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

Exposing database IDs - security risk?

提问by orip

I've heard that exposing database IDs (in URLs, for example) is a security risk, but I'm having trouble understanding why.

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

Any opinions or links on why it's a risk, or why it isn't?

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

EDIT: of course the access is scoped, e.g. if you can't see resource foo?id=123you'll get an error page. Otherwise the URL itself should be secret.

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

EDIT: 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.

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

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.

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

采纳答案by erickson

Given the proper conditions, exposing identifiers is not a security risk. And, in practice, it would be extremely burdensome to design a web application without exposing identifiers.

在适当的条件下，公开标识符不会带来安全风险。而且，在实践中，在不公开标识符的情况下设计 Web 应用程序将是极其繁重的。

Here are some good rules to follow:

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

1. Use role-based security to control access to an operation. How this is done depends on the platform and framework you've chosen, but many support a declarative security model that will automatically redirect browsers to an authentication step when an action requires some authority.
2. Use programmatic security to control access to an object. This is harder to do at a framework level. More often, it is something you have to write into your code and is therefore more error prone. This check goes beyond role-based checking by ensuring not only that the user has authority for the operation, but also has necessary rights on the specific object being modified. In a role-based system, it's easy to check that only managers can give raises, but beyond that, you need to make sure that the employee belongs to the particular manager's department.
3. For most database records, conditions 1 and 2 are sufficient. But adding unpredictable IDs can be thought of as a little extra insurance, or "security in depth," if you buy into that notion. One place where 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.

1. 使用基于角色的安全性来控制对操作的访问。这是如何完成的取决于您选择的平台和框架，但许多支持声明式安全模型，当操作需要某些权限时，该模型将自动将浏览器重定向到身份验证步骤。
2. 使用编程安全来控制对对象的访问。这在框架级别更难做到。更常见的是，您必须将其写入代码中，因此更容易出错。这种检查超越了基于角色的检查，它不仅确保用户具有操作权限，而且还对正在修改的特定对象拥有必要的权限。在基于角色的系统中，很容易检查是否只有经理可以加薪，但除此之外，您需要确保员工属于特定经理的部门。
3. 对于大多数数据库记录，条件 1 和 2 就足够了。但是添加不可预测的 ID 可以被认为是一种额外的保险，或者“深度安全”，如果你相信这个概念。然而，不可预测的标识符是必需的一个地方是在会话 ID 或其他身份验证令牌中，其中 ID 本身对请求进行身份验证。这些应该由加密 RNG 生成。

回答by Peter

While not a data securityrisk this is absolutely a business intelligence securityrisk as it exposes both data size and velocity. I've seen businesses get harmed by this and have written about this anti-pattern in depth. Unless you're just building an experiment and not a business I'd highly suggest keeping your private ids out of public eye. https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

虽然不是数据安全风险，但这绝对是商业智能安全风险，因为它暴露了数据大小和速度。我已经看到企业因此受到伤害，并且已经深入讨论了这种反模式。除非你只是建立一个实验而不是一个企业，否则我强烈建议你不要让公众看到你的私人 ID。https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

回答by some

It depends on what the IDs stand for.

这取决于 ID 代表什么。

Consider a site that for competitive reason don't want to make public how many members they have but by using sequential IDs reveals it anyway in the URL: http://some.domain.name/user?id=3933

考虑一个网站，出于竞争原因不想公开他们有多少成员，但通过使用顺序 ID 无论如何都会在 URL 中显示它：http: //some.domain.name/user?id= 3933

On the other hand, if they used the login name of the user instead: http://some.domain.name/user?id=somethey haven't disclosed anything the user didn't already know.

另一方面，如果他们使用用户的登录名：http: //some.domain.name/user?id=some，他们没有透露用户不知道的任何内容。

回答by Arjan Einbu

The general thought goes along these lines: "Disclose as little information about the inner workings of your app to anyone."

一般的想法是这样的：“尽可能少地向任何人透露有关您的应用程序内部工作的信息。”

Exposing the database ID counts as disclosing some information.

公开数据库 ID 算作公开了一些信息。

Reasons for this is that hackers can use any information about your apps inner workings to attack you, or a user can change the URL to get into a database he/she isn't suppose to see?

这样做的原因是黑客可以使用有关您的应用程序内部工作的任何信息来攻击您，或者用户可以更改 URL 以进入他/她不应该看到的数据库？

回答by Joshua

We use GUIDs for database ids. Leaking them is a lot less dangerous.

我们使用 GUID 作为数据库 ID。泄漏它们的危险性要小得多。

回答by Jason

If you are using integer IDs in your db, you may make it easy for users to see data they shouldn't by changing qs variables.

如果您在数据库中使用整数 ID，您可以通过更改 qs 变量让用户轻松查看他们不应该看到的数据。

E.g. a user could easily change the id parameter in this qs and see/modify data they shouldn't http://someurl?id=1

例如，用户可以轻松更改此 qs 中的 id 参数并查看/修改他们不应该访问的数据http://someurl?id=1

回答by krosenvold

When you send database id's to your client you are forcedto check security in both cases. If you keep the id's in your web session you can choose if you want/need to do it, meaning potentially less processing.

当您发送数据库ID对你的客户，你都不得不在这两种情况下，检查安全性。如果您将 id 保留在您的网络会话中，您可以选择是否想要/需要这样做，这意味着可能会减少处理。

You are constantly trying to delegate things to your access control ;) This maybe the case in your application but I have never seen such a consistent back-end system in my entire career. Most of them have security models that were designed for non-web usage and some have had additional roles added posthumously, and some of these have been bolted on outside of the core security model (because the role was added in a different operational context, say before the web).

您一直在尝试将事物委托给您的访问控制；)在您的应用程序中可能就是这种情况，但在我的整个职业生涯中，我从未见过如此一致的后端系统。它们中的大多数具有专为非 Web 使用而设计的安全模型，有些在死后添加了额外的角色，其中一些已被固定在核心安全模型之外（因为该角色是在不同的操作上下文中添加的，例如在网络之前）。

So we use synthetic session local id's because it hides as much as we can get away with.

所以我们使用合成会话本地 ID，因为它隐藏了我们可以逃脱的尽可能多的东西。

There is also the issue of non-integer key fields, which may be the case for enumerated values and similar. You can try to sanitize that data, but chances are you'll end up like little bobby drop tables.

还有非整数键字段的问题，枚举值和类似的可能就是这种情况。您可以尝试清理该数据，但很有可能您最终会像小摇摆桌一样。