RESTful Web 应用程序中的标识列和安全性答案

【问题标题】：Identity columns and security in a RESTful web applicationRESTful Web 应用程序中的标识列和安全性
【发布时间】：2009-04-20 14:05:08
【问题描述】：

问题

在 RESTful Web 应用程序中使用时，自动增量标识列是否应该具有非默认种子/增量？

背景

我正在开发我的第一个 ASP.NET MVC 应用程序并尝试保持我的网址 RESTful。该应用程序没有单独的管理网站。我使用属性来控制谁可以访问站点的哪些部分，以及根据他们在系统中的角色，当前用户可以看到哪些菜单项。我（大部分）遵循 ActiveRecord DB 模式并为我的表（包括用户表）使用合成 id，其中 id 是自动生成的标识列。

今天早上我突然想到，在 RESTful 应用程序中为身份列使用默认种子存在细微的安全风险。如果您假设管理 ID，尤其是最强大的 ID，通常首先在应用程序中创建，那么它们将是系统中编号最小的 ID。虽然实际上并没有在应用程序中打开一个漏洞，但使用种子/增量的默认值可以使破解者更容易通过使用 RESTful 操作（例如 ChangePassword - 这是其中之一）定位低编号的 id 来攻击高价值目标ASP.NET MVC 站点模板中的开箱即用操作）。

我是否应该将设置一个非默认种子至少添加到我的用户表到我的安全最佳实践库中？这样做的效果值得吗？还是我太偏执了？作为一个相关问题，我是否应该更改帐户相关操作的现成模板名称。

【问题讨论】：

标签： asp.net-mvc security model-view-controller rest

【解决方案1】：

我的建议是使用 GUID 而不是自动递增 ID。这完全摆脱了“猜谜游戏”。

【讨论】：

同意这一点。有几个优点。您不必等待访问数据库来获取唯一 ID——您可以生成它，然后在需要时将其排队。您可以对这些进行 base 64 编码，并将它们作为 25 个字符串传递，您可以将其用作 URL 中的查询参数。
谢谢约翰。还有更多的优点，例如能够使用这些 ID 进行离线工作或同步等。 - GUID PK 有很多优点（也有很多缺点，例如是普通 int 的 4 倍或难以记住调试和测试）。
我敢打赌大多数数据库可以处理 4 倍的大小增加。考虑到现在磁盘空间和内存非常便宜，我预计除了最大的数据库之外，这不会产生重大影响。
Josh，这是真的，但是，除了空间和内存之外，还有一些性能影响。 4 倍大小意味着 4 倍大索引（对于非聚集索引），4 倍要加载的页面（由于固定页面大小）等，因此实际上对性能有一些影响，尤其是对于大数据集合.也就是说，我非常喜欢 GUID，而且我几乎一直在使用 GUID，总体上没有性能问题，但我认为牢记这一点是个好主意。

【解决方案2】：

我一直对使用 Guid 持怀疑态度；然而，正如 Lucerno 所指出的，它确实有助于减少猜谜游戏，具体取决于 Guid 的生成和使用方式。使用 SQL Server 顺序生成的 Guid 不会阻止猜谜游戏。

如果你有一个域模型并且你使用像 nHibernate 这样的 ORM 或者甚至滚动你自己的，Guids 也非常方便。因为它大大简化了插入反向引用的复杂性，因为所有对象都可以在早期被赋予它们的 id。

话虽如此，如果您的 ID 包含在 URL 中，它们应该被视为非常公开的数据。即使通过 HTTPS，狡猾的攻击也可以获取整个 URL。如果您的页面请求任何第三方内容（例如 Google 分析），则 url 查询字符串和所有内容都会作为引用者发送给第三方。

【讨论】：

【解决方案3】：

将登录用户保留在服务器端的会话中，而不是将其传递给客户端 - 这样客户端就永远无法在恶意查询中更改用户 ID。

【讨论】：

但是如果我希望管理员能够使用相同的操作来代表用户更改密码怎么办？
我会将其他用户对象也放在会话中以执行该操作，并且可能在更改密码表单中具有隐藏字段，例如“modifyOther”=“Y”，服务器可以检查决定采取什么行动。

【解决方案4】：

我现在决定通过更改自动增量列的默认种子来解决风险。这并不难，也不会改变应用程序的特性或 ActiveRecord 模式。由于这些列也用于外键关系，因此我希望将它们保留为整数以提高索引效率。

我不打算更改默认操作，除非不同的动词更有意义。让界面直观比将操作隐藏在一个晦涩的名称后面更重要。

【讨论】：