【注意：此文章为博主原创文章！转载需注意，请带原文链接，至少也要是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给分。