文件上传漏洞利用

2018年，文件某安全团队在GitHub上扒出一款流行的上传CMS源码，发现它的漏洞利用文件上传接口只检查了Content-Type头。把PHP文件的文件Content-Type改成image/jpeg，服务器照单全收。上传这个漏洞后来被写进自动化利用工具，漏洞利用批量扫了十几万个站点。文件文件上传漏洞的上传可怕之处不在技术复杂度，而在于开发者的漏洞利用侥幸心理——总觉得前端加了`accept=".jpg"`就万事大吉。

前端校验是文件纸糊的墙。浏览器F12一按，上传JavaScript直接改掉，漏洞利用或者用Burp Suite拦截请求，文件把`filename="shell.php"`改成`filename="shell.php.jpg"`，上传后端如果只取第一个点之前的漏洞利用内容做扩展名判断，照样中招。更粗暴的方式：直接构造POST包，绕过整个页面逻辑。我见过一个真实案例，某企业OA系统的头像上传功能，后端用`$_FILES['file']['type']`做白名单，攻击者把Content-Type设为`image/gif`，文件内容却是``，上传后路径回显在响应里，菜刀一连，服务器就姓了别人的姓。

绕过手段远不止这些。黑名单校验？试试`.phtml`、`.php5`、`.pht`，Apache的httpd.conf里可能藏着几十个可执行扩展名。大小写混写`PhP`，Windows服务器不区分大小写，Linux下如果配置了`AddType application/x-httpd-php .php .php3 .php4`，照样执行。空格、点号、`::$DATA`这些NTFS数据流技巧，在IIS上曾经通杀。最阴的是竞争条件：上传一个`.htaccess`文件（内容为`AddType application/x-httpd-php .jpg`），再传一个jpg马，两个请求同时发，服务器来不及删除临时文件就被解析了。

文件内容检测也不是铁板一块。`getimagesize()`函数只读文件头，在PHP文件开头加`GIF89a`，后面跟一句话木马，函数返回真，文件却能被PHP解析。二次渲染更坑，某些CMS把用户上传的图片用GD库重新生成，表面看马被洗掉了，但攻击者可以精心构造像素块，让渲染后的图片里依然藏着可执行代码。我拆过一个Discuz!的旧版本，它的头像裁剪功能会把用户上传的图片按坐标裁剪，只要把恶意代码放在裁剪区域之外，渲染后代码原封不动保留。

防御这事，说复杂也复杂，说简单也简单。白名单扩展名，只允许jpg/png/gif，并且用`pathinfo()`取扩展名后强制转小写。文件名重命名，用`md5(uniqid())`生成随机名，别用用户传的。上传目录禁止执行权限，Nginx里加`location ~* /uploads/.*\.(php|php5|phtml)$ { deny all; }`，Apache用`.htaccess`写`php_flag engine off`。文件内容用`finfo_file()`检测MIME，别信`$_FILES['type']`。最狠的一招：把上传文件存到独立域名或OSS，彻底切断解析路径。

有人觉得这些老生常谈。可2023年HVV行动中，文件上传漏洞依然排在入口点前三。某次应急响应，我在客户服务器上找到三个不同年代的上传马：一个2015年的eval马，一个2019年的冰蝎马，还有一个2022年的哥斯拉马。三代同堂，整整齐齐。开发者换了一茬又一茬，漏洞代码却像传家宝一样留着。安全这行，最怕的就是“我以为”——我以为前端拦住了，我以为后端过滤了，我以为没人会去传那种文件。