为什么文件上传会出问题
很多人觉得，让用户传个头像、文档或者附件没什么大不了的。但现实中，不少网站就是因为一个小小的上传功能被攻破，导致整个系统沦陷。攻击者上传一个伪装成图片的PHP文件，服务器一执行，后台就被控制了。这种事不是危言耸听，而是每天都在发生。
根本原因在于：很多程序只做了前端限制，比如用JavaScript提示“只能传jpg、png”。可前端限制太容易绕过，改个请求、用个工具就能把恶意文件送进去。
别再依赖前端验证
有家公司做内部管理系统，上传头像时前端检查了文件类型，开发觉得挺安全。结果有人用浏览器开发者工具禁用了JS，直接发了个.php文件上去，名字改成avatar.jpg.php。服务器没做判断，文件被解析执行，数据库配置信息全被拖走。
真正有效的验证必须在服务端完成。前端提示可以有，但不能作为唯一防线。
后端该怎么正确验证
第一步是检查MIME类型，但也不能全信。攻击者可以伪造content-type为image/jpeg。更靠谱的是读取文件头（file signature），比如JPG开头是FF D8 FF，PNG是89 50 4E 47。这个很难伪造。
第二步是重命名文件。不要保留用户上传的原始文件名，避免特殊构造的名字触发问题。比如把文件名改成时间戳加随机字符串，如202404051230_ab12c.jpg。
第三步是限定存储路径。上传目录不要有脚本执行权限。比如在Nginx中设置：
location ~* \\/uploads\\/.*\.(php|jsp|asp)$ {\n deny all;\n}使用白名单而不是黑名单
很多系统用黑名单过滤.php、.jsp这些后缀，但攻击者可以用.php5、.phtml甚至.phar绕过。更安全的做法是白名单，只允许.png、.jpg、.pdf这类明确需要的格式。
比如PHP中可以这样写：
$allowed = ['jpg', 'jpeg', 'png', 'pdf'];\n$ext = pathinfo($_FILES['file']['name'], PATHINFO_EXTENSION);\nif (!in_array(strtolower($ext), $allowed)) {\n die('不允许的文件类型');\n}图像文件也别放松警惕
有些人觉得“我只允许传图片，应该没事”。但恶意文件可以嵌入到图片的EXIF信息里，或者利用图像处理函数的漏洞。建议对上传的图片进行二次渲染，比如用GD库重新生成一遍：
$img = imagecreatefromjpeg($_FILES['file']['tmp_name']);\nimagejpeg($img, '/safe/path/output.jpg', 90);\nimagedestroy($img);这样一来，哪怕原文件藏了代码，也会被清除掉。
定期检查上传目录
就算做了层层防护，也不能高枕无忧。建议定期扫描上传目录，看看有没有可疑文件。可以写个脚本自动检查非白名单类型的文件，发现就报警或删除。
安全不是一劳永逸的事，尤其是文件上传这种高频功能。每次更新代码时，都得回头看看这块有没有疏漏。一个小漏洞，可能就是大门钥匙。”,"seo_title":"文件上传漏洞修复方法详解 - 好睿思指南","seo_description":"了解如何有效修复文件上传漏洞，避免因上传功能导致服务器被入侵，掌握服务端验证、文件重命名、路径限制等实用防护技巧。","keywords":"文件上传漏洞修复, 文件上传安全, 服务器安全防护, 后端文件验证, 网站安全配置"}