为何扫描工具无法检测出失效的访问控制漏洞？

失效的访问控制这个漏洞类别一直跻身OWASP Top Web应用程序安全风险列表，目前已对应用程序安全构成了严重的挑战。

访问控制漏洞让用户可以访问敏感数据，并使他们能够执行超出预期权限的操作，此类漏洞的后果可能导致数据泄露、篡改甚至销毁。

本文将讨论为什么即使在漏洞扫描和评估之后失效的访问控制漏洞仍然常常存在，以及手动渗透测试对于有效检测和缓解的重要性。

访问控制如同一种授权检查，确保对资源的访问和执行操作的能力授予了某些用户（如管理员），而不是其他用户（如普通用户）。这种检查主要在身份验证过程之后执行。

在Web应用程序安全中，访问控制与内容、功能的预期用途以及用户扮演的各种角色密切相关。比如说，这可能包括阻止低权限用户执行管理员功能、阻止用户访问另一用户的资源，或者基于上下文因素授予或拒绝对资源或功能的访问。

在处理包含大量用户角色和功能的大型复杂应用程序时，正确实施访问控制很快会变得困难重重。

失效的访问控制顾名思义是访问控制没有按预期工作，这实际上与我们上面提到的恰好相反，后面附有一些详细的例子。

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

以允许普通用户查看和编辑帐户信息的应用程序为例。每个帐户被分配了一个用户ID，编辑请求被发送后，应用程序根据请求中所含的ID确定要更新哪个帐户。在这种场景下，攻击者可以通过将用户ID改为受害者的ID来操纵旨在更新帐户的出站请求。

如果没有实施适当的访问控制，受害者的帐户将收到编辑——这是直接影响完整性的IDOR漏洞。假设攻击者更改了受害者的电子邮件地址，随后提出了重置密码请求，这将允许他们设置一个新密码，最终接管受害者的帐户。

以下是失效的访问控制这个话题常出现的另两个术语：水平特权升级和垂直特权升级。

1. 水平特权升级

水平特权升级指以类似权限获得对另一个帐户资源的访问。在前面例子中，如果受害者帐户拥有与攻击用户（即普通用户）相似的权限，它也叫水平特权升级。简而言之，除了可以访问另一个帐户的资源外，攻击者并不获得任何额外的权限。

2. 垂直特权升级

垂直特权升级指以更大的权限获得对另一个帐户资源的访问。在前面例子中，如果受害者帐户拥有更高的权限（比如管理员），这就叫垂直特权升级。攻击者可以滥用额外的权限对应用程序进行进一步的攻击。

以允许用户借助内置预览器功能查看发票的应用程序为例。发票存储在托管应用程序的同一台服务器上，位于以下绝对路径：

/var/www/html/vulnerable-application/invoices/

当用户点击其配置文件下显示的其中一张发票时，将发送以下请求：

图1. 检索发票的合法请求

预览器的工作原理是将“file”参数的值附加到特定的绝对路径。然后，它将检索该文件的内容，然后返回给请求用户。

/var/www/html/vulnerable-application/invoices/invoice-2024-12-24.pdf

然而与IDOR场景一样，攻击者也可以在这里截获出站请求，将“file”参数修改为不打算检索的文件。

图2. 试图检索非预期文件的已被修改的请求

如果没有实施适当的访问控制，预览器现在将尝试检索：

/var/www/html/vulnerable-application/invoices/../../../../../etc/hosts

点-点-斜杠（../）序列回退路径中的一个目录（遍历到父目录）。我们有五个这样的序列，这意味着最后将出现在文件系统的根路径（/）。我们由此进入etc目录，我们从该目录请求hosts文件。

现在，hosts文件（将主机名映射到IP地址的默认文件）很可能不是攻击者的首选。我们在这里使用它只是为了展示在应用程序目录之外检索文件（又叫本地文件包含）的可能性。攻击者会改而尝试检索应用程序目录内外的敏感文件。

我们将通过客户评估的真实例子来说明。该应用程序具有多个用户角色，所有角色似乎精心设置，并适当隔离。由于实施了大量的访问控制，所有试图提升普通用户的特权、访问非预期资源以及执行特权操作的活动一律被阻止。

然而我们在全面分析各种用户角色之后注意到了一处差异。针对上下文，某些角色可以编辑和删除其他用户的帐户，但只能对权限较低的帐户执行此操作，拥有这些权限的用户也不能对自己的帐户执行这些操作。为任何高权限用户分配低权限角色的可能性被忽视，实际上删除了所有权限，对帐户进行了降级。从技术上讲，这些被降级的帐户现在满足被权限较低的帐户编辑和删除的条件。

图3. 落实了防止权限升级的访问控制，但没有落实防止权限降级的访问控制

由于正确实施访问控制的难度随应用程序的复杂性而加大，识别访问控制问题的难度也随之加大。若要检测这些控制，手动安全测试是最好的方法，因为它需要更深入地了解上下文和应用程序的预期用途。

漏洞扫描器是识别应用程序中缺陷的一种流行解决方案。然而，仅仅依赖它们会给应用程序的所有者带来一种虚假的安全感，虽然这些扫描器可以持续快速地提供扫描结果，但在检测新颖的攻击途径或需要直觉和推理的其他漏洞方面的能力有限。

为了进一步阐明这点，不妨将访问控制漏洞与另一个复杂性相似、需要人工推理的常见漏洞：业务逻辑漏洞进行比较。

当应用程序的设计、实施或内部流程偏离预期用途时，就会出现业务逻辑漏洞，一些独特而常见的例子包括订购负数量的产品或多次兑换相同的折扣码。

漏洞扫描器的局限性变得很明显，扫描器无法识别应用程序的预期行为。从它的角度来看，负数仍然是数字，重复使用某个功能未必是坏事。与跨站脚本（XSS）和SQL注入等其他漏洞不同，扫描器无法简单地在这里提供输入，然后在应用程序的响应中查找预定义的模式，以确定是否存在漏洞。

从进攻性安全的角度来看，从失效的访问控制或业务逻辑类别中捕获漏洞需要对应用程序具有相同的认识和上下文理解，在许多情况下也存在相当大的重叠。比如，在评估文件上传功能时，一个测试用例可能是在只允许图像文件的情况下，上传一个意外的文件类型，比如包含JavaScript载荷的SVG文件，虽然SVG满足广泛的图像标准，但其含有的JavaScript不易被受害者的浏览器解析。

在实际场景中，还会增加权限、角色、外部集成、第三方库和依赖项等形式的额外复杂性，而漏洞扫描器几乎不可能确定这种针对特定上下文的复杂性。

图4. 访问控制的复杂性

参考及来源：https://outpost24.com/blog/broken-access-control-and-scanners