重访不安全的直接对象引用（IDOR）

| Melissa Bruno

新的一年已经开始，作为Black Hills Information Security的渗透测试员，回顾2023年时有一件事让我印象深刻：大量Web应用程序存在不安全的直接对象引用（IDOR）漏洞，这些漏洞严重性极高，因为它们暴露了高度敏感的数据。仅在2023年的最后四个月，我就发现了五起此类实例。这个问题以惊人的频率被忽略，甚至在 otherwise 相当安全的Web应用程序中也是如此。

对于那些不熟悉IDOR的人，建议查看Kelsey Bellew 2016年2月的博客文章（链接）以获取高级概述。我在这里也将覆盖IDOR的基础知识，以及预防和检测它的额外技巧。

本质上，IDOR发生在Web应用程序的认证用户能够通过更改HTTP请求中的标识符值来获得未授权访问资源时。这些标识符可能出现在HTTP请求的多个位置，例如URL查询字符串、HTTP POST参数，甚至cookie值中。

如果Web应用程序通过HTTP POST请求检索当前用户（ID为10001）的姓名、电子邮件地址和电话号码，而将请求中的ID更改为10009会返回完全无关用户的姓名、电子邮件地址和电话号码，那么IDOR就被成功利用了。这是应用程序在执行请求时未能检查用户是否有权访问特定信息集的结果。

以下是IDOR利用的逐步示例。首先，用户Sideshow Bob通过正常方式在URL /user/10001.json 访问他自己的数据。

返回上述数据的HTTP请求被Burp Suite拦截，并发送到Burp Suite Intruder模块。URI /user/10001.json 中的数字1被指定为有效载荷位置。

接下来，配置Burp Suite Intruder将数字0到9注入有效载荷位置。

最终的Burp Suite Intruder输出不仅返回了Sideshow Bob的数据，还返回了Bart Simpson在 /user/10009.json 的数据，这是Sideshow Bob本不应查看的。

IDOR根据定义只能在认证后执行，这可能会给一些开发者关于此问题的错误安全感。然而，如果易受攻击的Web应用程序有一个允许任何人创建新用户帐户的注册页面，那么信息就相当于公开的，因为互联网上的任何人都可以创建帐户并访问该数据。即使帐户注册受到限制，潜在的损害如此之大，以至于IDOR攻击的风险不应被轻视。

由于未受保护的标识符可能在应用程序执行各种操作时使用，IDOR的后果可能非常广泛。我在过去几个月中成功利用的IDOR攻击示例包括：

• 影响密码更改功能的IDOR，使得可以更改应用程序中任何用户的密码。
• 允许低权限用户执行管理功能的IDOR，例如用户模拟、密码更改以及修改或删除用户帐户。
• 披露系统中每个用户大量个人信息的IDOR，包括全名、邮寄地址、电子邮件地址、电话号码和其他敏感数据。如果这些信息最终出现在暗网的数据转储中，可能对公司的声誉造成严重损害。

预防和解决IDOR需要开发者和渗透测试员都积极主动，采取我下面概述的步骤。

给测试者的技巧 – 发现IDOR

• 在探索应用程序时检查HTTP请求，并使用Burp Suite Intruder测试IDOR，如本博客文章前面所述。在生产环境中执行这些测试时需要小心，但只要可能，明智的做法是注入数百或数千个数字作为有效载荷，因为数字标识符并不总是顺序的，可能需要大量猜测才能成功识别IDOR。
• 了解环境中哪些信息被视为敏感。有时哪些数据敏感是显而易见的，但有时不是。与利益相关者合作，了解他们最关心的数据。
• 一旦确定了哪些数据最敏感，识别哪些端点返回这些数据，并优先测试这些端点，特别是如果测试应用程序的时间有限。
• 要极其彻底。即使访问控制在100个端点中的99个都正确执行，那一个未执行的端点也可能暴露大量信息。
• 只要可能，为每个权限级别使用两个用户帐户进行测试。如果用户帐户权限级别太多以至于这不切实际，至少 aim 使用具有最低权限和最高权限的用户帐户进行测试。
• 警惕误报。认证用户通常 intended 在某些上下文中访问某些个人可识别信息。例如，仅对公司员工可访问的应用程序可能有一个公司目录，包含员工的联系信息，以便同事之间联系。销售代表的业务地址和业务电话号码可能适合在没有认证的情况下透露，而相同个人的家庭地址可能不适合 even 向认证用户透露。上下文是关键。
• Burp Suite扩展Autorize有助于自动化访问控制检查，特别是当测试员可以访问多个用户帐户时。

给开发者的技巧 – 预防IDOR

• 每次用户访问资源或执行操作时，都需要执行检查以验证用户是否有权访问该资源或执行该操作。
• 每次部署新代码时都需要考虑IDOR。大多数时候，当我发现IDOR时，访问控制在99%的情况下都正确执行，但一两个端点滑过任何先前使用的质量检查并造成严重破坏。
• 记住IDOR是一个业务逻辑缺陷。漏洞扫描器可能擅长检测跨站脚本等东西，但它们不会捕捉到细微的逻辑，如“客户A应该有权访问客户B的数据，但不能访问客户C的数据”。
• 使用不可预测的标识符，如GUID，可能使IDOR更难以发现，但它不能替代正确执行安全控制。如果GUID在应用程序中的任何地方披露或通过URL发送，IDOR仍可能被利用。
• 考虑将IDOR检查添加为集成测试或验收测试，如这里所述。

希望这篇文章让您对IDOR有了一些思考。鉴于这种漏洞的普遍性和后果，我们都需要尽自己的一份力量来留意它。