6

我最近继承了一个 ASP.NET MVC 4 代码库。我注意到的一个问题是在 url 以及 html 表单提交中使用了一些数据库 ID（整数）。当前状态的代码可通过 URL 修补和创建具有不同数字的自定义 HTML 帖子来利用。

现在，虽然我可以通过使用会话状态或其他身份验证检查轻松解决 URL 问题，但我不太确定嵌入到站点吐出的 HTML 中的数据库 ID（即我给他们一个下拉列表来填充）。当 ID 在帖子中返回时，我如何确定我将它们作为有效选项放在那里？就解决这个问题而言，什么被认为是“最佳实践”？

虽然我很感激我可以“引导它”，但我很犹豫这样做，因为我发现在调试数据库时使用它们很痛苦。

我在这里有选择吗？我必须 GUID 以防止轻易猜测 id，还是有某种 DRY 机制可以用来在 id 返回站点时验证它们的使用？

更新：一位评论者询问了我期待的漏洞。假设我吐出了一个 HTML 表单，其中包含一个可以从中导入“宝藏”的所有位置的下拉列表。用户拥有的位置的 id 是 1,2 和 3，这些在 HTML 中提供。但是用户检查了 html，对其进行了修改，并决定将一个 POST 与 4 选择的 id 放在一起。4 不是他的位置，是别人的。

4

3 回答 3

9

根据用户可以修改的 ID 验证传递的 ID。

这可能看起来很乏味，但这确实是确保用户可以访问他们尝试修改的内容的唯一方法。使用未经验证的 GUID 是隐蔽的安全性：确定猜测它们很困难，但如果有足够的资源，您可能会猜测它们。

在对发布的数据执行任何其他操作之前，您可以在控制器顶部执行此操作。如果存在违规，只需抛出异常并让您的全局异常处理程序处理它；您不需要以漂亮的方式处理它，因为您可以安全地假设用户正在以不受支持的方式篡改数据。

于 2012-09-26T15:13:26.477 回答
4

您描述的问题被称为“不安全的直接对象引用”，OWASP小组推荐了两种策略来处理这个问题：

  1. 使用基于会话的间接对象引用，以及
  2. 验证对对象引用的所有访问。

建议 #1 的一个示例是，您不使用下拉选项 1、2 和 3，而是为每个选项分配一个 GUID，该 GUID 与用户会话中的地图中的原始 ID 相关联。当您从该用户处获得 POST 时，您会检查给定 ID 应该绑定到哪个对象。OWASP 的 ESAPI 有一些库可以用各种语言帮助解决这个问题。

但在许多情况下，建议 #1 实际上适得其反。例如，在许多情况下，您希望拥有可以从一个用户复制/粘贴到另一个用户的 URL。过程#2 通常被视为解决此问题的最简单方法。

于 2012-09-26T15:20:08.797 回答
2

您正在描述带有不安全 ID的损坏的访问控制。一旦您确定了威胁并确定了哪些 Id 归某些用户所有，请确保对该服务器端进行检查。

于 2012-09-26T15:21:24.167 回答