02 文件上传 漏洞介绍 原理 危害

一个正常的文件危害图片上传功能，攻击者上传一个.php文件，上传服务器就把他当PHP脚本执行了。漏洞这不是介绍什么高深漏洞，本质就是原理服务器太信任用户传上来的东西。

漏洞怎么来的文件危害

文件上传功能到处都是——换头像、传附件、上传导入数据。漏洞开发者写这段代码时往往只想着“让用户把文件传上来”，介绍很少认真想“用户会传什么上来”。原理

问题出在验证环节。文件危害很多代码只检查了前端，上传比如用JavaScript判断扩展名是漏洞不是.jpg或.png。这种检查形同虚设，介绍抓个包改一下，原理或者直接把JS禁用，前端验证就没了。后端如果没做二次校验，文件就直接落到服务器上了。

还有一种情况：后端确实检查了，但检查逻辑有缺陷。比如只过滤了小写的.php，没管.PHP、.php5、.phtml；或者只检查Content-Type，而这个字段是客户端发过来的，随便伪造。我见过一个系统，上传时验证文件名后缀，但用Burp抓包把文件名改成 shell.php%00.jpg，后端解析时被%00截断，实际存成了shell.php。这种Nginx配PHP的经典组合，一旦传上去就是直接拿shell。

攻击者拿到上传点之后干什么

最直接的是传WebShell。一个简单的PHP一句话木马：

<?php @eval($_POST['cmd']); ?>

传上去之后，用中国菜刀或者蚁剑连上，服务器就是攻击者的了。读文件、写文件、执行系统命令、提权、内网渗透，全从这一个点展开。

如果服务器禁用了脚本执行，攻击者还能传.htaccess文件（Apache环境），把.jpg解析成PHP。或者传一个包含恶意宏的Office文档，等着管理员打开。再或者传一个超大文件把磁盘撑满，造成拒绝服务。

2018年那个著名的ThinkPHP 5.x远程命令执行漏洞，配合文件上传，攻击者可以完全控制服务器。当时大量站点中招，就是因为上传点没做好过滤，加上框架本身的路由解析问题，组合起来杀伤力极大。

为什么这个漏洞一直存在

两个原因。一是开发者安全意识不够，觉得“上传个头像能有什么问题”。二是业务逻辑复杂，有些系统确实需要上传各种类型的文件，白名单不好做，干脆用黑名单，结果黑名单永远列不全。

我见过一个CMS，后台文件上传功能只允许上传.jpg，但它在验证时用的正则表达式是 /\.jpg$/i，看起来没问题。可是攻击者上传 shell.php.jpg，正则匹配通过，而Apache的mod_php在解析时，遇到多个扩展名会从右往左找，发现.jpg不认识，继续往左找到.php，当成PHP执行了。这种解析歧义，开发者根本没意识到。

危害到底有多大

取决于上传点所在的位置和服务器权限。如果Web服务以root运行（很多运维图省事这么干），那攻击者上传WebShell后直接就是root权限。如果是低权限用户，攻击者会尝试提权，内核漏洞、SUID、计划任务，总有一条路能走通。

更麻烦的是，文件上传漏洞往往和其他漏洞组合使用。比如先上传一个图片马，再利用文件包含漏洞去包含它，这样就绕过了上传点的执行限制。或者上传一个.htaccess，让服务器把所有.jpg当PHP解析，然后传图片马。组合拳打出来，防御方很难全部堵住。

企业内网里，一个上传点被拿下，攻击者可以横向移动，抓取域控密码，控制整个网络。数据泄露、勒索加密、业务中断，都是从这个小小的上传框开始的。

说到底，文件上传漏洞的核心就一句话：永远不要相信用户传上来的任何文件。验证要做在后端，白名单比黑名单可靠，上传目录要禁止脚本执行，文件名要重命名。做不到这些，就等于把服务器钥匙插在门上。

本文地址：http://www.79wt.cn/news/1838f1899798.html