003 HTTP 访问控制 (CORS)

跨域资源共享 (CORS) 是一种机制，它使用额外的 HTTP 标头来允许用户代理获得从服务器访问所选资源的权限，该服务器位于其所属的不同源（域）中。当代理从与生成它的文档不同的域、协议或端口请求资源时，它会创建一个跨域 HTTP 请求。

默认情况下，浏览器允许链接到位于所有类型域中的文档，如果我们从 HTML 或使用 DOM API（反过来构建 HTML）的 Javascript 进行链接。然而，当涉及到 Javascript (AJAX) 时，同样的情况不会发生`peticiones HTTP asíncronas`，无论是通过 XMLHttpRequest、fetch 还是出于相同目的的类似库。

使用这种类型的异步请求，默认情况下不允许位于当前页面以外的域中的资源。这就是通常所说的 CORS 保护。其目的是使向给定站点添加第三方资源变得困难。

我留给你一张从下一页拍摄的图片，[它](https://lenguajejs.com/javascript/peticiones-http/cors/)以非常简单的方式展示了这种保护的工作原理。

![](/media/202204/2022-04-24_212238_211173.png)

# **运作**

在最简单的情况下，浏览器脚本发出 GET 请求以从另一个域中的服务器获取资源。根据该服务器的 CORS 配置，如果请求来自允许发送 GET 请求的域，则跨域服务器将通过返回所请求的资源来响应。

如果请求域或 HTTP 请求类型未授权，则该请求将被拒绝。但是，使用 CORS，可以在实际发送之前提出初步请求。在这种情况下，发出一个初步请求，其中发送 OPTIONS 访问请求操作。如果源服务器的 CORS 配置授予对请求域的访问权限，则服务器将发送一个初步响应，其中包含请求域可以对请求的资源发出的所有 HTTP 请求类型的列表。

![](/media/202204/2022-04-24_212246_356591.png)

# **CORS 键标头**

有许多与 CORS 相关的 HTTP 标头，但以下三个响应标头对安全性最重要：

- `Access-Control-Allow-Origin`指定哪些域可以访问域的资源。例如，如果 requester.com 想要访问 provider.com 上的资源，开发人员可以使用此标头安全地授予 requester.com 访问 provider.com 上的资源的权限。
- `Access-Control-Allow-Credentials`指定浏览器是否会随请求发送 cookie。仅当 allow-credentials 标头设置为 true 时才会发送 Cookie。
- `Access-Control-Allow-Methods`指定可以使用哪些 HTTP 请求方法（GET、PUT、DELETE 等）来访问资源。此标头允许开发人员通过指定在 requester.com 请求访问 provider.com 资源时哪些方法有效来提高安全性。

# **CORS 错误配置**

## **利用 CORS 标头中配置错误的通配符 (\*)**

当涉及到 CORS 错误配置时，最常见的示例之一是滥用通配符，因为`*`允许域请求资源。这通常是默认设置的，这意味着任何域都可以访问该站点的资源。例如，让我们看一下以下请求：

```
GET /api/userinfo.php
Host: www.victim.com
Origin: www.victim.com
```

发送上述请求时，将返回带有 Access-Control-Allow-Origin 标头设置的响应。让我们看看响应代码。

```
HTTP/1.0 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
```

在这种情况下，标头设置为通配符 (*)。这意味着任何域都可以访问资源。

在下图中，我们将请求的来源从受害者的域更改为攻击者的域（简而言之，将敏感数据发送到外部服务器）。

![](/media/202204/2022-04-24_212257_627687.png)

以下是我们收到的回复。通配符在源头响应中显示为`Access-Control-Allow-Origin: *`，这意味着受害域允许访问所有站点的资源。

由于该站点共享来自任何站点的信息，因此我们可以更进一步并使用我们自己的域来利用它。我们创建名为[https://testing.aaa.com](https://testing.aaa.com/)的域，并将其嵌入漏洞利用代码以从易受攻击的应用程序中窃取敏感信息。当受害者在浏览器中打开[https://testing.aaa.com](https://testing.aaa.com/)时，浏览器会检索敏感信息并将其发送到攻击者的服务器。

## **信任通配符预域作为来源**

利用 CORS 错误配置的另一种常见方法是允许与部分验证的域名共享信息。例如，让我们看一下以下请求：

```
GET /api/userinfo.php
Host: provider.com
Origin: requester.com
```

对上一个请求的响应是：

```
HTTP/1.0 200 OK
Access-Control-Allow-Origin: requester.com
Access-Control-Allow-Credentials: true
```

我们假设开发人员已配置 CORS 来验证“Origin header” URL，白名单域只是“requester.com”。现在，当攻击者创建如下请求时：

```
GET /api/userinfo.php
Host: example.com
Connection: close
Origin: attackerrequester.com
```

服务器将响应：

```
HTTP/1.0 200 OK
Access-Control-Allow-Origin: attackerrequester.com
Access-Control-Allow-Credentials: true
```

发生这种情况的原因可能是后端验证配置错误，如下所示：

```
if ( $ _SERVER [' HTTP_HOST '] == '*requester.com') 
{ //访问数据
else{ //未授权访问 } 
}
```

这可以像我们对第一个 CORS 错误配置所做的那样被利用。我们可以创建一个新域，其名称由列入白名单的域名组成。然后在该恶意站点中嵌入可从受害者站点获取敏感信息的漏洞。

# **缓解措施**

要安全地实施 CORS，您需要将验证列表`whitelist`与`Access-Control-Allow-Origin`标识哪些特定域（例如，我们的公司域）可以访问资源相关联。然后，当域请求访问时，该应用程序可以根据该列表进行验证。我们也不想将其 Access-Control-Allow-Origin 标头设置为 NULL，因为攻击者可以发送带有 NULL 来源的请求，从而绕过其他控件。

同样，`Access-Control-Allow-Methods`我们必须准确指定哪些方法对已批准的域有效。有些可能只需要查看资源，而另一些则需要阅读和更新它们等。

攻击者很容易设置流量查看器并查看从您的站点来回发送的请求以及响应是什么。由此，他们可以确定我们的网站是否容易受到基于 CORS 的攻击。

因此，我们必须验证请求我们站点资源的每个域，以及如果我们的访问请求获得批准，其他域可能使用的方法。我们可以通过查看应用程序响应中先前的标头并验证这些标头的值来轻松识别 CORS 安全漏洞。使用开源扫描器也是发现 CORS 安全漏洞的好方法。