暴露数据库 ID - 安全风险? [英] Exposing database IDs - security risk?
问题描述
我听说公开数据库 ID(例如在 URL 中)存在安全风险，但我无法理解原因.
I've heard that exposing database IDs (in URLs, for example) is a security risk, but I'm having trouble understanding why.
是否有任何关于为什么存在风险或为什么不存在风险的意见或链接?
Any opinions or links on why it's a risk, or why it isn't?
当然访问是有范围的，例如如果您看不到资源 foo?id=123，您将看到一个错误页面.否则 URL 本身应该是秘密的.
of course the access is scoped, e.g. if you can't see resource foo?id=123 you'll get an error page. Otherwise the URL itself should be secret.
如果 URL 是秘密的，它可能会包含一个生成的具有有限生命周期的令牌，例如有效期1小时，只能使用一次.
if the URL is secret, it will probably contain a generated token that has a limited lifetime, e.g. valid for 1 hour and can only be used once.
编辑(几个月后):我目前对此的首选做法是将 UUIDS 用于 ID 并公开它们.如果我使用序列号(通常用于某些 DB 的性能)作为 ID，我喜欢为每个条目生成一个 UUID 令牌作为备用键，并公开它.
EDIT (months later): my current preferred practice for this is to use UUIDS for IDs and expose them. If I'm using sequential numbers (usually for performance on some DBs) as IDs I like generating a UUID token for each entry as an alternate key, and expose that.
推荐答案
暴露数据库标识符存在相关风险.另一方面，在完全不公开它们的情况下设计 Web 应用程序将是极其繁重的.因此，了解风险并小心应对这些风险非常重要.
There are risks associated with exposing database identifiers. On the other hand, it would be extremely burdensome to design a web application without exposing them at all. Thus, it's important to understand the risks and take care to address them.
第一个危险是 OWASP 所称的不安全的直接对象引用". 如果有人发现了实体的 id，而您的应用程序缺乏足够的授权控制来阻止它，他们可以做您不希望的事情.
The first danger is what OWASP called "insecure direct object references." If someone discovers the id of an entity, and your application lacks sufficient authorization controls to prevent it, they can do things that you didn't intend.
以下是一些很好的规则:
Here are some good rules to follow:
- 使用基于角色的安全来控制对操作的访问.这是如何完成的取决于您选择的平台和框架，但许多支持声明式安全模型，当操作需要某些权限时，该模型会自动将浏览器重定向到身份验证步骤.
- 使用编程安全来控制对对象的访问.这在框架级别更难做到.更常见的是，您必须将其写入代码中，因此更容易出错.这种检查超越了基于角色的检查，不仅确保用户具有操作权限，而且还对正在修改的特定对象具有必要的权限.在基于角色的系统中，很容易检查是否只有经理可以加薪，但除此之外，您需要确保员工属于特定经理的部门.
有一些方案可以对最终用户隐藏真实标识符(例如，真实标识符和服务器上临时的、用户特定的标识符之间的映射)，但我认为这是一种默默无闻的安全形式.我想专注于保留真正的加密机密，而不是试图隐藏应用程序数据.在 Web 上下文中，它也与广泛使用的 REST 设计背道而驰，在这种设计中，标识符通常出现在 URL 中以寻址受访问控制的资源.
There are schemes to hide the real identifier from an end user (e.g., map between the real identifier and a temporary, user-specific identifier on the server), but I would argue that this is a form of security by obscurity. I want to focus on keeping real cryptographic secrets, not trying to conceal application data. In a web context, it also runs counter to widely used REST design, where identifiers commonly show up in URLs to address a resource, which is subject to access control.
另一个挑战是标识符的预测或发现.攻击者发现未授权对象的最简单方法是从编号序列中猜测它.以下指南可以帮助缓解这种情况:
Another challenge is prediction or discovery of the identifiers. The easiest way for an attacker to discover an unauthorized object is to guess it from a numbering sequence. The following guidelines can help mitigate that:
仅公开不可预测的标识符.出于性能考虑，您可以在数据库内的外键关系中使用序列号，但是您想要从 Web 应用程序引用的任何实体也应该具有不可预测的代理标识符.这是唯一应该暴露给客户端的.为这些使用随机 UUID 是分配这些代理密钥的实用解决方案，即使它们在加密方面并不安全.
Expose only unpredictable identifiers. For the sake of performance, you might use sequence numbers in foreign key relationships inside the database, but any entity you want to reference from the web application should also have an unpredictable surrogate identifier. This is the only one that should ever be exposed to the client. Using random UUIDs for these is a practical solution for assigning these surrogate keys, even though they aren't cryptographically secure.
一个需要加密不可预测标识符的地方是会话 ID 或其他身份验证令牌，其中 ID 本身对请求进行身份验证.这些应该由加密 RNG 生成.
One place where cryptographically unpredictable identifiers is a necessity, however, is in session IDs or other authentication tokens, where the ID itself authenticates a request. These should be generated by a cryptographic RNG.
这篇关于暴露数据库 ID - 安全风险?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
