漏洞系列之——CORS配置错误

最新推荐文章于 2025-10-27 13:26:10 发布

原创最新推荐文章于 2025-10-27 13:26:10 发布 · 1.5w 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#网络 #https #web crawler

web安全专栏收录该内容

19 篇文章

订阅专栏

本文探讨了CORS配置错误导致的安全隐患，重点介绍了允许任意来源请求、未授权凭据暴露及通配符来源等问题，以及如何通过精确设置Access-Control-Allow-Origin和Credentials来防止这类攻击。漏洞修复建议提供了一套最佳实践方法。

CORS配置错误

漏洞描述

CORS 错误配置。允许攻击者代表用户发出跨源请求，因为应用程序没有将 Origin 标头列入白名单并且具有 Access-Control-Allow-Credentials: true 意味着我们可以使用受害者的凭据从攻击者的站点发出请求。

漏洞等级

高危

漏洞危害

那么，CORS的漏洞到底出现在哪里呢？

1：CORS服务端的 Access-Control-Allow-Origin 设置为了 *，并且 Access-Control-Allow-Credentials 设置为false，这样任何网站都可以获取该服务端的任何数据了。

2：有一些网站的Access-Control-Allow-Origin他的设置并不是固定的，而是根据用户跨域请求数据的Origin来定的。这时，不管Access-Control-Allow-Credentials 设置为了 true 还是 false。任何网站都可以发起请求，并读取对这些请求的响应。意思就是任何一个网站都可以发送跨域请求来获得CORS服务端上的数据。

（1）Access-Control-Allow-Origin

该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。

（2）Access-Control-Allow-Credentials

该字段可选。它的值是一个布尔值，表示是否允许发送Cookie。默认情况下，Cookie不包括在CORS请求之中。设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。这个值也只能设为true，如果服务器不要浏览器发送Cookie，删除该字段即可。

（3）Access-Control-Expose-Headers

该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。上面的例子指定，getResponseHeader('FooBar')可以返回FooBar字段的值。

Origin: https://evil.com
Access-Control-Allow-Credential: true
Access-Control-Allow-Origin: https://evil.com 或者 Access-Control-Allow-Origin: null

Access-Control-Allow-Origin:   允许进行跨域请求的域名
Access-Control-Allow-Methods:  允许进行跨域请求的方式
Access-Control-Allow-Headers:  允许进行跨区请求的头部

易受攻击的示例：

Null Origin

服务器可能没有反映完整的Origin标头，但null允许来源。这在服务器的响应中看起来像这样：

GET /endpoint HTTP/1.1
Host: victim.example.com
Origin: null
Cookie: sessionid=... 

HTTP/1.1 200 OK
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

没有凭据的通配符来源

如果服务器以通配符来源响应*，则浏览器永远不会发送 cookie。但是，如果服务器不需要身份验证，仍然可以访问服务器上的数据。这可能发生在无法从 Internet 访问的内部服务器上。然后，攻击者的网站可以转入内部网络，无需身份验证即可访问服务器的数据。

 *是唯一的通配符来源
https: //*.example.com无效

GET / endpoint HTTP / 1.1 
Host: api.internal.example.com 
Origin: https: // evil.com
 
HTTP / 1.1  200 OK 
Access - Control - Allow - Origin: *

扩展源/正则表达式问题

有时，原始来源的某些扩展不会在服务器端过滤。这可能是由于使用错误实现的正则表达式来验证原始标头造成的。

在这种情况下，任何插入在前面的前缀都example.com将被服务器接受。

GET /endpoint HTTP/1.1
Host: api.example.com
Origin: https://evilexample.com

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://evilexample.com
Access-Control-Allow-Credentials: true

漏洞修复方案

（最理想的）
Access-Control-Allow-Origin: https://attacker.com
Access-Control-Allow-Credentials: true