尝试了解 Data API Builder (DAB) 以及它是否适合我的用例。
基于一个简单的地址簿示例,有一个“地址”表,其中包含以下列:
用户(地址簿的用户,可能是从用户表链接的 ID)
姓名
电子邮件地址
在标准 Web 应用程序(前端 + 后端)中,为了获取属于应用程序用户的所有地址的列表,后端函数将获取用户 ID(从用户身份验证中解密)并返回链接到的所有地址用户。
在DAB示例中,前端将根据用户ID过滤/查询地址表,与上面相同。
但是,怎样才能阻止黑客仅仅增加用户 ID 并从整个表中提取所有地址,或者甚至不将用户 ID 添加到查询过滤器并获取整个地址表呢?
上面的标准网络应用程序已获得授权,可确保仅返回用户的地址。
我的假设正确吗?
有解决办法吗?
如何确保只能返回链接到授权用户的地址?
使用 GUID 作为用户 ID 并仅向 DAB 公开存储过程?
如何确保只能返回链接到授权用户的地址?
SESSION_CONTEXT
的支持以及底层 Azure SQL 或 SQL Server 数据库引擎中的行级安全性来实现这一目标。
简而言之,您需要首先在 DAB 配置中启用所述
SESSION_CONTEXT
:
{
...
"data-source": {
"database-type": "mssql",
"options": {
"set-session-context": true
},
"connection-string": "<connection-string>"
},
...
}
然后,您将在数据库中创建一个函数谓词,该函数谓词根据表中的数据执行检查,并根据在所述
SESSION_CONTEXT
中传递的有关特定用户的数据,返回该数据是否应可供特定用户使用。 :
CREATE FUNCTION dbo.RevenuesPredicate(@username varchar(max))
RETURNS TABLE
WITH SCHEMABINDING
AS RETURN SELECT 1 AS fn_securitypredicate_result
WHERE @username = CAST(SESSION_CONTEXT(N'name') AS varchar(max));
最后,您将使用上述谓词函数创建行级安全策略:
CREATE SECURITY POLICY dbo.RevenuesSecurityPolicy
ADD FILTER PREDICATE dbo.RevenuesPredicate(username)
ON dbo.Revenues;
您能否使用此设置来满足给定的数据安全要求取决于您的授权模型是否简单、您使用 Azure SQL 或 SQL Server,以及您对静态 Web 应用程序的内置授权功能的直接依赖。任何超出此范围的复杂性都将妨碍此功能的使用。