内容摘要：文件上传漏洞整改报告 昨天下午四点十七分，运维老张在群里甩了一张截图——后台的“产品图片”上传目录里，多了一个名为shell.php.jpg的文件。文件大小只有2KB，但足够让一个陌生IP拿到服务器的

文件上传漏洞整改报告

昨天下午四点十七分，文件运维老张在群里甩了一张截图——后台的上传“产品图片”上传目录里，多了一个名为shell.php.jpg的漏洞文件。文件大小只有2KB，整改但足够让一个陌生IP拿到服务器的报告控制权。这不是文件模拟攻击，是上传真实发生的入侵痕迹。

文件上传漏洞，漏洞说白了就是整改给攻击者开了一扇后门。他不需要破解你的报告密码，只要找到一个允许上传文件的文件入口——头像、附件、上传Excel导入——然后塞一个伪装成图片的漏洞脚本进去。你的整改服务器就成了他的肉鸡。这事儿在中小公司尤其常见，报告因为开发时图省事，只校验了文件后缀名，没管内容。

我们这次中招的路径很典型：一个合作伙伴的运营账号被钓鱼，攻击者用那个账号登录了后台，在“批量导入产品数据”的功能里上传了一个包含恶意代码的CSV文件。系统只检查了文件扩展名是.csv，就把它存到了web根目录下的/uploads/temp/，然后被Apache直接解析执行了。整个过程不到三分钟，日志里甚至没有触发任何告警规则。

整改方案分三步走。第一步，改代码逻辑——上传的文件一律重命名，用UUID加原始扩展名，禁止用户控制文件名；存储位置移到web根目录之外，用独立的文件服务域名来访问，这样即使文件被上传，也无法通过web路径直接执行。第二步，加内容校验——不只查扩展名，还要用getimagesize()检查图片文件头，用finfo_file()读取MIME类型，对CSV文件强制解析第一行，确认是纯文本数据而不是可执行脚本。第三步，改服务器配置——Apache和Nginx都禁止在/uploads/目录下执行任何脚本文件，用php_admin_flag engine off关掉该目录的PHP解析能力。

光改代码不够。我们花了三天时间，把所有历史上传文件全部拉出来跑了一遍哈希比对，找出所有可疑的.php、.phtml、.php5后缀文件，一共清掉了十一个。其中有两个是半年前的渗透测试留下的，当时测试报告里写了“存在上传绕过风险”，但没引起重视。这次是实打实的教训——漏洞不修，它不会自己消失，只会等一个更狠的攻击者来利用。

还有个细节值得单独说。攻击者上传恶意文件后，通常会先访问一下确认能执行，再植入webshell。我们审计访问日志时发现，那个IP在凌晨两点尝试了三次访问同一个URL——/uploads/temp/shell.php.jpg，前两次返回404，因为文件名被系统自动加了下划线前缀，第三次成功了。这说明攻击者也在试探，如果我们的文件名策略稍微严谨一点，他连试的机会都没有。

这次整改花了四天时间，涉及三个后端服务、两个前端上传组件、还有一套老旧的CMS系统——那套CMS是2018年外包做的，代码里写死了上传路径，连框架自带的过滤函数都没调用。最后我们决定直接弃用那个CMS的旧上传模块，全部迁移到新写的文件服务接口。迁移过程比预想中麻烦，因为有些历史数据里的图片路径是绝对路径，迁移后得改数据库里的URL，整整跑了一晚上脚本才替换干净。

复盘下来，最核心的教训就一条：上传功能必须默认不可信。别相信用户的文件后缀，别相信MIME类型，别相信任何客户端传来的元数据。服务器端要做的校验一个都不能少，存储和执行的权限边界必须物理隔离。另外，日志监控得跟上——我们这次要不是老张每天习惯性看一眼上传目录，可能被控制一两个月都发现不了。安全这东西，平时看着像成本，出了事才知道是保命符。