【网络安全 --- web服务器解析漏洞】IIS，Apache，Nginx中间件常见解析漏洞

一，工具及环境准备

以下都是超详细保姆级安装教程，缺什么安装什么即可（提供镜像工具资源）

二，服务器解析漏洞

服务器解析漏洞算是历史比较悠久了，但如今依然广泛存在。在此记录汇总一些常见服务器（WEB server）的解析漏洞，比如IIS6.0、IIS7.5、apache、nginx等方便以后回顾温习。

2-1 IIS5.x-6.x解析漏洞

## 使用iis5.x-6.x版本的服务器，大多为windows server 2003，网站比较古老，开发语句一般为asp；该解析漏洞也只能解析asp文件，而不能解析aspx文件。win7-win10中多为iis7.x-8.x了，版本比较高。

目录解析(6.0)
形式：www.xxx.com/xx.asp/xx.jpg
原理: 服务器默认会把.asp，.asa目录下的文件都解析成asp文件。

文件解析
形式：www.xxx.com/xx.asp;.jpg
原理：服务器默认不解析;号后面的内容，因此xx.asp;.jpg便被解析成asp文件了。

解析文件类型
IIS6.0 默认的可执行文件除了asp还包含这三种 :
/test.asa
/test.cer
/test.cdx

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

2-1-1 www.xxx.com/xx.asp;.jpg

我们演示一个www.xxx.com/xx.asp;.jpg

我们打开凡诺企业管理系统网站（靶场安装请看第一部分工具及环境准备）

这个首页就是index.asp ,我们复制一份这个index.asp,重命名为show.asp;.jpg 如下：

然后浏览器访问 http://192.168.31.208/show.asp;.jpg

发现依然能访问成功，这就是一个解析漏洞，如果发现asp网站有能上传图片的地方，可以使用这种方法上传asp木马程序来绕过验证

2-1-2 www.xxx.com/xx.asp/xx.jpg

原理: 服务器默认会把.asp，.asa目录下的文件都解析成asp文件。

浏览器访问 192.168.31.208/xx.asp/index.jpg

我们发现报错了，不过报错也正常，因为首页肯定包含一些别的代码文件，我们把首页移动到了别的目录，当然找不到这些包含的路径了，所以报错，而上图也显示确实找不到一个包含文件，但是肯定的是index.jpg当一个asp文件执行了，只是执行的时候由于路径问题报错了而已

2-1-3 index.asa | index.cer | index.cdx

IIS6.0 默认的可执行文件除了asp还包含这三种 :
/test.asa
/test.cer
/test.cdx

选一个演示一下，我们把首页的index.asp改名字改为index.cer

访问效果如下，也能进行访问

cer文件一般是证书文件，iis默认也是可以解析的，我们来看网站属性

2-2 apache 解析漏洞

漏洞原理
　 Apache 解析文件的规则是从右到左开始判断解析,如果后缀名为不可识别文件解析,就再往左判断。比如test.php.owf.rar “.owf”和”.rar” 这两种后缀是apache不可识别解析,apache就会把xx.php.owf.rar解析成php。

## 漏洞形式
www.xxxx.xxx.com/test.php.php123这个漏洞当时通杀了所有的apache搭建的网站。

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

示例：www.xxxx.xxx.com/test.php.php123

以pikachu靶场为例（靶场安装请看第一部分工具及环境准备）

比如我们将sql.php改为sql.php.xxxx，正常来讲的话是不能解析的，但是老版本的apache(apache2.2版本及之前的)是能够正常将这个文件解析为php文件的

我用的是新版本的apache，没搭建老版本的，所以这个漏洞大家就记住他就行了，当然，新版本的apache如果配置不当也会引起这个漏洞，有兴趣的大家可以去安装一个低版本的apache来玩玩，你看新版本的就不解析运行代码了，直接把源代码给你看，而不是将源代码执行了。以前大家通过黑名单的方式来防御的，基本都挂了，因为你发现后缀名你随意写

其余配置问题导致漏洞

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

这两个漏洞不是apache自身的问题，而是运维人员进行配置时，自己配置的出了问题。

这里就不演示了

修复方案

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

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

2.用伪静态能解决这个问题，重写类似.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>

2-3 nginx解析漏洞

大致原理：该漏洞与nginx、php版本无关，属于配置不当造成的解析漏洞。

## 当php.ini配置文件中开启了cgi.fix_pathinfo，该值默认为1，表示开启。看名字大概知道是处理路径用的配置。

## 比如我们上传了一个木马文件web.jpg，因为web.php不能上传，现在我们想执行这个web.jpg，可以如下路径访问
http://192.168.2.104/pikachu/web.jpg/aaa.php

## 而目标服务器上没有aaa.php文件，本来如果nginx.conf的配置没有问题的话，nginx会先去找下这个文件是否存在，如果存在，在找php解释器来解释执行代码，如果不存在，nginx会直接返回错误信息，说找不到该文件，但是如果nginx.conf配置不当会导致nginx把以’.php’结尾的文件交给fastcgi处理，也就是说首先nginx看到你路径中要找aaa.php，哦，原来是php文件，nginx不去找这个文件了，而是就直接交给了fastcgi，fastcgi又去找php解释器去处理该路径，而php开启了cgi.fix_pathinfo，那么php解释器处理这个路径的时候，发现没有aaa.php文件，那么他会找路径中上一层路径的文件作为aaa.php来运行，如是乎就找到了web.jpg，将web.jpg当作aaa.php来运行了，所以代码被执行，看到如下效果

示例：我们通过phpstudy来改成nginx运行（pikachu靶场）

fix_pathinfo这个功能参数默认是开启的，所以这个漏洞影响也是比较大的，我们访问一下phpinfo.php文件，看看这个功能是否开启了。

值为1表示开启状态，那么就存在这个漏洞

比如我将一个木马文件，改为.jpg文件，放到pikachu的文件夹下

（这个木马文件在文件上传闯关靶场的工具资料里给过，需要的看我下面这篇博客下载）

【网络安全 --- 任意文件上传漏洞靶场闯关 6-15关】任意文件上传漏洞靶场闯关，让你更深入了解文件上传漏洞以及绕过方式方法，思路技巧-CSDN博客文章浏览阅读901次，点赞3次，收藏2次。【网络安全 --- 任意文件上传漏洞靶场闯关 6-15关】任意文件上传漏洞靶场闯关，让你更深入了解文件上传漏洞以及绕过方式方法，思路技巧https://blog.csdn.net/m0_67844671/article/details/134114898?spm=1001.2014.3001.5502

然后通过浏览器来访问一下

能看出，默认是不能访问的，我们只要在路径后面加上一个 /tu.php ，就能够按照php来解析了，直接就是漏洞。因为图片我们是正常能够上传的，上传过去之后，如果是nginx来解析的，并且开启了cgi.fix_pathinfo功能，那么基本上属于被你拿下了。

其他漏洞形式

www.xxxx.com/UploadFiles/image/1.jpg/1.php，这是上面说的漏洞
www.xxxx.com/UploadFiles/image/1.jpg%00.php #我们试过这个00截断，除了apache之外，nginx也有这个00截断漏洞,这个导致的效果是：1.jpg会被当成php文件来解析。

www.xxxx.com/UploadFiles/image/1.jpg/%20\0.php #也算是00截断的一种

xxx.jpg%00.php (Nginx <0.8.03版本存在空字节代码执行漏洞)

修复方案 ：

1.修改php.ini文件，将cgi.fix_pathinfo的值设置为0;

2.在Nginx配置文件中添加以下代码：

if ( $fastcgi_script_name ~ ..*/.*php ) {
 return 403;
}

这行代码的意思是当匹配到类似test.jpg/a.php的URL时，将返回403错误代码。

2-4 IIS7.x解析漏洞

IIS7.5的漏洞与nginx的类似，都是由于php配置文件(php.ini文件)中，开启了cgi.fix_pathinfo，而这并不是nginx或者iis7.5本身的漏洞，都是配置不当引起的。

PHP - - phpStudy

当安装完成后， php.ini里默认cgi.fix_pathinfo=1，对其进行访问的时候，在URL路径后添加.php后缀名会当做php文件进行解析，漏洞由此产生

php.ini文件配置

虽然通过配置上看，我们发现是有这个漏洞的，但是实际测试过程中，并不是那么简单，如下，注意，下面的示例是用的phpstudy2016版本来演示的，win7及以上的系统才行昂，win2003不行的，勾选iis的时候，可能会提示你，说你没有尚未安装iis 7/8，大家自行安装一下即可。按照这个phpstudy的官网来安装：PHP - - phpStudy，其中要激活CGI功能，别忘了。