一个攻击者把一句话木马塞进图片的文件EXIF信息里，上传成功，上传然后整个服务器就沦陷了。漏洞这事我亲眼见过，修复就在去年一家做跨境电商的建议公司。他们的文件后台头像上传功能，只检查了文件头是上传不是FF D8 FF，攻击者随便找了个合法JPEG，漏洞用十六进制编辑器改了几字节，修复就绕过去了。建议修复方案其实不复杂，文件但很多人压根没想过为什么要这么做。上传

核心问题只有一个：服务器不该信任任何来自用户的漏洞东西。文件上传漏洞的修复本质，是建议把“用户输入”当成了“可信内容”来执行。所以修复的第一原则，就是让上传的文件永远无法被执行。

具体怎么做？最有效的一招，是把上传目录的脚本执行权限彻底关掉。在Nginx里写location ~* \.(php|jsp|asp)$ { deny all; }，Apache就用php_admin_flag engine off配合RemoveHandler。这比任何文件类型检查都管用——就算攻击者上传了带木马的PHP文件，服务器也只会把它当纯文本返回，不会执行。我见过不少团队只做前端校验，后端完全不设防，等于把大门敞开。

文件类型校验必须做两层。第一层看MIME类型，用finfo_file()读取真实文件头，别信$_FILES['file']['type']——那个值客户端可以随便改。第二层用服务端白名单，只允许jpg、png、pdf这种固定扩展名，然后重命名文件，用随机字符串加白名单后缀，比如20240613_8f3k2a9c.jpg。千万别保留用户原始文件名，那里面可能藏着shell.php.jpg这种双扩展名，或者.htaccess这种特殊名字。

图片文件还有个隐蔽坑：二次渲染。攻击者能把PHP代码藏在图片的像素数据里，用getimagesize()检查也发现不了。对付这个，用GD库或Imagick重新生成图片，丢弃原始数据。代码就三行：$img = imagecreatefromjpeg($upload); imagejpeg($img, $new_path, 90); imagedestroy($img);。虽然会损失一点画质，但安全上值得。

存储位置和Web根目录分离，这招很多人忽略。把上传文件放到/var/data/uploads/，然后通过一个专门的下载脚本download.php?file=xxx来读取，脚本里做路径检查和权限验证。这样即使文件被上传了恶意内容，攻击者也无法直接通过URL访问到可执行文件。代价是每次下载多一次PHP请求，但安全收益远大于性能损失。

还有个细节，上传接口必须做身份认证和频率限制。去年某大厂被拖库，就是因为他们一个未登录就能访问的文件上传接口，被人拿来当跳板。加个session_check()和每分钟最多10次的限流，成本极低，能挡住绝大多数自动化攻击。

最后说个反直觉的事：别用黑名单过滤危险字符。什么str_replace('php', '', $name)这种写法，攻击者用phphp就能绕过。白名单才是正路——只允许你明确知道安全的东西，其他一律拒绝。这就像机场安检，你不可能列出所有违禁品，但你可以只放行符合标准的物品。

文件上传的修复不是加一个函数就完事，它是多层防御的组合。关执行权限、白名单校验、重命名、二次渲染、存储分离、接口认证，每层都挡住一部分攻击路径。做完这六步，你基本可以放心让用户传文件了——但别完全放心，定期检查服务器日志，看看有没有异常的上传记录，这才是长期安全的常态。