database - 公开数据库 ID - 安全风险？

Question

我听说公开数据库 ID(例如，在 URL 中)存在安全风险，但我无法理解其中的原因。

关于为什么它有风险或为什么没有风险的任何意见或链接？

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

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

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

Answer 1

暴露数据库标识符存在风险。另一方面，在完全不公开它们的情况下设计 Web 应用程序将是极其繁重的工作。因此，了解风险并注意解决这些风险非常重要。

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

这里有一些好的规则要遵循:

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

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

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

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

2. 然而，在 session ID 或其他身份验证 token 中，密码不可预测的标识符是必需的，ID 本身在其中对请求进行身份验证。这些应该由加密 RNG 生成。