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

Question

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

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

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

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

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

Answer 1

鉴于适当的条件，暴露标识符不是安全风险。而且，在实践中，设计Web应用程序而不暴露标识符将是非常繁重的。

以下是一些很好的规则：

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

Answer 2

这取决于ID代表什么。

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

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

Answer 3

一般的想法是这样的：“向任何人公开关于你的应用程序内部运作的信息很少。”

公开数据库ID会将其视为披露某些信息。

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

Answer 4

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

Answer 5

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

Answer 6

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

E.g。用户可以轻松更改此qs中的id参数，并查看/修改不应该http://someurl?id=1

的数据

Answer 7

当您向客户端发送数据库ID时，强制会检查两种情况下的安全性。如果您在网络会话中保留了ID，您可以选择是否需要这样做，这意味着可能会减少处理。

您一直在尝试将内容委托给您的访问控制;）可能在您的应用程序中就是这种情况，但我在整个职业生涯中从未见过如此一致的后端系统。他们中的大多数都拥有专为非网络使用而设计的安全模型，其中一些在死后添加了其他角色，其中一些已经在核心安全模型之外进行了固定（因为角色是在不同的操作环境中添加的，比如说在网络之前）。

所以我们使用合成会话本地id，因为它隐藏了我们可以逃脱的内容。

还存在非整数关键字段的问题，枚举值和类似情况可能就是这种情况。您可以尝试清理这些数据，但有可能最终会像little bobby drop tables那样。

Answer 8

从代码设计的角度来看，应将数据库ID视为持久性技术的私有实现细节，以跟踪行。如果可能的话，您应该在设计应用程序时绝对不要以任何方式引用此ID。相反，您应该考虑一般如何识别实体。一个人的身份证号被识别吗？是否用电子邮件标识了一个人？如果是这样，您的帐户模型应该只引用这些属性。如果没有真正的方法来标识具有此类字段的用户，那么您应该在访问数据库之前生成UUID。

这样做有很多优点，因为它使您可以将域模型与持久性技术分离。这意味着您可以替代数据库技术而不必担心主键兼容性。如果您编写适当的授权代码，则将主键泄漏到数据模型中并不一定会带来安全问题，但这表明其设计不尽人意。