记一次文件上传类型渗透

仅用于信息安全教学和演示，请勿用于其他用途

“从未如此美妙的开局！”

0x00写在前面

很久没有做安全相关的事了，昨天在好奇心的驱使下，尝试挖了一个比较简单的洞，过程不复杂，但是对于以后的可能进行的后端开发敲响了警钟。

0x01过程

这个网站是一个某类表情包（一眼丁真）的分享网站，有随机表情包、按照id搜索表情包、按照id点赞表情包、上传表情包等功能。显然，有上传就一定有审核，有审核就一定有管理员端，而且这是肯定进不去的。（下图为按照id点赞表情包的api，没啥用其实）

还是看看他的主界面吧，有一个上传，看看源码

<div id="upload-pic-box">
    <a id="pic-path">上传一张图片吧</a>
    <form id="upload-form">
        <input onchange="validateFileType()" type="file" accept="image/gif,image/jpeg,image/jpg,image/png,image/svg" name="user-upload" id="user-upload">
    </div>

//...此处省略114514行~


    var fileName = document.getElementById("user-upload").value;
    var extFile = fileName.substr(idxDot, fileName.length).toLowerCase();
    if (extFile == "jpg"  extFile == "jpeg"  extFile == "png"  extFile == 'gif') {
        showfilename();
    } else {
        alert("你怎么骗我，\n哼，上传点正常格式的照片！（jpg/png/gif）");
    }

可以看出，如果服务端没做验证的话，这里的前端校验就是马奇诺防线，轻松上传我们的🐴

然后我们需要定位我们的🐴在哪里了，本来这有些棘手，毕竟万一人家后端有个杀🐴程序呢？（虽然能上传成功的话就说明大概率不会有了233）

然鹅，在审查其他api时，我发现了有个叫做/admin-get.php的get请求。我试着直接curl了一下，结果大跌眼镜的是，这玩意谁都能访问，而且一堆较为敏感的信息，虽然没有标识，但是能一眼看出有些字段是图片id和图片地址的。这极为致命，因为这就告诉了我上传的🐴的位置。

这就离谱了嗷xdm，让我们连一下蚁剑

xswl

不过还是要提issue的，这是道德底线

作者也在后面做了补救措施，看得出来还是个比较核善的人😋😋😋

0x02后记

实际上，我一直是在做黑盒测试，我是在拿到shell后才注意到它原来本身就开源了（离谱，那我浪费时间干嘛）。

可以看出来作者本人真的强，但是再强的人也难免有些地方不如成熟框架做的细致。想起我这种彩笔以前直接用几个组件拼接了一个后端，还自以为是地写了个恶心人的黑盒，就以为能抵御95%的入侵了，结果某个“阿喀琉斯之踵”被别人（plusls）拒绝服务攻击了，寄。