文件上传漏洞排查报告

昨天下午四点十七分，文件运维老周在监控面板上看到一条异常的上传上传记录。文件名是漏洞“avatar.php.jpg”，大小2.3MB，排查上传IP来自巴西圣保罗。报告老周骂了一句，文件立刻拔掉了这台服务器的上传网线。这已经是漏洞本月第三起针对上传接口的试探了。

我赶到机房的排查时候，老周已经把日志导出来了。报告攻击者先尝试上传一个正常的文件图片，然后用burp suite修改了Content-Type字段——这是上传最基础的绕过方式，但我们的漏洞WAF居然没拦住。问题出在代码里：if(in_array($ext,排查 array('jpg','png','gif')))只检查了扩展名，没验证文件内容。报告攻击者上传的PHP代码被藏在了图片的EXIF信息里，服务器用file_put_contents把它写进了web目录。

排查这种漏洞有个笨办法但很有效：翻上传日志，找那些文件名带两个后缀的，或者大小异常的文件。我们这次还发现攻击者用了分块传输，把恶意代码拆成几十个小包，每个包都小于WAF的检测阈值。这招挺阴的，纯粹是跟你玩耐心。

修复方案不复杂。首先，在服务器端用getimagesize()验证图片的真实性，这函数会解析文件头，PHP代码是过不了这关的。其次，把上传目录的脚本执行权限关掉——在nginx里配置location ~* \.(php|php5)$ { deny all; }，就算攻击者上传了webshell也执行不了。最后，给文件名重新随机命名，别用用户输入的名字，后缀统一改成.img，这样即使内容有恶意，也无法被解析为可执行脚本。

老周问我，为啥不直接用云上的文件存储服务？我笑了笑，这客户是国企，所有数据必须本地化部署，审批流程走完得三个月。现实就是这样，很多漏洞不是技术难题，是流程和预算问题。

后来我在测试环境复现了整个攻击链。上传一个包含<?php eval($_POST['cmd']);?>的合法PNG图片，文件名改成shell.png.php，成功绕过了扩展名黑名单。但当我加上getimagesize()校验后，同样的请求直接返回“非法图片”。原理很简单，PHP代码没有有效的图片文件头，函数会返回false。就这么几行代码的事，能挡掉90%的脚本小子。

排查报告最后我写了三条建议。一是所有上传接口统一走同一个类，别让每个业务线自己写上传功能——这次漏洞就是因为某个内部系统为了省事，跳过了公共校验层。二是日志保留时间从30天延长到180天，出了事能回溯。三是每季度做一次上传接口的渗透测试，别等被打了才想起来。

写报告的时候我看了眼时间，凌晨两点。机房空调嗡嗡响，老周已经趴在桌上睡着了。文件上传漏洞这东西，说破天也就是个输入校验问题，但就是有人不重视。你永远不知道下一个试探你的IP来自哪里，可能是圣保罗，也可能是某个内网员工的误操作。把基础打牢，比啥都强。