CORS跨域资源共享漏洞

一个网站如果设置了 Access-Control-Allow-Origin: *，跨域同时允许携带凭证，资源那基本等于把家门钥匙插在锁上还贴了张纸条写“欢迎光临”。共享这不是漏洞理论风险，是跨域每天都在发生的真实配置错误。我见过一个后台管理系统，资源前端域名是共享 admin.example.com，后端接口在 api.example.com。漏洞开发图省事，跨域后端直接返回 Access-Control-Allow-Origin: *，资源还加上了 Access-Control-Allow-Credentials: true。共享浏览器立刻报错——因为规范禁止这种组合。漏洞但他们没去修根因，跨域反而写了个中间件，资源把请求头里的共享 Origin 直接反射回去，顺便带上 Credentials: true。结果呢？任何网站只要诱导已登录的管理员点一下链接，就能用管理员的身份读取所有用户数据。

CORS 本身不是漏洞，它是浏览器为了放宽同源策略而设计的一套协商机制。问题出在服务器端对 Origin 头的校验太随意。很多开发者以为只要返回了 Access-Control-Allow-Origin 就完事，根本不检查这个来源是否可信。更糟的是，有些代码直接拿 Origin 值拼接到响应头里，连白名单都不做。我曾在一次渗透测试中，用 Origin: https://evil.com 请求一个金融类接口，服务器原样返回 Access-Control-Allow-Origin: https://evil.com，并且 Allow-Credentials: true。这意味着我可以在自己控制的页面上，用受害者的 Cookie 发起跨域请求，读取他的账户余额、交易记录。整个过程不需要任何 XSS，纯粹是 CORS 配置失误。

还有一种更隐蔽的情况：null 源。当用户从本地 HTML 文件（file://）或者沙盒 iframe 发起请求时，Origin 头就是字符串 null。如果服务器把 null 加入了白名单，攻击者可以构造一个 data: URL 或者沙盒 iframe，让浏览器发送 Origin: null，从而绕过限制。我见过一个在线代码编辑器，它的后端就信任 null，结果任何人只要在本地保存一个 HTML 文件，就能以登录用户的身份调用它的 API。这种漏洞利用起来几乎零成本。

那怎么判断一个站点有没有 CORS 漏洞？简单。打开浏览器开发者工具，在控制台里执行 fetch('https://target.com/api/userinfo', { credentials: 'include'})，然后看响应头。如果 Access-Control-Allow-Origin 返回的是你当前页面的源，或者返回 * 且 Allow-Credentials 为 true（浏览器会拦截，但服务器配置本身就是错的），再或者返回 null 而你正好能控制一个 null 源的环境，那就有戏。更直接的办法：用 curl -H "Origin: https://attacker.com" -I https://target.com/api/endpoint，看返回的 Access-Control-Allow-Origin 是不是 https://attacker.com。如果是，并且 Allow-Credentials: true，那基本可以确定漏洞存在。

修复方案不复杂，但需要细心。永远不要反射 Origin 头，除非你有一个严格的、写死的白名单。白名单里不要用通配符，不要用正则匹配子域名（比如 *.example.com 很容易被 evil.example.com 绕过）。对于需要携带凭证的请求，Access-Control-Allow-Origin 必须是一个具体的源，不能是 *。如果业务不需要跨域，直接不返回任何 CORS 头。另外，Vary: Origin 这个响应头要加上，否则 CDN 或代理可能缓存错误的 CORS 响应，把本应只给 a.com 的凭证响应缓存后返回给 b.com。我见过一个案例，就是因为漏了 Vary: Origin，导致攻击者通过缓存投毒获取了其他用户的敏感数据。

最后说个真实观察：很多漏洞扫描器对 CORS 的检测非常粗糙，只测 Origin: https://evil.com 是否被反射，不测 null，不测子域名绕过，也不测 Vary 头。手动测试仍然不可替代。下次你看到某个 API 返回 Access-Control-Allow-Origin: * 时，别急着关掉页面——先看看它有没有同时返回 Access-Control-Allow-Credentials: true。如果有，那这个站点的用户数据可能正在裸奔。