Broken Object Level Authorization in the Wild: An Empirical Taxonomy from 100+ Bug Bounty Disclosures
本文对 107 份分类后的漏洞赏金报告进行了大规模实证分析，揭示出操作级对象 BOLA 是一个占主导地位但代表性不足的漏洞家族，并证明依赖平台标签会显著高估对象级授权失效的普遍性。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正走在一个庞大、高科技的公寓小区里。你有一张门禁卡，可以进入大楼（身份验证），但真正的安全机制本应检查你被允许进入的是哪一套具体的公寓。
对象级授权失效（BOLA） 就是当大楼的保安忘记将你的门禁卡与你试图打开的具体房号进行核对时发生的情况。你可能是一名有效的住户，但你试图打开 402 室，而保安只是说：“没问题，请进”，却没有核实 402 室是否属于你。
这篇论文是对来自漏洞赏金计划（黑客因此类发现而获得报酬）的107 份真实安全报告进行的深入调查。研究人员希望超越“理论性”的安全建议，去审视现实世界中实际发生的情况。
以下是他们研究发现的分解，使用了简单的类比：
1. “标签噪声”问题（误报）
研究人员首先查看了 HackerOne 上标记为"IDOR"（此类漏洞的常见名称）的 200 份报告。
- 发现： 其中只有**42%**的报告确实是真实问题。
- 类比： 想象一个火警系统响了 200 次。研究人员发现，39% 的时候根本没有火灾——那只是有人在烤面包、洗热水澡产生的蒸汽，或者是传感器故障。
- 启示： 仅仅因为一个系统被标记为"IDOR"，并不意味着它确实存在特定的、危险的“对象级授权失效”漏洞。安全团队往往因为过度信任标签而高估了风险。
2. 两大主要反派（分类法）
研究人员将真实的漏洞分为了六类。其中两类是明显的“赢家”，占了所有案例的近80%：
反派 A：“直接对象引用”（电话簿把戏）
- 是什么： 你看到一个 URL 如
website.com/invoice/101。你将数字改为102，突然之间你看到了别人的发票。 - 类比： 就像你走到一排邮箱前。你知道你的邮箱是 101 号。你尝试 102 号，发现锁坏了，于是你打开它并阅读了邻居的邮件。
- 频率： 这种情况发生在**37%**的案例中。
- 是什么： 你看到一个 URL 如
反派 B：“操作级对象”（破坏者）
- 是什么： 这是一个大惊喜。这不仅仅是读取别人的数据；而是修改或删除它。
- 类比： 你走到邻居的邮箱前（你本不该触碰），但你没有只是阅读邮件，而是把邮箱从墙上扯下来，删除他们的邮件，或者转走他们的钱。
- 频率： 这种情况发生在**42%**的案例中。
- 为何重要： 大多数安全指南都关注“读取”数据。这篇论文指出：“嘿，坏蛋们实际上比窥探更频繁地破坏和修改数据。”
3. 其他狡猾的反派
剩余的 20% 漏洞更为复杂：
- 租户隔离失效： 你在一栋共享办公楼里。你试图打开另一家公司的办公室套间，但锁失效了。
- 工作流上下文失效： 你被一家公司解雇了，但系统仍然允许你访问你曾经参与项目的“归档”文件，因为系统忘记更新你的状态。
- 链式泄露： 你无法猜出 ID，但你在应用的其他部分（如收据）发现了一个 ID 列表，并利用该列表闯入他人的账户。
- 对象重绑定： 你通过更改请求中的隐藏字段（例如更改文档上的“所有者”名称），欺骗系统认为你拥有该对象。
4. “垂直”惊喜（电梯之旅）
通常，我们认为这些攻击是“水平”的（用户 A 从用户 B 那里窃取东西）。
- 发现： 有12%的情况下，普通用户成功访问或删除了属于管理员的内容。
- 类比： 公寓小区里的一名普通住户设法走进了大楼经理的私人办公室，并删除了主钥匙。
- 启示： 这是一个巨大的风险，大多数安全检查清单都忽略了这一点，因为它们假设“管理员是安全的”。
5. “魔法”ID 行不通
开发人员常想：“如果我们不使用像 1、2、3 这样的简单数字，而是使用长长的随机代码（UUID）或编码字符串，我们就安全了。”
- 发现： **39%**的成功攻击使用了这些“复杂”的 ID。
- 类比： 坏蛋们找到了解码邮箱上“秘密代码”的方法，意识到那只是一个隐藏的数字，然后只需递增数字就能拿到下一个邮箱。
- 启示： 隐藏 ID 并不能解决问题。无论 ID 看起来如何，服务器仍然需要检查你是否拥有该对象。
6. "GraphQL"漏洞
论文发现，许多现代应用使用一种称为 GraphQL 的系统。这些系统使用“全局 ID"（如 gid://hackerone/Report/123）。
- 发现： 攻击者发现，如果解码这些 ID，会揭示其底层的顺序数字，使他们能够轻松猜测下一个 ID。
- 启示： 仅仅因为一个 ID 看起来像是一串复杂的字符，并不意味着它是随机的。
给普通人的总结
这篇论文告诉我们：
- 不要信任标签： 仅仅因为一个系统被标记为存在特定漏洞，并不意味着它确实以那种特定方式被破坏了。
- 坏蛋具有破坏性： 他们不仅仅是在窃取数据；他们删除和修改数据的频率比我们想象的要高。
- 秘密代码不够用： 如果服务器不检查谁拥有数据，使用复杂的 ID 也阻止不了黑客。
- 普通用户也能伤害管理员： 普通用户账户有时可以闯入“老板”的东西。
论文结论指出，安全测试需要改变。我们需要停止仅仅检查你是否能读取他人的数据，转而检查你是否能删除或修改它，并且我们需要测试普通用户是否能意外地（或故意地）闯入管理员的领域。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。