利用Autorize发现访问控制漏洞

在OWASP Top 10最新修订中，失效的访问控制从第五位跃升至第一位。OWASP将访问控制定义为“执行策略，使用户不能在其预期权限之外进行操作”。因此，当我们在Web应用中发现自己能够以当前权限执行本不应允许的操作时，就发现了访问控制漏洞。除了常见之外，访问控制漏洞在利用时通常具有高影响。

访问控制漏洞以几种不同方式显现。目前，我们重点关注野外最常见的两种类型：垂直访问控制漏洞和水平访问控制漏洞。垂直访问控制漏洞发生在应用具有不同权限级别但未正确跨这些级别执行访问控制时。例如，同时拥有普通用户和更高权限管理用户的应用应限制普通用户执行管理用户专属操作。如果应用未阻止普通用户执行这些特权管理操作，则存在垂直访问控制漏洞。水平访问控制漏洞发生在用户具有相等权限但被限制访问/操作子集时。例如，允许患者登录查看个人医疗信息的自助医疗应用应限制用户访问其他患者数据。

在使用Autorize寻找访问控制漏洞之前，我们先进行一些设置。我们需要能够同时从多个认证上下文与目标应用交互，因此需要能够同时以不同用户账户登录应用。我偏好的方法是通过–no-remote和–p标志运行Firefox。

–no-remote标志告诉Firefox启动新实例且不与任何其他现有实例通信。-p标志允许选择配置文件。我为渗透测试Web应用创建了两个配置文件：“Primary”和“Secondary”。这些配置文件定制了有用扩展、用于高质量截图的UI修改以及一些配置（由Brian “BB” King提供），减少了Firefox通常产生的背景噪音。一旦我们启动了两个具有不同配置文件的独立Firefox实例，并将它们配置为通过Burp Suite代理请求，就可以启动Burp Suite并配置Autorize。

要安装Autorize，需选择Burp Suite顶部的“Extensions”选项卡，然后选择“BApp Store”选项卡，向下滚动到Autorize扩展，点击“Install”按钮。幸运的是，不需要Burp Suite Pro，Autorize可与Burp的免费社区版一起使用。

如果未使用其他利用Python的Burp Suite扩展，可能会看到需要下载和配置Jython的消息。要安装扩展，需下载Jython独立JAR文件。下载后，需通过打开“Extensions settings”界面在Burp Suite中配置其位置。

打开扩展设置界面后，浏览到“Python environment”部分，配置Jython独立JAR的位置。一旦为Burp Suite指定了Jython独立JAR，就应该能够安装Autorize。

接下来，我在测试主机上启动了OWASP故意易受攻击的Juice Shop应用实例，并在两个Web浏览器中浏览它。

为了测试不同上下文中的访问控制，我们首先必须确定应用如何管理会话和控制对特权请求的访问。我喜欢首先使用测试凭证认证到应用，并观察应用如何响应。通常，应用会在成功认证请求后发出会话令牌。这些值可以设置为cookie或在响应体中。通常，会返回多个值。首先，我浏览到Juice Shop应用的登录页面，并使用管理员凭证进行认证。

剧透警告！ 如果您想自己跟随操作，以下是我们将在本文中使用的相应Juice Shop账户的凭证：

用户名：admin@juice-sh.op 密码：admin123
用户名：mc.safesearch@juice-sh.op 密码：Mr. N00dles

打开登录页面，输入凭证并进行认证。认证后，我们想在Burp Suite中查看应用的响应。对于Juice Shop，应用未设置任何cookie，但返回了JSON内容。这部分JSON内容包含一个名为“token”的属性，其值似乎是JSON Web Token（JWT）。

我们不会在本文中深入探讨JWT，但BB King有一个优秀的网络广播，如果您想了解更多关于它们如何工作的信息。这里的重点是，这个JWT值是响应中唯一看起来可能用于会话管理和访问控制的东西，因此我们继续下一步。接下来，我们想通过使用新认证的会话发出特权请求来确认该值用于会话管理。特权请求的内容因应用而异，但修改认证用户自己账户的能力通常是一个安全的选择。因此，接下来我将导航到认证用户的账户设置并上传新的个人资料图片。

浏览到认证用户的账户，上传新的个人资料图片，个人资料图片已上传。当我们在Burp Suite中检查上传请求时，可以看到它包含了我们的JWT以及其他一些cookie。

接下来，我们将此请求发送到Burp Suite的Repeater，以准确确定哪些cookie是成功发出特权请求所必需的。首先，重放请求以确保按预期成功。接下来，我喜欢删除所有cookie以了解失败请求的样子。对于Juice Shop，我们可以看到应用响应HTTP 500内部服务器错误，并在正文中显示阻止了“非法活动”。

删除cookie后，请求失败。接下来，我们可以重放原始请求，逐个删除cookie，直到只剩下请求成功所需的令牌。对于提交大量额外cookie的应用，可以使用Request Minimizer扩展帮助修剪内容。如您所料，只需要我们的“token” JWT。

最小成功的特权请求。现在我们终于准备好开始使用Autorize测试访问控制。我们将在第二个浏览器中以较低权限的mc.safesearch@juice-sh.op账户登录Juice Shop。认证后，我们将此账户会话的JWT粘贴到Autorize配置界面并启用Autorize。

配置和启用Autorize。接下来，我们只需要使用高权限账户浏览应用。对于在高权限账户浏览器中发出的每个请求，Autorize将发出两个额外请求。其中一个请求将使用我们低权限账户的会话令牌，第二个请求将在未认证上下文中发出。Autorize比较每个请求的响应，并尝试确定访问控制是否已正确执行。结果显示在Autorize选项卡左侧的表中。

Autorize结果表。查看Autorize结果，我们可以看到给定请求的三个结果类别：

已执行！ – Autorize认为此请求的访问控制已正确执行。
已绕过！ – Autorize认为此请求的访问控制未正确执行。
是否执行??? – 请求的响应与原始请求的响应不同，但Autorize不确定访问控制是否已执行。

需要手动审查Autorize结果，因为请求的上下文和响应的内容决定了访问控制是否已应用或甚至是否应该应用。让我们看一些例子。首先，考虑一个对“Products”API方法的GET请求，该请求似乎允许低权限用户和未认证用户绕过访问控制。

产品请求。一旦在结果表中选择一行，我们可以在Autorize界面右侧查看所有三个请求及其响应的详细信息。

未认证请求的响应。对于所选请求，我们发现所有三个响应都是相同的。响应都包含了应用中出售产品的详细信息。未认证用户浏览应用中出售产品的能力几乎肯定是所需行为，因此这不构成访问控制漏洞。

接下来，考虑一个对“whoami”API方法的请求，Autorize似乎对此感到困惑。

Whoami请求 – Autorize不确定访问控制执行。这些请求的响应都不同，但响应的内容适合每个请求的认证上下文。也就是说，对于修改后的请求，应用返回了低权限用户的身份信息，而未认证请求的响应中未返回身份信息。

Whoami请求的响应。由于响应的内容适合每个请求的认证上下文，这不构成访问控制漏洞。

接下来，考虑一个在将产品添加到购物篮时发出的POST请求。Autorize报告此请求的访问控制已正确执行。

添加项目到购物篮的请求。查看响应，我们发现原始请求成功。

原始请求的成功响应。我们发现修改后的请求和未认证请求导致了错误响应。虽然这些错误响应有其他有趣之处，但它们不构成访问控制漏洞。

低权限请求的错误响应。最后，让我们检查在添加几个项目后查看高权限用户购物篮内容的请求。

检索购物篮内容的请求。检索认证用户购物篮的内容将被视为特权请求，因此这很有希望。当我们查看原始请求的响应时，我们发现高权限用户购物篮的内容在响应中。

原始请求的响应。查看低权限请求和未认证请求的响应，我们发现应用在这些响应中也返回了高权限账户的购物篮内容。

未认证请求响应中返回的特权数据。对此行为的进一步调查显示，单个购物篮通过请求URL末尾的数字索引。通过更改此数字，我们可以访问不同用户的购物篮内容。以下截图显示如何通过修改此值检索与不同用户关联的购物篮内容。

检索用户3的购物篮内容。检索用户8的购物篮内容。此行为显示应用受到称为不安全直接对象引用（IDOR）的访问控制漏洞的影响。访问控制漏洞的广泛存在和潜在影响意味着在执行Web应用渗透测试时，我们应特别关注此类情况。希望本文有助于演示如何使用Autorize更有效地识别这些漏洞。

脚注

利用Autorize工具发现访问控制漏洞

本文详细介绍了如何使用Burp Suite的Autorize扩展来检测Web应用中的访问控制漏洞，包括垂直和水平权限漏洞的识别方法，并通过OWASP Juice Shop实例演示检测流程。

利用Autorize发现访问控制漏洞