跨源资源共享 cors 漏洞

跨源资源共享（CORS）漏洞，跨源说白了就是资源浏览器把本该属于你的数据，错手送给了别人。共享这事不复杂，漏洞但破坏力极强。跨源

2019年，资源某知名社交媒体平台曝出过这样一个问题：攻击者只需引诱用户点击一个恶意链接，共享就能读取该用户的漏洞私信内容。攻击手法简单到令人发指——利用了一个配置错误的跨源CORS策略。那个平台的资源服务器允许了任意来源的跨域请求，而响应中又恰好包含了敏感的共享用户信息。浏览器看到服务器点头同意，漏洞就乖乖把数据交给了攻击者的跨源脚本。

CORS机制本身是资源个安全设计。浏览器默认阻止跨域请求读取响应，共享这是铁律。但现实业务总需要跨域——前端调后端API，子域名互相访问，第三方登录回调。于是有了CORS头，服务器通过Access-Control-Allow-Origin告诉浏览器：这个来源可以读我的响应。问题出在，很多开发者图省事，直接把这个头设成了*，或者错误地反射了请求中的Origin字段。

反射是重灾区。服务器代码写成这样：Access-Control-Allow-Origin: { 请求头里的Origin}。攻击者构造一个请求，把Origin设为自己的恶意域名，服务器原样返回。浏览器一看，来源匹配，放行。整个过程中，服务器根本没验证这个来源是否可信。

更隐蔽的是，CORS漏洞通常不会单独出现。它需要配合其他条件才能造成实质伤害——比如目标接口需要携带Cookie认证，且Access-Control-Allow-Credentials被设为true。如果服务器同时允许了任意来源和携带凭证，那等于把保险柜钥匙挂在门口。攻击者只需要在自己的网站上放一段JavaScript，用fetch发起带credentials的跨域请求，就能拿到受害者的私人数据。

我见过一个真实案例，某电商平台的用户信息接口存在CORS配置错误。攻击者把恶意脚本伪装成抽奖页面，在社交群里传播。点进去的瞬间，脚本会请求那个接口，读取用户的历史订单、收货地址、手机号。整个过程用户毫无感知，浏览器地址栏看起来还是那个抽奖页面。事后调查发现，这个接口上线时就写死了Access-Control-Allow-Origin: *，测试环境直接搬到了生产环境，没人复查。

修复方案不复杂，但需要态度。维护一份可信来源白名单，严格校验Origin头，不要把*和credentials同时使用。更关键的是，别把所有敏感接口都设计成可跨域访问。有些数据，压根就不该通过CORS暴露给前端。

说到底，CORS漏洞暴露的是开发者的侥幸心理。总以为没人会注意那几个响应头，总以为攻击者不会想到这种冷门角度。可现实是，攻击者比你想象中更在意这些细节。浏览器帮你拦了一道，你自己却把门打开了。