文件上传漏洞网站

一个普通的文件网站下午，我登录某家企业的上传内部系统，想传一张产品图片。漏洞上传框很友好，文件网站支持jpg、上传png、漏洞gif，文件网站还贴心地提示“最大5MB”。上传我随手把文件名改成shell.php.jpg，漏洞系统弹窗提示“格式不支持”。文件网站但当我用Burp Suite截断请求，上传把文件名改回shell.php，漏洞Content-Type改成image/jpeg——服务器安静地接受了。文件网站那一刻，上传我知道这个站点的漏洞上传功能形同虚设。

文件上传漏洞的可怕之处在于，它把“信任”直接交给用户输入。开发者以为检查了扩展名就万事大吉，却忽略了服务器解析顺序、文件头伪造、甚至双写后缀绕过。更隐蔽的是，有些系统只校验MIME类型，而MIME是客户端随便改的。你上传一个合法图片，在图片末尾追加一段PHP代码，服务器照样当图片存下来，但当你用evil.php%00.jpg这种老式截断技巧访问时，Apache老版本可能直接解析成PHP执行。

我见过最离谱的案例，是一家小型电商平台。他们的头像上传功能没做任何过滤，攻击者传了个avatar.php，服务器直接放在/uploads/目录下。攻击者访问/uploads/avatar.php，执行了system('cat /etc/passwd')，然后轻松拿到数据库账号密码。整个攻击过程不到两分钟，而这家公司直到被拖库才发现问题。

别以为现在框架都安全了。很多开发者喜欢自己写上传逻辑，理由往往是“框架太重”或“需求太特殊”。但自己写就意味着要处理所有边界情况：文件内容检测、路径穿越、符号链接、压缩包解压时的zip slip。你漏掉一个，攻击者就多一条路。比如某些CMS允许上传SVG，SVG本质是XML，里面能嵌script标签——存储型XSS直接打到管理员后台。

防御思路其实不复杂，但执行起来需要偏执。最有效的一招：上传目录禁止执行脚本。Nginx里配置location /uploads { php off; }，Apache用RemoveHandler。其次，文件名必须服务端重新生成，用随机字符串加白名单扩展名，用户提供的任何文件名都不该直接采用。文件内容检测要用二进制读取，别只看头部几个字节——GIF89a开头后面跟PHP代码照样能骗过简单校验。

还有一点常被忽略：上传后的验证。文件存到服务器后，用getimagesize()检测图片真实性，或者用命令行工具重新编码图片，把潜在恶意代码直接“洗掉”。对PDF、DOC这类复杂格式，最好用LibreOffice转换一次，既消毒又统一格式。

最后说句实在话，漏洞永远修不完，但攻击面能缩小。把上传功能当成最危险的外部输入接口来设计，每次改动都问自己：如果攻击者传了一个1GB的压缩炸弹怎么办？如果文件名包含../怎么办？如果上传的是软链接指向/etc/怎么办？想清楚这些，你的上传框才算真正能用。

本文地址：http://www.79wt.cn/news/57e399939.html