SN某接口CRLF注入艰难利用 – cookie复写可打全站XSS
【注意:此文章为博主原创文章!转载需注意,请带原文链接,至少也要是txt格式!】
请注意,本文主要说明攻击思路。
CRLF注入这个漏洞我碰到的真是特别少,有印象的是总共碰到过两次,那两次还都无法实际利用,可能过滤了换行的参数吧。不过这次也算是巧合SN发现了几处CRLF注入,这里我挑选了一处比较有意思的来说说,如下图。
http://xxxx.SN.com/cxxxxxxxxs?sid=16xxxxxx8&tid=1612xxxxxxxxx0614&ap=NDQzxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxfDB8fA==
当访问上面的URL的时候如下图:
上面URL参数中有个AP参数,这个值明显是base64编码的参数。
通过base64解码ap参数的值发现。值是:
4439xxxxxxxx421|37c949xxxxxxxxxxa9ddcbe|100xxxxx22|161xxxxxxxxx614|16xxxxx78|http://xxxx.SN.com/jxxxxxxx0.html|cpm|2017-06-14 16:37:55|1497xxxxxxx1188|58.2xx.xx2.35|0||42xxxxx83|0|148617xxxxxx798|15xxxxx4|16|100|192.1xx.xxx.37|0||
这里感觉指向的就是 解码后http://xxxx.SN.com/jxxxxx0.html这个地址,然后,后缀还加上了cpm这个参数值。
这里随便更改了一下地址,然后编码,再然后访问了一下,确实就跳转到了我随便放入的URL地址,可以确定这个参数由我控制。那么尝试了一下%0a换行,看看是否有CRLF注入,但是如图:
这里发现,你怎么编码它就怎么返回你编码的值。然后直接不编码尝试了一下。
本来以为这样就可以直接注入写入恶意的cookie,把恶意的代码写入其中,但是如图【程序把值html实体化了】:
这个地方花了很多的时间,因为把html实体化了(左右尖括号、单引号)这些都不可用,当时想了很多办法什么提前闭合返回Connection: close头部等等,但是都因为尖括号无法使用而
后来翻看以前的给SN提交的CRLF注入,发现,URL编码问题。因为其他接口调用cookie,只要恶意的cookie的值是[一次]URL编码会自动被解码。所以,最终利用URL编码绕过程序的html实体编码。
这里需要注意,一定要确保你写的cookie会被对方的程序会调用。(这里就需要你自己细心的查找了。)
只要诱导用户访问了下面的这个地址:
http://xxxx.SN.com/cxxxxxks?sid=16xxxx78&tid=1612xxxx0614&ap=NDxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxjM3fDB8fA==
只要访问了这个URL地址,直接会跳转到SN的首页,然后再次访问http://任何其他站点.suning.com/app/cart2/prxxxxe/shxxxxnfo.do 等其它调用此mtixxxxo cookie的时候就会中招。当然,因为直接可以301跳转,所以完全可以直接跳转到上面的那个地址。最终类似于反射XSS的payload如下:
最终说一下,首先如果有人访问了我构造好的恶意链接,然后恶意链接会复写他的cookie,当他访问任何SN的系统,只要有调用我复写恶意cookie的地方,都会触发XSS代码。而且这样神不知鬼不觉。
中招之后。。。。
对方SRC给分。
布施恩德可便相知重
微信扫一扫打赏
支付宝扫一扫打赏