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

新的一年已经开始，作为Black Hills Information Security的渗透测试员，回顾2023年时，有一件事让我深感震惊：大量Web应用程序存在不安全的直接对象引用（IDOR）漏洞，这些漏洞的严重性极高，因为它们暴露了高度敏感的数据。仅在2023年的最后四个月，我就发现了五个这样的实例。这个问题以惊人的频率被忽略，甚至在那些其他方面相当安全的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 – 有效载荷位置配置

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

Burp Suite Intruder – 有效载荷集配置

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

Burp Suite Intruder结果 – 未授权访问其他用户数据

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

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

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

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

测试员技巧 – 发现IDOR

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

开发者技巧 – 预防IDOR

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

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