1. 项目概述：为什么CORS配置漏洞值得你立刻关注
如果你是一名Web开发者、安全工程师或者渗透测试人员，最近在浏览器控制台里看到过“has been blocked by CORS policy: response to preflight request doesn't pass”或者“has been blocked by CORS policy: permission was denied for this request to a”这类错误，那你已经和CORS（跨域资源共享）打过交道了。这不仅仅是开发时的一个小麻烦，它背后隐藏着一类广泛存在且极易被忽视的安全风险——CORS配置漏洞。我见过太多项目，前端和后端联调时为了图省事，直接在服务器上配置一个 Access-Control-Allow-Origin: * ，觉得功能通了就万事大吉。殊不知，这个看似简单的配置，可能已经为攻击者打开了一扇窃取用户数据的大门。
CORS协议的本意是好的，它是在严格的同源策略（SOP）上开一个可控的口子，让现代Web应用能安全地进行跨域通信。但问题就出在这个“可控”上。服务器返回的 Access-Control-Allow-Origin 等响应头，本质上是一份由服务器单方面声明的“访问控制策略”。如果这份策略写错了，比如错误地信任了不该信任的域名，浏览器的安全机制就会被绕过。攻击者可以构造一个恶意网站，诱骗用户访问，然后利用目标网站错误的CORS配置，悄无声息地读取用户在目标网站上的敏感数据，比如私信内容、账户余额、甚至执行敏感操作。
手动检测这些配置错误非常繁琐，你需要构造各种可能的Origin值，观察服务器的响应头，判断逻辑是否存在缺陷。这就是为什么我们需要自动化工具。今天要深入拆解的 CORScanner ，正是由清华大学与360联合研究团队在2018年USENIX Security顶级会议上发表相关研究后，开源的一款专门用于自动化检测CORS配置漏洞的工具。它不是一个简单的端口扫描器，而是一个基于对CORS协议深度理解和大量实战经验积累的“策略分析器”。接下来，我将带你从原理到实战，彻底掌握如何使用CORScanner，并理解你发现的每一个漏洞背后意味着什么。
2. CORS配置漏洞核心原理深度拆解
在拿起工具之前，我们必须搞清楚我们要找的是什么。CORS配置漏洞的本质，是服务器声明的跨域访问策略与其真实的安全意图不一致，导致了权限的意外扩大。根据前述的权威研究，主要可以归纳为七大类，每一类都有其独特的成因和危害。
2.1 反射Origin头：最危险的宽松配置
这是最常见也最危险的一种错误。开发者的意图可能是想动态地允许多个可信域名访问。一种偷懒的做法是直接从请求头中读取 Origin 的值，然后不经任何校验，直接将其设置为 Access-Control-Allow-Origin 响应头的值。
错误配置示例（Nginx）：
add_header Access-Control-Allow-Origin $http_origin always;
add_header Access-Control-Allow-Credentials true always;
漏洞原理： 这种配置意味着，无论请求来自哪个网站（ evil.com 、 attacker.net ），服务器都会回答：“是的，我允许你这个来源读取我的数据。” 这完全绕过了同源策略。如果这个接口还配置了 Access-Control-Allow-Credentials: true （允许携带Cookie等凭证），那么攻击者就可以在其控制的恶意页面上，用用户的身份（携带用户的会话Cookie）向该接口发起请求，并直接读取返回的敏感数据。
注意： 很多开发框架或中间件的“宽松模式”默认就是这种反射行为，在启用时需要极度警惕。
2.2 Origin校验逻辑缺陷：信任域的意外“扩大”
当开发者意识到不能无条件反射Origin后，通常会加入校验逻辑，只允许特定的域名列表。但校验逻辑的编写极易出错，主要分为四类：
- 前缀匹配错误： 意图允许
example.com，但校验逻辑是origin.startswith(“example.com”)。这会导致example.com.attacker.com也被允许，因为后者确实以example.com开头。 - 后缀匹配错误： 意图允许
example.com，但校验逻辑是origin.endswith(“example.com”)。这会导致attacker-example.com也被允许。 - 正则表达式点号未转义： 意图允许
www.example.com，使用正则www.example.com进行匹配。这里的点号.在正则中代表“任意单个字符”，因此wwwaexample.com或www- example.com也会被匹配。 - 包含匹配错误： 意图允许
example.com，但校验逻辑是“example.com” in origin。这会导致myexample.com或example.com.attacker.com都被允许。
这些错误都使得信任域的范围超出了开发者的本意，为攻击者提供了可乘之机。
2.3 信任null Origin：被忽视的“空”值风险
Origin: null 是一个特殊的取值。它可能出现在一些特定场景，比如从本地 file:// 协议打开的HTML文档发起的请求，或者由沙盒（sandbox） iframe 生成的文档发起的请求。有些开发者为了方便本地测试或特定功能，会配置 Access-Control-Allow-Origin: null 。
漏洞原理： 攻击者可以通过构造一个沙盒 iframe ，其 src 是 data:text/html,<script>…</script> ，在这个沙盒环境中发起的跨域请求，其 Origin 头就是 null 。如果目标服务器配置了信任 null 且允许凭证，那么这个沙盒页面就能以当前用户的身份读取目标服务器的数据。这意味着， 任何网站都可以通过这种方式攻击配置了信任null的站点 。
2.4 HTTPS域信任HTTP域：安全协议的降级
这是一个在混合内容（HTTP/HTTPS）环境下容易出现的错误。假设一个HTTPS站点 https://api.secure.com 配置了CORS，错误地允许了HTTP来源 http://api.secure.com 。
攻击场景（中间人攻击）：
- 用户访问了一个HTTP网站
http://example.com（或攻击者通过中间人劫持将某个HTTPS请求降级到HTTP）。 - 该HTTP网站被攻击者控制或注入恶意脚本。
- 恶意脚本向
https://api.secure.com发起跨域请求。由于服务器配置为信任http://api.secure.com，而浏览器发送的Origin头正是http://api.secure.com，请求被允许。 - 攻击者通过控制的HTTP站点作为跳板，间接读取了HTTPS站点的敏感内容，破坏了HTTPS的机密性。
2.5 信任自身全部子域：横向渗透的跳板
许多大型网站拥有多个子域，如 www.example.com 、 api.exa
扫一扫
723
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
