CORS配置错误为何仍是攻击者的金矿

丑陋的真相

开发者常常为了"让功能正常工作"而错误配置CORS，无意中在应用防御中留下了巨大的安全漏洞。

实际危害

会话劫持：窃取已登录用户的会话数据
未授权API调用：利用CORS滥用经过身份验证的API
完全账户接管：结合IDOR或JWT问题升级为完全入侵

攻击场景：bank.com的已登录用户访问恶意网站evil.com。如果bank.com的CORS设置薄弱，攻击者可以通过隐藏请求悄无声息地窃取用户的财务数据。

开发者常犯的错误配置（可被利用）

1. 通配符(*) + 凭证

1
2


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

违反规范，但某些自定义服务器允许此配置。 利用方式：攻击者使用cookie通过恶意网站获取敏感信息。

2. Origin头反射

1

Access-Control-Allow-Origin: <Origin头中的值>

没有源站白名单 = 巨大风险。 利用方式：设置Origin: evil.com — 服务器反射回该值，攻击者获得完全访问权限。

3. 子域通配符

1

Access-Control-Allow-Origin: https://*.target.com

误导性安全：*.target.com ≠ test.target.com.evil.com 利用方式：控制合法子域并从该子域提供恶意JS。

4. 信任null源

1

Access-Control-Allow-Origin: null

发生在file://或沙盒环境中。 利用方式：提供本地恶意HTML，悄无声息地窃取数据。

5. 不安全的白名单逻辑

示例：

1
2


if origin.endswith("example.com"):
    allow_origin(origin)

可通过login.example.com.attacker.com绕过 利用方式：使用攻击者控制的子域欺骗逻辑。

如何使用简单工具发现CORS漏洞

curl命令：

1

curl -I -H "Origin: https://evil.com" https://target.com/api/data

检查：

Access-Control-Allow-Origin: https://evil.com
Access-Control-Allow-Credentials: true

浏览器脚本：

1
2
3
4
5


fetch("https://target.com/api/userinfo", {
  credentials: "include",
  method: "GET",
  mode: "cors"
}).then(res => res.text()).then(data => alert(data));

从恶意域执行并观察结果。

🤖 AI提示加速CORS挖掘

“编写bash脚本测试100个URL的CORS错误配置”
“生成Python工具查找CORS通配符+凭证问题”
“建议Express.js中弱CORS验证的绕过载荷”
“创建识别不安全子域通配符配置的侦察逻辑”

正确修复CORS的方法

使用严格的白名单 — 不使用通配符
绝不将*与凭证混合使用
规范化并严格验证源站
添加Vary: Origin防止缓存相关泄漏
除非完全控制，否则避免使用子域通配符
除非绝对需要（如沙盒环境），否则不允许null

最后思考

CORS被危险地误解了。它可能看起来像是一个无聊的头配置错误，但它可能为账户劫持、敏感数据泄漏和关键API滥用打开大门。不要让懒惰的CORS设置成为你的失败。

无论你是安全工程师还是漏洞赏金猎人，始终要尊重CORS并严格测试它。

网络安全 | 信息安全 | Infosec | 漏洞赏金 | AI