如何在避免使用guid的同时防止HTML被利用？

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

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

虽然我很感激我可以“引导它”，但我还是犹豫着这样做，因为我发现在调试数据库时，与它们一起工作很麻烦

我在这里有选择吗？我必须使用GUID来防止容易猜测ID，还是有某种干式机制可以用来验证ID返回站点时的使用情况

---

更新：一位评论员问到了我所期待的漏洞。比方说，我弹出一个HTML表单，其中包含一个下拉列表，其中列出了所有可以导入“宝藏”的位置。用户拥有的位置的id是1、2和3，它们在HTML中提供。但是用户检查html，摆弄它，然后决定将id为4的帖子放在一起。4不是他的位置，而是其他人的位置。

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

这可能看起来很乏味，但这确实是确保用户能够访问他们试图修改的内容的唯一方法。使用未经验证的guid是不明确的安全性：当然猜测它们是困难的，但是如果有足够的资源，您可以潜在地猜测它们

---

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

您描述的问题称为“不安全的直接对象引用”，小组建议采用两种策略来处理此问题：

使用基于会话的间接对象引用，以及

正在验证对对象引用的所有访问

建议#1的一个示例是，不要使用下拉选项1、2和3，而是为每个选项指定一个GUID，该GUID与用户会话中映射中的原始ID关联。当您收到该用户的帖子时，您会检查给定ID应该绑定到哪个对象。OWASP的ESAPI有一些不同语言的库来帮助实现这一点

---

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

您所描述的是不安全的ID。一旦您确定了威胁并确定哪些ID属于某些用户，请确保对此服务器端进行了检查。

您希望利用什么机制进行攻击？在什么情况下，篡改数据可能会危害您的系统？使用guid并不会使任何东西天生更安全。为您更新了OP。在这种情况下，guid更安全，因为你猜不到它们。再编辑一次：它可能看起来很乏味；p--我本来打算这么做的，但是看到你自己做编辑，不想发生冲突因此，如果我明白了这一点，这意味着asp.net在API上提供的角色属性（至少在设计上）或多或少都是毫无价值的（当然它们有点帮助，但它们不是auth的灵丹妙药），因为我们需要自己验证大多数用户的操作。我说没有价值，因为如果使用它们，那么本质上就是将身份验证代码在属性和API顶部的代码之间拆分，在API顶部，将所有身份验证放在一个地方会更整洁。。。。我想我要问的是你是否仍然使用它们。@Quibblesome-By

Role

属性，你指的是

Authorize

属性的Role属性吗？该属性用于控制授权，即用户是否具有查看特定操作/控制器的权限——请更多地考虑

Admin

与

普通用户。它的责任不再延伸。验证用户的实际操作/数据操作是业务逻辑可以回答的问题，因此您必须自己验证操作。