记一次TXT的存储型XSS奇葩案例

有注册功能，那就注册成为尊贵的用户吧。

有短信验证码的功能看看有没有漏洞（关于短信验证码的漏洞挖掘技巧详情查看历史文章【技术分享】短信和邮箱验证码的漏洞挖掘技巧）

好的，没有，您的站点非常安全。

进入个人中心发现用户的头像处可以上传文件。

先上传一个正常图片看看数据包。

发现上传头像后站点会有两步操作：第一步对上传的文件进行检验是否为合规文件，第二步对图片进行裁剪，最后把裁剪后的图片设置为头像。

在设置头像的数据包中发现图片信息的上半段为二次渲染的标记，下半段为图片信息。

知道了逻辑那就直接在第二步中修改文件信息吧。

通过插件知道这是一个php的站。

上传一个纯代码文件，在第一步中就失败并返回只能上传jpg、jpeg和png格式的文件的提示，难道是对文件头有限制？

上传一个正常的图片。通过第一步的检验后，进入第二步裁剪完成后拦截上传头像的数据包，转发到repeater模块把图片名字cropper.jpg改为cropper.php，在图片信息末尾加上恶意代码然后放包。

返回的还是只能上传jpg、jpeg和png格式的文件。

把文件信息改成123456看看效果什么样。

能显示啊这是为什么？

把文件末尾信息改成123456<?php @eval($_POST['1']);?>123456。访问后只保留了两个123456，中间的代码被删除了。头回遇到这种情况啊。

虽然php没法利用了，但是至少还有html。可以弄一个存储XSS保底也还行，传上去访问文件竟然不显示。

G，啥都没有。闲的无聊把文件后缀改成txt重新发包。

访问目标文件，属实给我开眼了。非预期文件上传TXT导致存储型XSS！闻所未闻，想都不敢想的事啊！