避免在Web应用程序源中暴露主键？

Question

我经常遇到通过选择框等形式公开内部数据库主键的Web应用程序。偶尔我会看到javascript匹配一个int或guid魔术值来切换逻辑。

最佳做法是避免泄露Web应用程序中行的所有内部标识符，以防止外人了解您的系统太多，并可能使用它来利用您的系统。如果是这样，解决这个问题的最佳方法是什么？

您是否应该向Web应用程序公开可以转换回主键的其他值？

由于

修改

在一个完美的世界中，你的应用程序将是100％安全的，所以如果你遮住了东西就没关系了。显然情况并非如此，所以我们应该谨慎对待并且不公开这些信息吗？

有些人指出Stackoverflow可能会暴露Url中的密钥，这可能很好。但企业应用程序的注意事项有何不同？

Answer 1

我不同意暴露主键是个问题的立场。如果你让用户看到它们可能会有问题，因为它们在系统之外被赋予了意义，这通常是你想要避免的。

但是要使用ID作为组合框列表项的值？我说，去吧。从一些中间价值进行翻译有什么意义？您可能没有唯一的密钥可供使用。这样的翻译为bug带来了更大的潜力。

只是不要忽视安全。

如果说您向用户展示了6个项目（ID 1到6），请不要假设您只会从用户那里获得这些值。有人可能会通过发回ID 7来尝试破坏安全性，因此您仍需要验证您获得的内容是否被允许。

但完全避免这种情况？没门。没必要。

作为对另一个答案的评论说，请查看此处的URL。这包括无疑是SO数据库中问题的主要关键。公开用于技术用途的密钥完全没问题。

另外，如果你确实使用了一些代理价值，那就不一定更安全了。

Answer 2

对你的所有问题都是。我同意你的断言，你应该“向Web应用程序公开一些其他值，这些值可以转换回主键”

否则你可以打开潜在的问题。

修改

关于“没有理由对微不足道的钥匙进行点击的评论。现在查看浏览器的URL，我打赌你看到了一个键！”。

我理解你在说什么，是的，我确实看到了SO URL中的密钥，并且同意它可能确实引用了数据库PK。我承认在这样的情况下，如果没有更好的选择，那可能就行了。

我仍然喜欢暴露除PK以外的东西 - 具有语义价值的东西。问题的标题也在URL中，但由于这很难验证为唯一（或用户口头传递），因此无法在其自身上可靠地使用。

但是，当查看“标记”网址（即https://stackoverflow.com/questions/tagged/java+j2ee）时，不会公开PK，而是使用标记名称。就个人而言，我更喜欢这种方法，并会为此而努力。

我还想补充一点，PK指向的数据有时会随时间而变化。我已经开发了一个系统，其中一个表填充了来自脱机过程的信息 - 即每月统计数据，其中数据库表内容在月末下降并重新填充新数据。

如果数据以不同的顺序添加到数据库，则特定数据点的PK将会更改，并且从上个月到该数据的任何已保存书签现在将指向不同的数据集。

这是暴露PK会“破坏”与应用程序安全性无关的应用程序的一个实例。使用生成的密钥不是这样。

Answer 3

是的，公开密钥是可以用作攻击的信息。特别是如果它们是可预测的。

如果您认为信息敏感，请使用其他键/列。

例如，为了避免显示您拥有的用户，请考虑：

site.com/user/123 vs site.com/user/username

Answer 4

一如既往，“这取决于”。如果有人可以通过了解您每个（小时/日/月）执行的交易数量而获得价值（并且），并且您将交易ID暴露为单调递增的数字，那么这就是风险。

正如其他人所说，对于下拉值列表，通常没有问题。

Answer 5

公开除主键之外的其他值不会避免您检查安全性的负担。实际上，如果您的安全漏洞，“邪恶”用户仍可能通过更改网址中的值来访问他们不想要的对象。他们可能没有使用哪些值的线索，但随机选择值，他们可能会很幸运。

如果你想以这种方式提高安全性，你将不得不在url中使用大的随机字符串（使猜测变得困难）而不是id并使用与随机值匹配的间接表与背景中的良好id 。

我认为大部分时间都不值得麻烦。

也就是说，它对于您希望“默默无闻”的情况很有用，例如当您公开用于更改用户密码的页面时，不需要登录（对于丢失密码的用户）。在这种情况下，您还应该将限制有效日期与您的密钥相关联。

Answer 6

主键与代理键或内部键不同，尽管存在一些重叠。内部键的反面是自然键。有很多次将自然键用作主键。除非我们处理隐私问题，否则通常没有理由隐藏自然密钥。

我认为，您的真正问题是内部密钥是否应该向用户公开。答案是，“这取决于”。对于大多数用户社区，公开内部密钥将导致密钥被用作自然密钥。当内部键和表行主题之间的一对一映射发生故障时，这可能并且通常会导致一些混淆。

此故障只能在数据管理不善的情况下发生。但是，大多数情况下，您必须计划在现实世界中发生的一些数据错误管理。如果出现水资源管理不当，您不会计划供水系统发生故障。您没有计划每次数据管理不善时都会出现故障的信息系统。

话虽如此，如今大多数数据库设计人员都在为软件供应商工作，并且没有看到他们的产品用户对数据管理不当造成的问题。