公开数据库ID – 安全风险？
我听说公开数据库ID（例如在URL中）是一种安全风险，但是我很难理解为什么。
任何意见或链接，为什么这是一个风险，或为什么不是？
编辑：当然访问是有作用域的，例如，如果你不能看到资源foo?id=123你会得到一个错误页面。 否则，URL本身应该是秘密的。
编辑：如果URL是秘密的，它可能会包含一个有限生命周期的生成令牌，例如1小时有效，只能使用一次。
编辑（几个月后）：我目前的首选做法是使用UUIDS的ID和暴露他们。 如果我使用序列号（通常用于某些数据库上的性能）作为ID，我喜欢为每个条目生成一个UUID标记作为备用密钥，然后公开这个标记。
鉴于适当的条件，暴露标识符不是安全风险。 而且，在实践中，devise一个Web应用程序而不暴露标识符是非常繁琐的。
以下是一些很好的规则：
- 使用基于angular色的安全性来控制对操作的访问。 这是怎么做的取决于你select的平台和框架，但是许多支持声明式安全模型，当动作需要某些权限时，它将自动将浏览器redirect到authentication步骤。
- 使用编程安全性来控制对对象的访问。 在框架层面这很难做到。 更多的时候，这是你必须写入你的代码，因此更容易出错。 这种检查不仅限于基于angular色的检查，通过确保用户对操作具有权限，还对被修改的特定对象具有必要的权限。 在一个基于angular色的系统中，很容易检查只有pipe理者可以加薪，但除此之外，你需要确保员工属于特定经理的部门。
- 对于大多数数据库logging来说，条件1和2是足够的。 但是如果join这个概念，增加不可预测的ID可以被认为是一点额外的保险，或者“深度安全”。 然而，一个需要不可预知的标识符的地方是会话ID或其他authentication令牌，其中ID本身对请求进行authentication。 这些应该由密码RNG生成。
这取决于ID代表什么。
考虑一个网站，出于竞争的原因，不想公开他们有多less成员，但通过使用顺序ID显示它无论如何在URL中： http ： //some.domain.name/user？ id = 3933
另一方面，如果他们使用用户的login名： http : //some.domain.name/user?id=some他们还没有透露用户不知道的任何东西。
总体思路是这样的：“向任何人披露关于你的应用程序内部运作的信息。”
公开数据库ID计算公开了一些信息。
原因是黑客可以使用任何有关您的应用程序内部工作的信息来攻击您，或者用户可以更改URL以进入他/她不应该看到的数据库？
我们使用数据库id的GUID。 泄漏他们是不那么危险的。
如果您在数据库中使用整数ID，则可以通过更改qsvariables来让用户轻松查看不应该有的数据。
例如，用户可以很容易地在这个QS中更改ID参数，并查看/修改数据，他们不应该http：// someurl？id = 1
当你发送数据库ID到你的客户端时，你不得不在两种情况下检查安全性。 如果您将ID保留在您的networking会话中，您可以select是否需要这样做，这意味着可能会减less处理。
您一直在尝试将事物委托给您的访问控制;）在您的应用程序中可能会出现这种情况，但我从未在整个职业生涯中看到过如此一致的后端系统。 他们中的大多数都具有为非Web使用而devise的安全模型，有些在追授时添加了额外的angular色，其中一些已经被locking在核心安全模型之外（因为angular色被添加到不同的操作环境中）在networking之前）。
所以我们使用合成会话本地ID，因为它隐藏了我们可以逃避的一切。
还有非整数键字段的问题，这可能是枚举值和类似的情况。 您可以尝试清理这些数据，但是您可能会像小垃圾表一样丢失数据 。
虽然不是数据安全风险，但这绝对是商业智能安全风险，因为它暴露了数据大小和速度。 我已经看到企业受到这样的伤害，并且写下了这个反模式的深度。 除非你只是build立一个实验，而不是一个企业，否则我强烈build议把你的私人ID保持在公众的视线之外。 https://blog.lightrail.com/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e
