bra*_*rad 10 security api database-design
我听说有些人说你不应该把你的内部ID暴露给外面的世界(例如auto_increment'ng主键).
有人建议使用某种uuid列来代替查找.
我想知道为什么会这样建议,如果真的很重要的话.
使用uuid基本上只是混淆了id.重点是什么？我唯一能想到的是auto_incrementing整数显然指出了我的db对象的顺序.如果外部用户知道有一件事是在另一件事之前/之后创建的,那有关系吗？
或者纯粹是混淆id会阻止对特定对象的不同操作进行"猜测"？
在设计面向外部的API时,这是否是我应该考虑的问题？
您向恶意用户提供的有关您的应用程序及其布局的任何信息都可以并且将会用于您的应用程序。我们在（Web）应用程序安全中面临的问题之一是，在项目初期做出的看似无关紧要的设计决策在项目规模扩大时变成了致命弱点。让攻击者对实体的排序做出明智的猜测可能会以以下一些不相关的方式再次困扰您：
实体的 ID 将不可避免地在应用程序中的某个时刻作为参数传递。这将导致黑客最终能够提供他们通常不应该访问的应用程序参数。我个人已经能够查看我没有查看过的订单详细信息（在一个非常受欢迎的零售商的网站上），作为 URL 参数同样如此。我只是从我自己的合法订单中输入应用程序序列号。
了解限制或至少主键字段值的进展是 SQL 注入攻击的宝贵资料，我无法在此处涵盖其范围。
键值不仅用于 RDBMS 系统，还用于其他键值映射系统。想象一下 JSESSION_ID cookie 顺序是否可以预先确定或猜测？每个拥有反对意见的人都会在网络应用程序中重播会话。
还有更多我相信这里的其他人会想出的。
海豹突击队 6 并不一定意味着有 6 个海豹突击队。只是让敌人猜测。潜在攻击者花在猜测上的时间是你口袋里的更多钱，不管你怎么切。
与许多与安全相关的问题一样，这是一个微妙的答案 - kolossus 提供了一个很好的概述。
它有助于了解攻击者可能会如何破坏您的 API，以及发生了多少安全漏洞。
大多数安全漏洞是由错误或疏忽造成的，攻击者会寻找这些。试图破坏您的 API 的攻击者将首先尝试收集有关它的信息——因为它是一个 API，大概是您发布了详细的使用文档。攻击者将使用此文档，并尝试多种不同的方式使您的站点崩溃（从而暴露更多信息，如果他幸运的话），或以您未曾预料到的方式做出反应。
您必须假设攻击者有很多时间，并且会编写他们的攻击脚本以尝试每一条途径 - 就像一个拥有无限时间的窃贼，他在您的房子周围尝试每扇门和窗户，并使用从每次尝试中学习的锁头。
因此，如果您的 API 公开了类似 的方法getUserInfo(userid)，并且 userID 是一个整数，则攻击者将编写一个脚本从 0 向上迭代以找出您有多少用户。他们会尝试负数，并且max(INT) + 1. 在所有这些情况下，您的应用程序都可能泄漏信息，并且 - 如果开发人员忘记处理某些错误 - 可能会暴露比您预期的更多的数据。
如果您的 API 包含限制访问某些数据的逻辑 - 例如，您可以getUserInfo为朋友列表中的用户执行- 由于错误或疏忽，攻击者可能会幸运地获得一些数字，并且他会知道信息他正在与有效用户相关联，因此他们可以构建您的应用程序设计方式的模型。这相当于窃贼知道你所有的锁都来自一个制造商，所以他们只需要带上那个锁扣。
就其本身而言，这可能对攻击者没有任何好处——但它使他们的生活变得更轻松。
鉴于使用 UUID 或其他无意义标识符的努力，可能值得让攻击者更难。当然，这不是最重要的考虑因素 - 它可能不会成为保护 API 免受攻击者应该做的前 5 件事 - 但它有帮助。
很好的答案，我还会添加一个您不想公开内部自动递增ID的原因。
作为一家有竞争力的公司，我可以轻松地衡量您每周/每天/每小时获得多少新用户/订单/等。我只需要创建一个用户和/或订单，并从上次获取的内容中减去新的ID。
因此，不仅出于安全原因，还出于商业原因。