代码之家  ›  专栏  ›  技术社区  ›  tvanfosson

RESTful web应用程序中的标识列和安全性

  •  0
  • tvanfosson  · 技术社区  · 17 年前

    问题

    在RESTful web应用程序中使用时,自动递增的标识列是否应该具有非默认种子/增量?

    我正在开发我的第一个ASP.NETMVC应用程序,并试图保持URL的RESTful状态。该应用程序没有单独的管理网站。我使用属性来控制谁可以访问站点的哪些部分,以及当前用户根据其在系统中的角色可以看到哪些菜单项。我(主要)遵循ActiveRecord DB模式,对我的表(包括用户表)使用合成ID,ID是自动生成的标识列。

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

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

    4 回复  |  直到 17 年前
        1
  •  3
  •   Lucero    17 年前

    我的建议是使用guid而不是自动增加id。这就彻底摆脱了“猜谜游戏”。

        2
  •  0
  •   JoshBerke    17 年前

    我一直非常怀疑使用Guid;然而,正如Lucerno指出的,它确实有助于根据Guid的生成和使用方式最大限度地减少猜测游戏。例如,使用SQL Server中的sequential生成的GUID不会阻止猜谜游戏。

    如果您有一个域模型,并且您使用像nHibernate这样的ORM,甚至使用自己的ORM,那么GUI也非常方便。因为它大大简化了插入反向引用的复杂性,因为所有对象都可以在早期获得id。

    也就是说,如果你的Id包含在URL中,它们应该被视为非常公开的数据。即使通过HTTPS,恶意攻击也可能获取整个URL。如果您的页面请求任何第三方内容,例如Google analytics,则url查询字符串和所有内容都将作为引用发送给第三方。

        3
  •  0
  •   JeeBee    17 年前

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

        4
  •  0
  •   tvanfosson    16 年前