0x01 写在前面

今天发现了个有趣的URL特性，跟大家分享下。授权项目，重马伺候~

0x02 漏洞发现

拿到系统，先找高危，看到一处文件上传：

本来想试下任意文件上传，结果白名单验证，遂放弃。但是测试过程中发现了个有趣的现象：

附件名称可控！虽然附件名称不会影响上传的文件名，也就是对我们的上传没有帮助，但这里可能还存着其他的利用方式！安排：

没错，测试XSS，script标签被吃掉了，换img:

上传成功，点击图片：

问题不大，成功弹窗。这里能执行js代码是因为附件名称引入到了title标签中：

上XSS平台payload，同理我们还是用img标签：

上传后，发现payload不完整：

仔细研究后，得知/后面的内容才会被引入title，这就蛋疼了，http协议都是带/的，不带协议的话又不能成功访问到链接，尝试URL编码后亦无法绕过。

正当我百思不得解时，突然想到，既然/不行，那何不用试试？于是有了以下payload：

来看一下结果：

这就舒服了，果然可以带入执行，接下来就是解决https:// ==> https:\：

看起来好像成功了，其实并没有，反斜杠被吃掉了一个：

于是构造<Img+sRC=https:\xss.pt\k7gmp.jpg>，文件传上去了，但是发现死活点不开，此时又陷入了僵局。

正当我再次愁眉苦脸时，发现了一个非常有趣的现象：访问https:www.baidu.com竟然可以成功访问到百度！！这就好办了，改一下payload：<Img+sRC=https:\xss.pt\k7gmp.jpg>，这次，他，终于来了！

成功get存储型XSS一枚~

0x03 写在最后

后来跟大佬们交流的时候发现，还有其他有趣的特性，比如www.baidu。com也可以成功访问，用来使用句号绕过点的过滤，interesting~

原文始发于微信公众号（黑客前沿）：《记一次漏洞挖掘》第二季