文件上传漏洞攻击

一个文件上传接口，文件如果只检查了文件扩展名，上传那它跟没检查差不多。漏洞2018年，攻击某国内CMS曝出一个上传漏洞，文件攻击者把PHP代码写进一张图片的上传EXIF字段，文件后缀改成.jpg，漏洞上传成功后用本地文件包含漏洞一引，攻击服务器直接执行了里面的文件代码。整个链路不需要多高深的上传技术，一个Burp Suite改包就够了。漏洞

这就是攻击文件上传漏洞的典型面貌。它不复杂，文件但杀伤力极大。上传上传一个webshell，漏洞等于把服务器的大门钥匙交了出去。攻击者能读文件、写文件、执行命令、连数据库，甚至以此为跳板渗透内网。很多人觉得这种漏洞早该绝迹了，但你去翻翻漏洞平台，文件上传相关的提交量从来没跌出过前十。

问题出在哪？出在开发者的侥幸心理。前端JS校验后缀？抓包绕过。后端黑名单禁了.php？试试.php5、.phtml、.php.jpg，Apache在某些配置下照样当PHP解析。Content-Type检查？改一下请求头就行。这些绕过手法在网上流传了十几年，依然有效，因为总有人只做一层防护就觉得万事大吉。

我见过一个真实案例。某企业的OA系统，上传头像的功能只允许.jpg和.png。看起来没问题对吧？但后端用的是白名单校验文件名后缀，却忘了校验文件内容。攻击者上传了一个.jpg文件，里面全是PHP代码，然后利用系统的文件包含功能去引用这个“图片”。服务器一解析，代码就跑了。更离谱的是，上传目录还有执行权限。两个配置失误叠加在一起，直接导致服务器沦陷。

防御这件事，单靠一层根本兜不住。文件名要重命名，别用用户传上来的原始名字，../../etc/passwd这种路径穿越也是老套路了。后缀用白名单，但白名单本身不够，还得配合文件内容检测。图片就检查文件头魔数，FF D8 FF是JPEG，89 50 4E 47是PNG，对不上就拒绝。上传目录必须禁止脚本执行，Nginx里加一条location ~* \.(php|jsp|asp)$ { deny all; }，Apache关掉Options +ExecCGI。这些配置不复杂，但缺一个都可能出事。

还有个容易忽略的点：上传后的文件存储位置。别放在Web根目录下能直接访问的地方。理想情况是存到独立的对象存储或者专用文件服务器，通过后端脚本读取后再输出给用户。这样即使传了恶意文件，也没法通过URL直接触发执行。

文件上传功能几乎每个Web应用都有，头像、附件、导入数据，到处都是入口。攻击面大，防御又容易出纰漏，这就是它长期活跃的原因。别指望WAF能挡住所有绕过，WAF规则更新永远滞后于攻击手法。真正靠谱的做法是在代码层面把校验做扎实，把权限收干净。一个上传点失守，整台服务器就可能变成别人的肉鸡。