Database expose数据库 ID 安全风险

发布于12月29日

我听说公开数据库ID(例如，在URL中)是一种安全风险，但是我很难理解为什么.

关于为什么它是一种风险，或者为什么它不是，有什么意见或链接吗？

编辑:当然，访问是有范围的，例如，如果你看不到资源foo?id=123，你会看到一个错误页面.否则URL本身应该是保密的.

编辑:如果URL是机密的，它可能会包含一个生成的令牌，该令牌的生命周期有限，例如有效期为1小时，并且只能使用一次.

编辑(几个月后):我目前的首选做法是将UUID用于ID并公开它们.如果我使用序列号(通常用于某些DB上的性能)作为ID，我喜欢 for each 条目生成一个UUID令牌作为备用键，并公开它.

推荐答案

expose 数据库标识符存在相关风险.另一方面，设计一个web应用程序而不公开它们将是极其繁重的.因此，重要的是要了解风险并小心应对.

第一个危险是OWASP所说的"insecure direct object references."如果有人发现实体的id，而您的应用程序缺乏足够的授权控制来阻止它，他们可能会做您不想做的事情.

以下是一些好的规则:

使用基于角色的安全性来控制对操作的访问.如何做到这一点取决于您 Select 的平台和框架，但许多平台和框架都支持声明性安全模型，当某个操作需要某些权限时，该模型会自动将浏览器重定向到身份验证步骤.
使用编程安全性来控制对对象的访问.这在框架级别更难做到.更多情况下，它是您必须写入代码中的内容，因此更容易出错.此判断超越了基于角色的判断，它不仅确保用户具有操作权限，而且还确保用户对正在修改的特定对象具有必要的权限.在基于角色的系统中，很容易判断是否只有经理可以加薪，但除此之外，您需要确保员工属于特定经理所在的部门.

存在对终端用户隐藏真实标识符的方案(例如，真实标识符与服务器上临时的、特定于用户的标识符之间的映射)，但我认为这是一种模糊的安全形式.我想专注于保持真正的加密秘密，而不是试图隐藏应用程序数据.在网络环境中，它也与广泛使用的睡觉设计背道而驰，后者的标识符通常出现在URL中，以寻址受访问控制的资源.

另一个挑战是预测或发现标识符.对于攻击者来说，发现未经授权对象的最简单方法是从编号序列中猜测它.以下指导原则可以帮助缓解这种情况:

仅公开不可预测的标识符.为了提高性能，您可以在数据库内的外键关系中使用序列号，但要从web应用程序引用的任何实体也应该具有不可预测的代理标识符.这是唯一一个应该向客户公开的.使用随机UUID来分配这些代理密钥是一个实用的解决方案，尽管它们在加密方面不安全.
然而，需要密码上不可预测的标识符的一个地方是会话ID或其他身份验证令牌，其中ID本身对请求进行身份验证.这些应该由加密RNG生成.