Question

我目前遇到了问题，我想很多人之前遇到过这种情况，我想知道你是如何处理它的。

因此，假设您的应用上有10.000个用户。（每个人都有自己的用户/ pw登录来管理他的东西）。进一步想象一下，您在后端有一个不断增长的规范化SQL表结构，其中的表包括：用户，订单，OrderPositions，发票等。

因此，为了显示/编辑/删除不具有用途的表的内容，你可能会有这样的链接，让ypur用户与应用程序进行交互。

~/Orders/EditOrder?id=12    
~/Orders/ShowOrderPosition?orderId=12&posId=443

好的，现在问题是：

如何防止“无复杂”的用户A访问（显示/编辑/删除）用户B的数据。

示例：

用户B致电：

~/Orders/ShowOrderPosition?orderId=12&posId=443

这是用户A的订单，因此用户B应该无法访问它。

因此，在我的代码中，我需要在每个SQL语句之前或之内进行UserIdentity检查，例如：

select * from OrderPosition op, Order o, User u 
   where op.Id = :orderId 
     and op.Fk_OrderId = :orderpositionId
     and o.Id = :orderId
     and o.Fk_User = :userId

只有这样我才能确保数据属于请求用户。

为达到可用的意愿当然会变得更复杂，usertable-connection在规范化中被“埋没”的程度越深（想象表，如付款或发票，连接到订单表......）

问题：

您处理此问题的方法是什么，结论：低复杂度，干燥和性能

（希望你明白我的意思;））

Answer 1

这有点像多租户应用程序 - 我已经沿着这条路线走下去，并将ID重新规范化到需要这种检查的所有那些表上（租户ID，在你的情况下，听起来像用户ID）。

然后我创建了一个仅包含该字段的接口，并将其应用于我的模型层中需要此访问权限的所有类。

在我的基本数据访问（存储库）类中，所有选择/更新/删除调用都通过，然后我检查是否该类的接口类型，然后检查当前访问是否匹配那个ID。

当然，这取决于您的代码的结构，以及实现这种全局变化的简单/复杂程度......

Answer 2

永远不要暴露ids。

如果你必须：加密它们。

Answer 3

效果

为了达到最佳性能，您必须非规范化，以便读取行并与某个应用程序级别变量进行比较，这将为您提供用户所拥有的权利类型的答案（这是相当快的，如果您的DAO / BAO级别插入它的组织良好将使其相对干燥且复杂性相对较低。）注意：复杂性也是您的安全模型的一个功能，一旦您开始实施可继承的，积极的和消极的，基于角色的访问规则，那么它就不能真的很简单。

DRY

另一条路线（这些天很少采取）是使用您的数据库角色来管理安全性;这可能会变得复杂但会提供无与伦比的安全性（因为它将在数据库级别而不是应用程序级别上得到保证。如果您设法将所有访问路径封装到VIEWS中，复杂性应该在应用程序代码级别下降需要在数据库级别进行相当多的重新定制。但是（！），可以通过对应用程序代码进行非常少的更改来实现安全模型 - 通过重命名现有表并用安全视图替换它们。

Answer 4

请勿使用您加密或未加密的内部ID列，它会在某一天回来咬你。

创建一个随机的，唯一的字符串（GUID，无论如何），其中包含用户和他请求的数据之间的链接。因此，对于用户34567而不是：

<a href="~/Orders/EditOrder?id=12">Edit order</a>

在临时表格中创建记录{“5dsfwe8frf823jrf”，34567,12}并显示：

<a href="~/Orders/EditOrder?txn=5dsfwe8frf823jrf">Edit order</a>

当用户点击该链接时，请从临时表中获取34567,12。

字符串5dsfwe8frf823jrf无法猜测=没有安全风险。

Web应用程序中的典型规范化安全问题

4 个答案: