这是针对数据形式的网络表单的初学者模式问题。我阅读了暴露数据库 ID - 安全风险？并且接受的答案让我认为这是浪费时间，但是等等......
我有一个引用业务逻辑库的 MVC 项目，以及引用相同的 NHibernate SQL 存储库的程序集。如果有什么东西迫使我直接从我的控制器代码库中引用这些存储库，我就会知道出了什么问题。但是当这些控制器在 URL 参数中与数据库记录 ID 交谈时，它只是看起来是错误的吗？
我无法想象那些 ID 会变得无法使用（通过 MVC 操作）。我认为我不需要两个 UI 实体对应于数据库中的同一行。我不打算让控制器以任何方式解释 ID。代理键将产生零差异。尽管如此，我还是想解决这个问题，因为关于理性设计的假设并不比跳层依赖更好。
您将如何制作一个仅引用业务逻辑程序集并在 BL 对象和仅对该会话有意义的 GUID 中进行对话的 Web 应用程序，而该程序集使用数据库 ID 保留事务？
我不是安全专家，但我可以向用户公开某些 ID，例如产品 ID、用户 ID 以及用户通常可以阅读的任何内容，这意味着如果我向用户展示产品，则显示其产品身份证不是问题。
用户不直接与之交互的系统内部的东西，比如事务 ID，我不向用户显示，不是害怕他们以某种方式编辑它，而是因为那不是对他们有用的信息。
通常在表单中，我会将操作点指向“mysite.com/messages/view/5”，其中 5 是他们想要查看的消息。在所有这些操作中，我始终通过执行简单的数据库检查并确保登录用户等于消息所有者来确保用户有权查看它（修改或删除，需要任何功能）。
如果需要，您可以加密或散列您的 id。使用会话 ID 作为盐。这取决于上下文。您希望目录页面清晰且易于复制的公共购物网站。用户帐户管理员可以对 id 进行加密，因此用户无法通过 url 入侵他人的帐户。
我不认为这是默默无闻的安全。如果恶意用户拥有一个被盗用的帐户，他们可以查看以该用户身份登录时设置的所有表单字段、url id 和 cookie 值。然后，他们可以在以其他用户身份登录时尝试使用这些来升级权限。但是通过使用会话 ID 作为盐来保护它们，您已经锁定了该数据，因此它仅在一个会话中有用。这些页面甚至无法添加书签。他们能弄清楚你的保护措施吗？可能。但很可能他们只是转移到另一个站点。如果有人想上车，锁上你的车门实际上并不能阻止任何人进入你的车，但它会让事情变得更难，所以每个人都这样做。
要非常非常小心，因为参数篡改会导致数据修改。在公开这些 id 时，必须非常小心地将关于“谁可以访问哪些 id”的规则构建到您的应用程序中。
例如，如果您要根据 OrderId 更新订单，请在 where 子句中包含用于加载和更新的内容： where order.orderid=passedInOrderId 和 Order.CustomerId=
我开发了一个扩展来帮助在 MVC 中存储 id 可用这里：
http://mvcsecurity.codeplex.com/
我还在我的安全课程中谈到了这一点：Hack Proofing your ASP.NET MVC and Web Forms Applications
除了这些响应之外，有时最好使用明显的 id，这样人们就可以破解 url 以获得他们想要的信息。例如，www.music.com\artist\acdc 或 www.music.com\arist\smashing-pumpkins。如果它对您的用户有意义，并且如果您可以通过 URL 增加用户从页面中理解的信息，那就更好了，特别是如果您的细分市场年轻或精通技术，那么使用 id 对您有利。这也将提高您的搜索引擎优化。我会说当它没有用时，然后对其进行编码。一个开发人员只需要一个错误就不会根据会话检查客户 ID，并且您会暴露整个客户群。
但是，当然，您的单元测试应该抓住这一点！
虽然您会发现有些人说 ID 只是一个实现细节，但在大多数系统中，您需要一种唯一标识域实体的方法，并且您很可能会为该标识符生成一个 ID。ID由数据库生成的事实是一个实现细节；但是一旦生成，它就成为域实体的属性，因此在需要引用实体的任何地方使用它是完全合理的。