文件上传漏洞复现：一个头像框引发的文件“血案”

我拿自己刚搭的测试站开刀。一个普通的上传用户头像上传功能，PHP后端，漏洞没做任何过滤。复现我随手传了个shell.php，文件文件内容就三行：<?上传php @eval($_POST['cmd']);?>。结果呢？漏洞上传成功，路径直接返回在JSON里。复现我打开浏览器访问那个路径，文件页面空白——但我知道，上传它活着。漏洞用蚁剑连上去，复现虚拟终端一开，文件whoami回显www-data。上传整个服务器，漏洞像没锁门的房子，我穿着拖鞋就进去了。

问题出在哪？服务器信任了客户端提供的文件名。它只检查了HTTP头里的Content-Type，而那个字段是浏览器自己报的，我用Burp Suite改成image/jpeg就绕过了。更蠢的是，文件存到了/uploads/目录，并且没有禁止脚本执行。Apache配置里AddType application/x-httpd-php .php，意味着只要后缀是.php，它就会当作代码跑。这组合拳，等于把钥匙挂在门口。

换个场景，如果后端用了白名单呢？比如只允许.jpg、.png。那我会传一个shell.jpg，内容里塞PHP代码。然后找找有没有文件包含漏洞——把图片当PHP解析。或者试试shell.php.jpg，某些老版本Apache会从右往左解析，识别成.php。再不行就传.htaccess，让jpg文件以PHP执行。这些招数，都是跟攻击者学的，他们比大多数开发更懂服务器配置。

我见过最离谱的案例，是个政务网站。上传点用来传身份证照片，结果攻击者传了个getshell.php，直接拿下数据库。后来查日志，发现上传接口连大小限制都没有，50MB的PHP文件也照收。开发人员说“当时只想着功能实现，没想过有人会传非图片”。这话听着气人，但真实。很多漏洞不是技术多高深，而是压根没把用户当敌人。

修复其实不难。第一，文件名重写，服务端生成随机字符串，别用用户给的。第二，后缀白名单，只认图片扩展名。第三，文件内容头校验，用getimagesize()真的读一遍图片信息。第四，上传目录禁止脚本执行，Nginx里配location ~ \.php$ { deny all; }。第五，存储和展示分离，文件放独立域名或CDN，不跟应用服务器同域。做到这五条，能堵住九成攻击。

但别高兴太早。攻击者会研究你的业务逻辑，比如他传个SVG，里面嵌JavaScript，你把它当图片展示，XSS就来了。或者传个恶意PDF，触发解析器漏洞。文件上传这口子，永远有新鲜玩法。我复现完这次，第一反应不是“我技术多牛”，而是“幸好这是我自己搭的靶机”。真实生产环境要是这么搞，早被人拖库了。

最后说个细节。我把那个测试用的shell.php删了，但/uploads/目录里留了个空文件夹。每次看到它，都像看到一扇没关严的窗户。安全这行，你永远不知道下一秒会从哪飘来一阵邪风。