一个朋友接了个外包项目，过上盖代对方要求后台能上传图片。传文他图省事，覆件直接在网上抄了一段文件上传代码，码文把扩展名白名单写死了jpg、过上盖代png、传文gif。覆件结果上线第三天，码文网站被人挂了个一句话木马，过上盖代整个服务器被拖库。传文

问题出在哪？覆件他完全忽略了上传路径和文件名可控这件事。攻击者把文件名改成shell.php.jpg，码文或者利用Apache的过上盖代解析漏洞，把文件命名成shell.php%00.jpg。传文更狠的覆件是，如果服务器配置了AddHandler，直接传个.phtml文件就能执行。白名单只拦了后缀，没拦内容。

真正危险的是那些连白名单都不写的开发者。他们只检查了$_FILES['file']['type']，也就是浏览器的Content-Type字段。这玩意儿是客户端传过来的，用Burp Suite随便改一下就能绕过。我见过有人把PHP文件伪装成image/png，然后服务器就傻乎乎地把它存到web目录里了。

覆盖代码文件是更隐蔽的玩法。如果上传目录和脚本目录有交集，或者开发者没限制上传路径只能相对当前目录，攻击者就能构造../../config.php这样的文件名。有些系统会直接拼接用户输入到上传路径里，比如$target = $uploadDir . $_FILES['file']['name']，那攻击者把文件名写成../../index.php，就能把原来的index.php给覆盖了。

覆盖成功意味着什么？意味着你网站的所有逻辑瞬间变成攻击者手里的代码。他不需要再找其他漏洞，直接通过上传接口写个webshell，然后访问那个被覆盖的文件，就能拿到服务器的执行权限。整个过程可能不到十秒，而且痕迹很难清理——因为原文件已经被替换了，你连备份都没有。

我见过更蠢的案例。某个CMS系统，后台有个“模板编辑”功能，允许管理员上传自定义的模板文件。开发者没做任何过滤，直接把上传的文件重命名成template.php存到主题目录。理论上只有管理员能访问后台，但管理员账号密码被社工了。结果攻击者上传了一个包含系统命令的PHP文件，直接通过浏览器执行system('cat /etc/passwd')，把服务器密码哈希全拉走了。

怎么防？最核心的一点：上传目录必须和执行脚本目录彻底隔离。存文件的目录不能有PHP解析权限，要么在Nginx里配置location ~ \.php$ { deny all; }，要么把上传文件放在web根目录之外，用另一个域名或者通过PHP读取后输出。文件名也要重新生成，用随机字符串加时间戳，别用用户原始文件名。内容检查不能只靠后缀，要读文件头，用getimagesize()验证是不是真正的图片。

还有一点容易忽略：上传接口的权限控制。别以为后台有登录就行，很多系统把上传功能暴露给前台用户，比如头像上传、附件上传。只要这个接口没做严格的鉴权和频率限制，攻击者就能批量上传恶意文件试探服务器配置。我见过一个论坛系统，允许用户上传自定义头像，结果有人传了个.php文件，服务器直接解析了——因为开发者在Nginx里配了location ~ \.php$，但没限制这个目录不能执行脚本。

最后说个实操技巧。如果你用的是Apache，在upload目录下放一个.htaccess文件，写上php_flag engine off，能直接禁止该目录下的PHP执行。Nginx的话，在server块里加location ~* ^/uploads/.*\.(php|php5|phtml)$ { deny all; }。但别以为这样就完了——攻击者可能会利用解析漏洞，比如上传shell.jpg，然后在URL后面加/.php，让Apache误以为这是个PHP文件。所以最稳妥的还是把上传目录完全移出web根目录。

代码写烂不可怕，可怕的是不知道哪里烂。文件上传这个功能，从输入到存储到解析，每个环节都可能被钻空子。你写的时候多花十分钟做过滤和隔离，就能省下后面通宵删木马的时间。