cors跨域漏洞修复
某个周五晚上十一点，跨域我正打算关电脑，漏洞运维同事甩过来一条消息：“官网被人刷验证码了，修复源头是跨域一个游戏外挂论坛。”排查之后发现，漏洞问题不在验证码本身，修复而是跨域我们接口的CORS策略写得太宽松。攻击者从自己的漏洞恶意站点发请求，浏览器照样放行，修复因为响应头里明晃晃写着 CORS跨域漏洞的跨域本质，是漏洞浏览器帮你打破了同源策略的边界。同源策略本该让A网站的修复脚本碰不到B网站的数据，但CORS是给合法跨域请求开的门。门开太大，就什么人都能进了。很多开发者的第一反应是“我加上Origin校验不就行了”，但真正的问题是——你的校验逻辑到底校验了什么。 我见过一个真实案例，某金融类App的接口服务器，代码里写了这样一段：读取请求头里的 另一个高频坑是 真正的修复思路应该分三层。第一层，能不用CORS就不用。同域部署、反向代理、WebSocket替代HTTP轮询，都是更安全的选择。第二层，必须用CORS时，白名单精确到协议+域名+端口，别偷懒写通配符。第三层，对敏感接口（涉及用户数据、支付、修改操作）额外加自定义请求头校验，比如 还有个细节容易被忽略： 修复完之后，别急着收工。拿curl模拟一下跨域请求，看响应头是否真的只返回了你允许的Origin。再拿浏览器控制台跑一段fetch代码，确认非白名单来源被拦截。有条件的话，用无头浏览器做自动化测试，把CORS规则写进CI流程里，防止以后有人不小心改回去。 最后说句实在话——CORS漏洞修复不是配个响应头就完事的事。它考验的是你对“浏览器信任模型”的理解。攻击者永远在找那些“看起来能过就行”的代码。你多思考一层，他们就少一个突破口。安全这东西，没有一劳永逸，只有不断较真。Access-Control-Allow-Origin: *。跨域就这么简单，漏洞任何网站都能以用户身份调用我们的修复接口。Origin字段，判断是否以.example.com结尾。看着没问题对吧？攻击者注册了一个attackerexample.com的域名，完美通过校验。字符串后缀匹配是典型的低级错误，但它在生产环境跑了两年没人发现。修复方法也很粗暴：不要用后缀匹配，用精确匹配，或者直接维护一个白名单列表。Access-Control-Allow-Credentials: true和Access-Control-Allow-Origin: *同时出现。按规范，浏览器会直接拒绝这种组合——但前提是浏览器足够新。老版本浏览器或者某些内置WebView不会管这些，照单全收。如果你的产品还有存量老用户，别指望浏览器帮你兜底。X-Requested-With: XMLHttpRequest，因为跨域请求无法自定义头——除非攻击者用非浏览器工具，但那已经不是CORS攻击的范畴了。OPTIONS预检请求。很多后端框架会自动处理预检，但如果你手动写了CORS中间件，记得对OPTIONS请求直接返回200并带上正确的响应头，不要走正常业务逻辑。我见过有团队在预检请求里查了数据库，导致性能瓶颈——更糟的是，预检请求出错时，浏览器会静默失败，用户看到的就是“接口突然超时”，排查起来极其痛苦。