重新审视不安全的直接对象引用（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将数字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个中正确执行，那一个未执行的端点也可能暴露大量信息。
• 尽可能为每个权限级别使用两个用户帐户进行测试。如果用户帐户权限级别太多，以至于这不切实际，至少使用具有最低权限和最高权限的用户帐户进行测试。
• 警惕误报。认证用户通常被允许在某些上下文中访问某些个人可识别信息。例如，仅对公司员工可访问的应用程序可能有一个公司目录，包含员工的联系信息，以便同事之间可以联系。销售代表的业务地址和业务电话号码可能适合在没有认证的情况下公开，而相同个人的家庭地址可能不适合向认证用户公开。上下文是关键。
• Burp Suite扩展Autorize有助于自动化访问控制检查，特别是当测试员可以访问多个用户帐户时。

给开发者的技巧 – 预防IDOR

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

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