文件上传漏洞原理

文件上传漏洞的文件本质，是上传服务器把用户提交的文件当成了“自己人”。

2019年某云厂商的漏洞存储桶被脱库，攻击者只上传了一个带恶意脚本的原理图片。那个图片在浏览器里正常显示，文件但服务器在处理时把它当成了PHP执行——因为文件名是上传“avatar.php.jpg”，而Nginx的漏洞解析规则恰好以“.”为分界。就这么一个点，原理整个管理后台的文件账号密码全被拖走。

这类攻击的上传命门在于“解析与执行的不一致”。用户传的漏洞是图片，但服务器可能因为配置、原理中间件特性、文件或开发者偷懒用文件名后缀判断类型，上传最终把图片当代码跑。漏洞最典型的就是Apache的“多重后缀”特性：它从右往左识别扩展名，遇到不认识的（比如.jpg）就继续往左看，直到碰上认识的（比如.php）才执行。

更隐蔽的玩法是“Content-Type欺骗”。某些开发用HTTP头里的Content-Type判断文件类型，但那个头是客户端自己填的，用Burp Suite改一下就能把“image/png”换成“application/x-php”。服务器一看是PHP，直接存进了可执行目录。你以为在传头像，其实在给服务器装后门。

还有一种场景很蠢但常见：开发者只过滤了文件后缀，却没过滤文件名里的“空字节”。老版本PHP里，如果你上传的文件名是“shell.php%00.jpg”，系统会截断%00后面的内容，最终落盘的文件名是“shell.php”。这招在2010年前后几乎横扫所有国产CMS，现在虽然少了，但老系统仍在运行。

别以为配了白名单就安全。攻击者可以传一个“.htaccess”文件——如果服务器允许上传该文件，就能重写解析规则，把任意文件都当成PHP执行。更骚的操作是传一个“.user.ini”，在CGI模式下设置“auto_prepend_file=evil.jpg”，让所有PHP文件先包含那个图片里的恶意代码。这俩文件本身就是纯文本，根本不需要伪装。

我见过最离谱的案例是某OA系统，它把上传的文件直接存到Web根目录下的“/upload/”文件夹，文件名用时间戳加随机数，后缀固定为“.jpg”。看似无懈可击。但攻击者发现系统用了IIS 6.0，该版本有个经典特性：分号“;”后面的内容会被截断。于是上传“shell.asp;.jpg”，IIS解析时直接当成ASP执行——因为分号后的一切都被忽略。

要堵住这个洞，核心原则只有一条：用户输入永远不可信。文件内容要用服务端工具检测（比如getimagesize读图片头），文件名要重新生成随机串，存储目录要禁止脚本执行权限，上传接口必须校验MIME和扩展名双重匹配。但说真的，大部分开发者连第一层都做不好——他们总以为“用户会按规矩来”。

这漏洞存在二十年了，OWASP Top 10里它常年霸榜。原因不是技术多难，而是人的惰性：懒得多写几行校验代码，懒得改服务器配置，懒得把上传目录和Web根目录分开。攻击者要做的，只是试出你偷懒的那个点。