暴露数据库 ID - 安全风险？

如何解决暴露数据库 ID - 安全风险？

暴露数据库标识符存在风险。另一方面，在完全不暴露它们的情况下设计 Web 应用程序将是非常繁重的。因此，重要的是要了解风险并小心应对。

第一个危险是 OWASP 所说的“不安全的直接对象引用”。如果有人发现了一个实体的 id，而您的应用程序缺乏足够的授权控制来阻止它，他们可能会做您不打算做的事情。

这里有一些好的规则可以遵循：

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

有一些方案可以对最终用户隐藏真实标识符（例如，真实标识符与服务器上临时的、用户特定的标识符之间的映射），但我认为这是一种默默无闻的安全形式。我想专注于保持真正的加密秘密，而不是试图隐藏应用程序数据。在 Web 上下文中，它也与广泛使用的 REST 设计背道而驰，其中标识符通常出现在 URL 中以寻址受访问控制的资源。

另一个挑战是标识符的预测或发现。攻击者发现未经授权对象的最简单方法是从编号序列中猜测它。以下指南可以帮助减轻这种情况：

1. 仅公开不可预测的标识符。出于性能考虑，您可以在数据库内的外键关系中使用序列号，但您希望从 Web 应用程序引用的任何实体也应该具有不可预测的代理标识符。这是唯一应该向客户公开的内容。为这些使用随机 UUID 是分配这些代理密钥的实用解决方案，即使它们在密码学上并不安全。

2. 然而，在密码学上不可预测的标识符是必要的一个地方是在会话 ID 或其他身份验证令牌中，其中 ID 本身对请求进行身份验证。这些应该由加密 RNG 生成。

解决方法

我听说公开数据库 ID（例如在 URL 中）是一种安全风险，但我无法理解为什么。

关于为什么它是风险的任何意见或链接，或者为什么它不是？

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

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

编辑（几个月后）：我目前的首选做法是使用 UUIDS 作为 ID 并公开它们。如果我使用序列号（通常用于某些数据库的性能）作为
ID，我喜欢为每个条目生成一个 UUID 令牌作为备用键，并公开它。