文件上传漏洞绕过

文件上传功能几乎是文件每个Web应用的标配，头像、上传附件、漏洞导入数据，绕过哪哪都要用。文件但就是上传这个看似简单的功能，成了无数渗透测试报告里的漏洞高频漏洞点。问题出在哪？绕过开发者往往只做了前端校验，或者后端只检查了Content-Type，文件攻击者改个包就绕过去了。上传

我见过一个真实案例。漏洞某企业OA系统的绕过头像上传功能，前端用JavaScript限制了只能选.jpg和.png。文件抓包把文件名改成shell.php，上传Content-Type从image/jpeg改成application/x-php，漏洞直接上传成功。更离谱的是，上传后的文件路径是/webroot/upload/avatar/shell.php，浏览器访问就能执行。从发现到拿到服务器权限，前后不到五分钟。

绕过手段比想象中多

前端校验是最容易绕的，禁用JavaScript或者直接抓包改请求体就行。后端校验才是真正的战场，但很多后端写得也粗糙。

只检查Content-Type的，把PHP文件的Content-Type改成image/gif，照样过。只检查文件后缀的，试试大小写混合——shell.PHP、shell.pHp，Windows服务器上不区分大小写，Linux上某些配置也不区分。还有空格绕过，shell.php （末尾加空格），Windows会自动去掉空格，Linux某些版本也会。

黑名单机制更是个笑话。禁了php，那就传php3、php4、php5、phtml、pht。禁了这些，还有.htaccess文件上传。传一个.htaccess上去，内容写AddType application/x-httpd-php .jpg，然后传个jpg的webshell，照样解析。Apache的配置文件就是这么好使。

白名单相对靠谱，但也不是铁板一块。检查文件头？那就伪造GIF89a文件头，后面跟PHP代码。检查图片完整性？用copy命令把正常图片和webshell拼接，或者用exiftool把代码写进图片的注释段。服务器端如果只检查文件头不检查文件尾，这招屡试不爽。

解析漏洞才是大杀器

有时候上传功能本身没问题，但服务器解析配置有缺陷。Nginx的fastcgi解析漏洞，访问shell.jpg/x.php，Nginx会把shell.jpg当成PHP解析。Apache的多后缀解析漏洞，shell.php.jpg，Apache从右往左解析，遇到不认识的后缀就继续往左，最后把shell.php当成PHP执行。

IIS更夸张。IIS 6.0的解析漏洞，shell.asp;.jpg，分号后面的被截断，直接当asp执行。还有IIS 7.5的畸形解析漏洞，shell.jpg/.php，也能执行。这些漏洞虽然老，但内网里跑着老版本IIS的服务器一抓一大把。

文件上传的绕过核心就一句话：前后端校验不一致，或者服务器解析配置有缺陷。防御也不复杂——后端白名单校验文件后缀，重命名文件，把上传目录设置为不可执行，用单独的文件服务器存储。但现实是，很多项目赶工期，上传功能随便写写就上线了。

上次帮朋友看一个CMS，上传功能只检查了文件后缀，而且黑名单里只有php和asp。我传了个php5，直接getshell。他问我怎么发现的，我说你这黑名单跟闹着玩似的。他苦笑，说这代码是三年前外包写的，一直没动过。

文件上传漏洞就是这样，技术含量不高，但架不住开发人员偷懒。渗透测试里遇到上传点，先试前端绕过，再试Content-Type，然后后缀大小写、空格、点号、特殊字符，最后试试解析漏洞。一套流程走下来，总能找到突破口。