我最近继承了ASP.NET MVC 4代码库。我注意到的一个问题是在URL中使用了一些数据库ID（ints）以及html表单提交。目前状态的代码可通过URL修补和创建具有不同数字的自定义HTML帖子来利用。
现在，虽然我可以通过使用会话状态或其他身份验证来轻松修复URL问题，但我不太确定嵌入到网站吐出的HTML中的数据库ID（即我给他们一个下拉菜单）填写）。当ids回到帖子中时，我怎么能确定我把它们作为有效选项？ 什么被认为是＆＃34;最佳实践＆＃34;在解决这个问题方面？
虽然我很感激我可以＆＃34; GUID it up＆＃34;我这样做是犹豫不决的，因为我发现在调试数据库时，他们很痛苦。
我可以在这里选择吗？我必须指导以防止轻松猜测ID，或者是否有某种DRY机制可用于验证ID返回站点时的使用情况？
更新：一位评论者询问了我期待的漏洞。让我们说我吐出一个HTML表单，其中包含一个可以导入的所有位置的下拉列表＆＃34; treasure＆＃34;从。用户拥有的位置的ID是1,2和3，这些是在HTML中提供的。但是用户检查html，用它来解决问题，并决定将选择了id为4的POST放在一起。 4不是他的位置，而是别人的位置。
答案 0 :(得分：9)
验证通过用户可以修改的ID传递的ID。
这可能看起来很乏味，但这确实是确保用户可以访问他们试图修改的内容的唯一方法。使用没有验证的GUID是默默无闻的安全性：确定猜测它们很难，但是如果有足够的资源，你可以猜测它们。
在对发布的数据执行任何其他操作之前，您可以在控制器顶部执行此操作。如果存在违规，只需抛出异常并让全局异常处理程序处理它;您不需要以一种漂亮的方式处理它，因为您可以安全地假设用户以不受支持的方式篡改数据。
答案 1 :(得分：4)
您描述的问题称为“不安全的直接对象引用”，OWASP组建议使用两个策略来处理此问题：
建议＃1的一个示例是，不是使用下拉选项1,2和3，而是为每个选项分配与用户会话中的地图中的原始ID相关联的GUID。当您从该用户获得POST时，您将检查给定ID应该绑定到哪个对象。 OWASP的ESAPI有一些库可以用各种语言来帮助它。
但在许多情况下，建议＃1实际上会适得其反。例如，在许多情况下，您希望将URL从一个用户复制/粘贴到另一个用户。过程＃2通常被视为解决此问题的最简单方法。
答案 2 :(得分：2)
您正在使用不安全的ID描述Broken Access Control。一旦确定了威胁并确定了某些用户拥有哪些ID，请确保为此服务器端进行检查。