19

我听一些人说你永远不应该将你的内部 id 暴露给外界（例如 auto_increment'ng 主键）。

有些人建议使用某种 uuid 列来代替查找。

我真的很想知道为什么会建议这样做，以及它是否真的很重要。

使用 uuid 基本上只是混淆了 id。重点是什么？我唯一能想到的是 auto_incrementing 整数显然指出了我的数据库对象的顺序。外部用户是否知道一件事是在另一件事之前/之后创建的？

或者纯粹是混淆 id 会阻止“猜测”对特定对象的不同操作？

在设计面向外部的 API 时，这甚至是我应该考虑的问题吗？

4

3 回答 3

14

很好的答案，我将添加另一个原因来说明您不想公开内部自动递增 ID 的原因。
作为一家有竞争力的公司，我可以轻松地衡量您每周/每天/每小时获得多少新用户/订单/等。我只需要创建一个用户和/或订单，然后从上次得到的 ID 中减去新 ID。
因此，不仅是出于安全原因，也是出于商业原因。

于 2016-03-01T11:34:39.007 回答
9

您向恶意用户提供的有关您的应用程序及其布局的任何信息都可以并将用于您的应用程序。我们在（Web）应用程序安全中面临的问题之一是，在项目初期做出的看似无害的设计决策在项目规模扩大时变成了致命弱点。让攻击者对实体的顺序做出明智的猜测可能会以以下一些无关的方式再次困扰您：

  1. 实体的 ID 不可避免地会在您的应用程序中作为参数传递。这将导致黑客最终能够提供他们通常不应该访问的应用程序参数。我个人能够查看我没有业务查看的订单详细信息（在一个非常受欢迎的零售商网站上），作为 URL 参数同样如此。我只是从我自己的合法订单中输入应用程序序列号。

  2. 了解限制或至少了解主键字段值的进展对于 SQL 注入攻击来说是非常宝贵的素材，这里我无法涵盖其范围。

  3. 键值不仅用于 RDBMS 系统，还用于其他键值映射系统。想象一下 JSESSION_ID cookie 顺序是否可以预先确定或猜测？每个具有相反拇指的人都将在 Web 应用程序中重播会话。

还有更多我相信这里的其他人会想出的。

海豹突击队 6 并不一定意味着有 6 个海豹突击队。只是让敌人猜测。潜在攻击者花在猜测上的时间是你口袋里的更多钱。

于 2012-09-12T07:10:29.567 回答
6

与许多与安全相关的问题一样，这是一个微妙的答案——kolossus 提供了一个很好的概述。

它有助于了解攻击者可能如何破坏您的 API，以及发生了多少安全漏洞。

大多数安全漏洞都是由错误或疏忽引起的，攻击者会寻找这些。试图破坏您的 API 的攻击者首先会尝试收集有关它的信息 - 因为它是一个 API，所以您可能会发布详细的使用文档。攻击者将使用此文档，并尝试许多不同的方法来使您的站点崩溃（如果幸运的话，从而暴露更多信息），或者以您未预料到的方式做出反应。

你必须假设攻击者有很多时间，并且会编写他们的攻击脚本以尝试每条途径 - 就像一个有无限时间的窃贼，他在你的房子里走来走去尝试每一扇门和窗户，并且从每次尝试中学习的开锁器。

因此，如果您的 API 公开了类似的方法getUserInfo(userid)，并且 userID 是一个整数，那么攻击者将编写一个脚本从 0 向上迭代以找出您有多少用户。他们会尝试负数，并且max(INT) + 1. 在所有这些情况下，您的应用程序都可能泄漏信息，并且 - 如果开发人员忘记处理某些错误 - 可能会暴露比您预期更多的数据。

如果您的 API 包含限制对某些数据的访问的逻辑 - 例如，您可以getUserInfo为好友列表中的用户执行 - 攻击者可能会因为错误或疏忽而幸运地获得一些数字，并且他会知道这些信息他正在与一个有效的用户建立联系，因此他们可以建立一个应用程序设计方式的模型。这相当于一个窃贼知道你所有的锁都来自一个制造商，所以他们只需要带上那个开锁器。

就其本身而言，这可能对攻击者没有任何好处 - 但它会让他们的生活变得更轻松。

考虑到使用 UUID 或其他无意义的标识符的努力，可能值得让攻击者更加困难。当然，这不是最重要的考虑因素——它可能不会成为保护 API 免受攻击者应该做的前 5 件事——但它会有所帮助。

于 2012-09-12T09:08:57.563 回答