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

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

是否对为什么有风险有任何意见或链接？

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

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

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

在适当的条件下，公开标识符不是安全风险。而且，实际上，在不公开标识符的情况下设计Web应用程序将非常繁重。

以下是一些要遵循的良好规则：

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

尽管不是数据安全风险，但这绝对是商业智能安全风险，因为它同时暴露了数据大小和速度。我已经看到企业受到了这种伤害，并且已经深入地介绍了这种反模式。除非您只是在做实验而不是做生意，否则我强烈建议您不要公开您的私人身份证。https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

这取决于ID代表什么。

考虑一个出于竞争原因不想公开其拥有多少成员但通过使用顺序ID仍在URL中显示该站点的站点：http : //some.domain.name/user? id= 3933

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

普遍的思路是：“向任何人公开有关您应用内部运作的信息。”

公开数据库ID被视为公开了一些信息。

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

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

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

例如，用户可以轻松地在此qs中更改id参数，并查看/修改他们不应该使用的数据http：// someurl？id = 1

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

您一直在尝试将事情委托给您的访问控制;）在您的应用程序中可能会出现这种情况，但是我从没在整个职业生涯中看到过如此一致的后端系统。他们中的大多数人都具有专为非Web使用而设计的安全模型，有些人死后又添加了其他角色，其中一些人被附加在核心安全模型之外（因为该角色是在不同的操作环境中添加的，例如，在网络之前）。

因此，我们使用合成会话本地ID，因为它隐藏了尽可能多的内容。

还存在非整数键字段的问题，枚举值和类似值可能会出现这种情况。您可以尝试对数据进行清理，但是最终您可能会像小小的鲍勃放置表那样。