文件解析漏洞总结（IIS,APACHE,NGINX）

（本文主体来自https://blog.csdn.net/qq_36119192/article/details/82834063）

文件解析漏洞

文件解析漏洞主要由于网站管理员操作不当或者 Web 服务器自身的漏洞，导致一些特殊文件被 IIS、apache、nginx 或其他 Web服务器在某种情况下解释成脚本文件执行。

 

比如网站管理员配置不当，导致php2、phtml、ascx等等这些文件也被当成脚本文件执行了。甚至某些情况下管理员错误的服务器配置导致.html、.xml等静态页面后缀的文件也被当成脚本文件执行。

 

但是，大部分的解析漏洞还是由于web服务器自身的漏洞，导致特殊文件被当成脚本文件执行了。

 

 

IIS解析漏洞

目录解析漏洞(/test.asp/1.jpg)

在 IIS5.x/6.0 中，在网站下建立文件夹的名字为*.asp、*.asa、*.cer、*.cdx 的文件夹，那么其目录内的任何扩展名的文件都会被IIS当做asp文件来解释并执行。例如创建目录 test.asp，那么 /test.asp/1.jpg 将被当做asp文件来执行。假设黑客可以控制上传文件夹路径，就可以不管上传后你的图片改不改名都能拿shell了

 

文件名解析漏洞(test.asp;.jpg)

在 IIS5.x/6.0 中， 分号后面的不被解析，也就是说 xie.asp;.jpg 会被服务器看成是xie.asp。还有IIS6.0默认的可执行文件除了asp还包含这两种 .asa   .cer 。而有些网站对用户上传的文件进行校验，只是校验其后缀名。所以我们只要上传 *.asp;.jpg、*.asa;.jpg、*.cer;.jpg 后缀的文件，就可以通过服务器校验，并且服务器会把它当成asp文件执行。

 

畸形解析漏洞(test.jpg/*.php)

微软发布了IIS7.0修补了IIS6.0的解析漏洞，没想到IIS7.0爆出更严重的畸形解析漏洞，于是微软急忙发布了IIS7.5

在 IIS7.0中，在默认Fast-CGI开启状况下，我们往图片里面写入下面的代码

 

将文件保存成test.jpg格式，上传到服务器，假设上传路径为/upload，上传成功后，直接访问/upload/test.jpg/x.php，此时神奇的畸形解析开始发挥作用啦。test.jpg将会被服务器当成php文件执行，所以图片里面的代码就会被执行。我们会神奇的发现在 /upload 目录下创建了一个一句话木马文件 shell.php 。

 

临时解决办法：设置 cgi.fix_pathinfo为0

 

这个解析漏洞和下面讲的Nginx的解析漏洞是一样的。

 

其他解析漏洞

在windows环境下，xx.jpg[空格]  或 xx.jpg.  这两类文件都是不允许存在的，若这样命名，windows会默认除去空格或点，黑客可以通过抓包，在文件名后加一个空格或者点绕过黑名单。若上传成功，空格和点都会被windows自动消除。

 

 

Ngnix解析漏洞

畸形解析漏洞(test.jpg/*.php)

漏洞原因：

 

php的配置文件 php.ini 文件中开启了 cgi.fix_pathinfo

/etc/php5/fpm/pool.d/www.conf中不正确的配置security.limit_extensions，导致允许将其他格式文件作为php解析执行

在nginx<0.8.03环境中，我们新建一个文件，内容为： ，然后将其名字修改为:  test.jpg

 

在浏览器中访问 http://192.168.10.139/test.jpg  显示图片解析错误。在浏览器中访问 http://192.168.10.139/test.jpg/test.php ，显示：Access denied.  。这就奇怪了，test.jpg是文件不是目录，test.php更是根本就不存在的文件，访问/test.jpg/test.php没有报404，而是显示  Access denied.  。

 

 

 

原因在于，Nginx拿到文件路径（更专业的说法是URI）/test.jpg/test.php 后，一看后缀是.php，便认为该文件是php文件，于是转交给php去处理。php一看 /test.jpg/test.php 不存在，便删去最后的/test.php，又看/test.jpg存在，便把/test.jpg当成要执行的文件了，又因为后缀为.jpg，php认为这不是php文件，于是返回  Access denied. 。

 

这其中涉及到php的一个选项：cgi.fix_pathinfo，该值默认为1，表示开启。开启这一选项有什么用呢？看名字就知道是对文件路径进行处理。举个例子，当 php 遇到文件路径 /aaa.xxx/bbb.yyy/ccc.zzz  时，若 /aaa.xxx/bbb.yyy/ccc.zzz 不存在，则会去掉最后的 /ccc.zzz ，然后判断 /aaa.xxx/bbb.yyy 是否存在，若存在，则把 /aaa.xxx/bbb.yyy 当做文件  /aaa.xxx/bbb.yyy/ccc.zzz ，若   /aaa.xxx/bbb.yyy  仍不存在，则继续去掉  /bbb.yyy ，以此类推。

 

该选项在配置文件 php.ini 中。若是关闭该选项，访问 http://127.0.0.1/test.jpg/test.php 只会返回找不到文件。但关闭该选项很可能会导致一些其他错误，所以一般默认是开启的。

 

但是目前我们还没能成功执行代码，test.jpg 没有当成php文件执行，只是返回了 Access denied ，因为新版本的php引入了security.limit_extensions ，限制了可执行文件的后缀，默认只允许执行.php文件。

 

这一漏洞是由于Nginx中php配置不当而造成的，与Nginx版本无关，但在高版本的php中，由于security.limit_extensions 的引入，使得该漏洞难以被成功利用。

 

为何是Nginx中的php才会有这一问题呢？因为Nginx只要一看URL中路径名以.php结尾，便不管该文件是否存在，直接交给php处理。而如Apache等，会先看该文件是否存在，若存在则再决定该如何处理。cgi.fix_pathinfo是php具有的，若在php前便已正确判断了文件是否存在，cgi.fix_pathinfo便派不上用场了，这一问题自然也就不存在了。（IIS在这一点和Nginx是一样的，同样存在这一问题）

 

%00空字节代码解析漏洞

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

 

在以下版本的nginx中，我们在图片中嵌入PHP代码然后通过访问 xxx.jpg%00.php 来执行其中的代码

 

 Nginx 0.5.*

 Nginx 0.6.*

 Nginx 0.7 <= 0.7.65

 Nginx 0.8 <= 0.8.37

 

CVE-2013-4547(%20%00)

影响nginx版本：nginx 0.8.41 ~ 1.5.6

 

这一漏洞的原理是非法字符空格和截止符（%00）会导致Nginx解析URI时的有限状态机混乱，危害是允许攻击者通过一个非编码空格绕过后缀名限制。是什么意思呢？举个例子，假设服务器上存在文件：“file.jpg ”，注意文件名的最后一个字符是空格。则可以通过访问：

 

http://127.0.0.1/file.jpg \0.php 

让Nginx认为文件“file.jpg ”的后缀为“.php”。

 

来测试下，这次测试在Nginx/1.0.15中进行。首先准备一张图片，命名为“test.html ”，注意，文件名含有空格。然后在浏览器中访问该文件，会得到一个404，因为浏览器自动将空格编码为%20，服务器中不存在文件“test.html%20”。

 

测试目标是要让Nginx认为该文件是图片文件并正确地在浏览器中显示出来。我们想要的是未经编码的空格和截止符（\0），怎么办呢？使用Burp Suite抓取浏览器发出的请求包，修改为我们想要的样子，原本的URL是：http://192.168.56.101/test.htmlAAAjpg ,将第一个“A”改成“20”（空格符号的ASCII码），将第二个“A”改成“00”（截止符），将第三个“A”改成“2e”（“.”的ASCII码），如图

 

 

 

修改完毕后Forward该请求，在浏览器中看到：

 

 

 

我们已经成功地利用了漏洞！但这有什么用呢？我们想要的是代码被执行。

 

继续测试，准备文件“test.jpg ”，注意文件名的最后一个字符是空格，上传到服务器。文件内容为：

 

 

 

用Burp Suite抓包并修改，原本的URL是：http://192.168.56.101/test.jpg…php ,将jpg后的第一个“.”改为20，第二个“.”改为00，如下图所示：

 

 

 

修改完毕后 Forword 该请求，在浏览器中看到：Access  denied  ，好吧，又是这个。

 

这说明Nginx在接收到这一请求后，确实把文件“test.jpg ”当做php文件交给php去执行了，只是php看到该文件后缀为“.jpg ”而拒绝执行。这样，便验证了Nginx确实存在该漏洞。但是由于 security.limit_extensions 的存在，导致我们并不能利用此漏洞

 

Apache解析漏洞

文件名解析漏洞

apache是从右到左开始判断解析，如果为不可识别解析，就再往左判断。比如 xie.php.owf.rar     .owf和.rar 这两种后缀是apache不可识别的解析，apache就会把xie.php.owf.rar解析成 xie.php 。如何判断是不是合法的后缀就是这个漏洞的利用关键，测试时可以尝试上传一个 xie.php.rara.jpg.png..(把你知道的后缀都写上去)去测试是否是合法后缀。任意不识别的后缀，逐级向上识别。

 

罕见后缀

计算机世界自开天辟地以来，便自由多彩。还记得mime.types文件吗？在该文件中搜索“php”这三个字母，结果如下所示：

1.   werner@Yasser:~$ cat /etc/mime.types | grep php
2.   #application/x-httpd-php          phtml pht php
3.   #application/x-httpd-php-source           phps
4.   #application/x-httpd-php3         php3
5.   #application/x-httpd-php3-preprocessed        php3p
6.   #application/x-httpd-php4         php4
7.   #application/x-httpd-php5         php5

还记得正则表达式”.+\.ph(p[345]?|t|tml)$”吗，该正则表达式匹配的不仅仅有php，还有php3、php4、php5、pht和phtml。

好吧，原来不仅php，就连phtml、pht、php3、php4和php5都是Apache和php认可的php程序的文件后缀。我原本只知道“.php”的，真是大开眼界。这就好比，不仅py是Python程序文件的后缀，还有pyc和pyo也都是。写上传过滤规则的程序员是否博学多识，也知道这些知识呢？我想，大抵是不知道的。利用这些“罕见”的后缀名，也可能绕过安全检查，干些“坏事”。

我在Ubuntu14.04+Apache2.4.7中进行测试，先准备文件text.php，其内容是经典的Hello World：

 

然后在浏览器中打开它，成功显示“HELLO WORLD”。再修改该文件后缀为各种后缀，进行测试。测试结果是，以php、phtml、pht、php3、php4和php5为后缀，能成功看到“HELLO WORLD”；以phps为后缀，会报403错误，Forbidden；以php3p为后缀，会在浏览器中看到源码。

 

 

 

.htaccess文件

.htaccess文件是Apache服务器中的一个配置文件，它负责相关目录下的网页配置。通过 .htaccess文件，可以实现：网页301重定向、自定义404错误页面、改变文件扩展名、允许/阻止特定的用户或者目录的访问、禁止目录列表、配置默认文档等功能IIS平台上不存在该文件，该文件默认开启，启用和关闭在 httpd.conf 文件中配置。

 

 .htaccess 文件生效前提条件为：

mod_rewrite 模块开启

AllowOverride All

 

#1：这个.htaccess的意思就是把所有名字里面含有shell的文件当成php脚本来执行

 

SetHandler  application/x-httpd-php 

 

#2：这里代码的意思可以让 .jpg后缀名文件格式的文件名以php格式解析

AddType application/x-httpd-php .jpg