web文件上传漏洞：不是传漏你想传就能传

一个看似人畜无害的"选择图片"按钮，背后可能藏着整个服务器的传漏生杀大权。我见过太多开发者在文件上传功能上栽跟头——不是传漏他们不努力，而是传漏攻击者的脑洞永远比防御清单多一页。

漏洞长什么样？传漏

去年某电商平台被拖库，根因就是传漏后台的商品图片上传接口。攻击者把PHP一句话木马改名为logo.jpg，传漏用Burp Suite拦截请求，传漏把Content-Type改成image/jpeg，传漏文件名后缀改成.php——服务器没校验内容，传漏只信了HTTP头。传漏结果呢？传漏整个管理后台被脱裤，数据库里几十万条用户隐私裸奔。传漏

这不是传漏个例。随便一个没做过安全培训的传漏实习生写的上传模块，都可能存在类似问题。最常见的坑有三个：只校验Content-Type（这个头随便改）、只校验文件后缀（可以双写或加空格绕过）、把上传目录放在Web根目录下（直接可以访问执行）。

攻击者都在想什么？

他们不关心你的业务逻辑，只关心两件事：能不能传可执行文件，以及能不能访问到它。所以你会看到攻击者尝试上传.php、.jsp、.asp，甚至.phtml、.php5这种冷门后缀。更阴的是，他们会在图片文件末尾附加一段PHP代码，用%00截断后缀，或者利用Apache的解析漏洞让shell.php.jpg被当作PHP执行。

有一次我测试一个站，上传点只允许图片，但服务端用getimagesize()验证——这函数确实能识别伪图片。可攻击者用图片马，把恶意代码塞进EXIF信息里，再配合文件包含漏洞触发。防了上传，没防解析，照样被打穿。

防御不能靠堆黑名单

很多开发者的防御思路是：禁止上传.php，那就再加个.php3，再拦.phtml……累不累？黑名单永远堵不完。正确的姿势是白名单后缀+随机文件名+目录隔离。只允许.jpg、.png、.gif，文件名改成时间戳+随机字符串，存储路径放到Web目录之外的/uploads/，再通过单独的下载接口输出。这样就算攻击者传了个PHP文件，他也访问不到执行路径。

还有个细节很多人忽略——服务器配置。即使代码写了白名单，如果Apache配置了AddHandler或者Nginx的fastcgi_pass没做限制，攻击者用x.jpg/.php这种路径就能触发解析。我见过一个站，代码防御严严实实，结果运维图省事在Nginx里配了location ~ \.php$，所有文件都交给PHP-FPM处理——白搭。

测试你的上传点

别等被黑再修。手动测几个关键点：改后缀、改Content-Type、双写后缀、加空格、加%00截断、上传超大文件看是否报错泄露路径。再试试上传一个合法的图片，用十六进制编辑器在文件末尾插入<?php phpinfo();?>，然后通过其他接口包含它。如果这些测试都过了，基本能挡住大部分脚本小子。

但说实话，安全是动态的。今天防御有效，明天可能就有新绕过技巧。我见过最狠的案例是攻击者利用上传功能做存储型XSS——图片SVG文件里嵌了JavaScript，管理员一预览就中招。所以，上传功能的本质是"不可信输入"，别过度依赖任何单一校验，把每次上传都当成潜在攻击来设计。

最后说句实在的，别信那些"上传漏洞已修复"的保证。代码是人写的，人总会犯错。真正靠谱的做法是：上传功能上线前，找个懂安全的人做次渗透测试，比自己拍脑袋想几个规则强得多。