任意文件上传漏洞案例

某次渗透测试，任意目标是文件个政府门户网站。信息收集阶段一切正常，上传直到我翻到后台的漏洞“证件照上传”功能——管理员上传身份证扫描件的入口。随手传了个PHP一句话木马，案例改后缀为.jpg，任意系统提示“上传成功”。文件打开图片路径，上传服务器原样返回了文件内容，漏洞没有重命名，案例没有二次渲染，任意连Content-Type都没检查。文件就这么简单，上传一个Getshell完成了。漏洞

这类漏洞的案例根源往往不在代码逻辑多复杂，而是开发者的“信任惯性”。他们默认上传接口只被内部人员使用，默认攻击者不会去改文件内容，默认图片处理库能过滤掉所有恶意代码。但现实是，攻击者连burp suite都不需要打开，直接在浏览器里把文件名改成“shell.php.jpg”就能绕过某些弱校验——如果后端只检查后缀名是否包含“jpg”字符串的话。

更讽刺的是，很多修复方案反而制造了新漏洞。见过某团队为了防上传漏洞，在服务器上禁用所有PHP执行权限，结果运维后台的日志分析功能直接瘫痪。还有的用黑名单过滤常见危险后缀，攻击者改用“.phtml”“.php5”“.shtml”就绕过去了。黑名单永远是下策，因为你不知道攻击者字典里有多少种变体。

真实案例里有个细节挺有意思。某电商平台的上传点，开发人员加了文件头校验——只允许GIF89a开头。攻击者就在PHP代码前加了3字节的GIF头，配合文件包含漏洞成功执行。这暴露了另一个问题：单点防御根本不安全，文件上传校验必须和服务器解析配置联动。Nginx的fastcgi配置如果写了“location ~ \.php$”，而上传目录恰好匹配这个正则，那所有.jpg文件都会被当PHP解析。

说点个人观点吧。现在很多安全培训都在教“如何写安全的文件上传代码”，但实际漏洞更多出在框架配置和中间件层。比如Tomcat的PUT方法默认开启时，直接传JSP文件就能Getshell，这跟代码半毛钱关系都没有。做防御时，先确认服务器的解析顺序，再谈过滤规则，顺序反了全是白费功夫。

那次渗透最后怎么结束的？拿到shell后没深入，提交报告时附上了修复建议：上传目录禁止脚本执行、文件重命名加随机字符串、单独部署文件存储域名。过了两周复测，对方把上传路径改成OSS了。有时候漏洞修复挺简单，难的是让甲方相信——他们花几万块买的WAF，可能不如一条“location ~* \.(php|jsp)$ { deny all; }”配置管用。

别迷信复杂方案。攻击者最喜欢的就是那些只防了表面、却留了一堆逻辑漏洞的系统。文件上传这东西，本质上就是“信任用户输入”和“不信任用户输入”的博弈，而安全的关键在于——你预设的信任边界，是否覆盖了所有可能的逃逸路径。