将数据库ID公开给UI

Question

这是一个关于Web表单数据类型的初学者模式问题。我读了Exposing database IDs - security risk?，接受的答案让我觉得这是浪费时间，但等等......

我有一个引用业务逻辑库的MVC项目，以及引用它的NHibernate SQL存储库的程序集。如果有什么东西强迫我的手去直接从我的控制器代码库引用这些存储库，我就知道出了什么问题。但是当这些控制器在URL参数中与数据库记录ID对话时，它只是看起来错了吗？

我无法想象这些ID会变成非消耗品（通过MVC行动）。我不想我需要两个与数据库中同一行对应的UI实体。我不打算让控制器以任何方式解释ID。代理键会产生零差异。尽管如此，我还是想解决这个问题，因为关于平面设计的假设并不比跳过层次的依赖更好。

如何使用仅引用该对话的BL对象和GUID的业务逻辑程序集和会话的Web应用程序，而程序集使用数据库ID保留事务？

Answer 1

我没有安全专家，但我没有任何问题向用户公开某些ID，例如产品ID，用户ID以及用户通常可以读取的任何内容，这意味着我向用户显示产品用户，显示其产品ID不是问题。

用户不直接与之交互的系统内部的东西，比如交易ID，我不向用户显示，不用担心他们以某种方式编辑它，而只是因为那不是有用的信息他们。

通常在表单中，我会将操作指向＆＃34; mysite.com/messages/view/5"，其中5是他们想要查看的消息。在所有这些操作中，我总是通过执行简单的数据库检查并确保登录用户是相同的，确保用户有权查看它（修改或删除，需要哪些功能）消息所有者。

Answer 2

如果需要，您可以加密或散列您的ID。使用会话ID作为salt。这取决于具体情况。一个公共购物网站，您希望目录页面清晰易于复制。用户帐户admin可以加密ID，因此用户无法将其黑客入侵其他人的帐户。

我不认为这是默默无闻的安全。如果恶意用户有一个被入侵的帐户，他们可以查看以该用户身份登录时设置的所有表单字段，url ID和cookie值。然后，他们可以尝试使用那些以其他用户身份登录的用户来升级权限。但是通过使用会话ID作为salt保护它们，您已将数据锁定，因此它仅在一个会话中有用。这些页面甚至无法加入书签。他们可以找出你的保护吗？有可能。但可能他们只是转移到另一个网站。如果他们想要进入车门，锁定你的车门实际上并没有让任何人离开你的车，但这会使它变得更难，所以每个人都这样做。

Answer 3

非常非常小心，因为参数篡改会导致数据修改。在暴露这些ID时，必须非常仔细地将“谁可以访问哪些ID”的规则构建到您的应用程序中。

例如，如果您要基于OrderId更新订单，请在您的where子句中包含加载和更新： 其中order.orderid = passedInOrderId和Order.CustomerId =

我开发了一个扩展来帮助在MVC中存储id：

http://mvcsecurity.codeplex.com/

我也在安全课程中谈到这一点：Hack Proofing your ASP.NET MVC and Web Forms Applications

Answer 4

除了这些回复之外，有时使用明显的ID会很好，所以人们可以通过破解网址来获取他们想要的信息。例如，www.music.com \ artist \ acdc或www.music.com \ arist \ smashing-pumpkins。如果它对您的用户有意义，并且如果您可以通过URL增加用户从页面中理解的信息，那就更好了，特别是如果您的细分市场年轻或精通技术，那么请使用id来获得优势。这也将提升你的SEO。 我会说当它没有用时，然后对其进行编码。只需要一个开发人员犯一个错误就是不检查会话中的客户ID并暴露整个客户群。

但是，当然，你的单元测试应该抓住它！

Answer 5

虽然您会发现一些人说ID只是一个实现细节，但在大多数系统中，您需要一种唯一标识域实体的方法，并且很可能您将为该标识符生成ID。数据库生成的ID是一个实现细节;但是一旦生成它就会成为域实体的一个属性，因此在需要引用该实体的任何地方使用它都是完全合理的。