IIS6中的解析漏洞
下面是iis6文件解析的原理：
1、當(dāng)WEB目錄下，文件名以 xxx.asp;xxx.xxx 來進行命名的時候，此文件將送交asp.dll解析(也就是執(zhí)行腳本)
2、當(dāng)WEB目錄下，在訪問以 xxx.asp 命名的目錄下的任意文件時，此文件將送交asp.dll解析(也就是執(zhí)行腳本)
我們都知道IIS6中間件主要解析的就是asp語言的文件，如果你放入一個JAVA語言的文件，php語言的文件他是不會進行解析的，只能當(dāng)做文本文件進行顯示出來，而里面語法所表達的意思是不會執(zhí)行的。那么從iis底層審計原理和測試發(fā)現(xiàn)IIS6在解析文件時存在如下問題：
1、后綴如下會被當(dāng)做asp程序進行執(zhí)行 .asp .cer .asa .cdx
2、IIS 6.0在處理含有特殊符號的文件路徑時會出現(xiàn)邏輯錯誤，從而造成文件解析漏洞。這一漏洞有兩種完全不同的利用方式： /test.asp/test.jpg test.asp;.jpg
為什么說這樣的解析我們叫做漏洞呢？而不叫做多一種解析方式呢？
主要的原因是很多研發(fā)在編寫上傳功能的時候會進行黑名單活著白名單的判斷，而往往不了解這種解析漏洞，忽略了這種校驗，從而被其他人繞過上傳能解析的大小馬。
比如：有一個頭像上傳功能，開發(fā)者后臺只允許上傳后綴為jpg的文件，其他文件不允許上傳，而黑客利用第二條解析漏洞上傳了個1.asp;.jpg這時候能順利的將該文件上傳到服務(wù)器中，如果服務(wù)器只是將其按照圖片解析，那么里面插入的asp馬腳本就解析不成功無法發(fā)揮馬的作用，但是iis6會將其安裝asp文件解析，因此這個馬就能起到馬的作用，從而被黑客利用。
而iis6由于是設(shè)計上的缺陷，因此該漏洞沒有廠家的修復(fù)方案，只要研發(fā)在本身上傳功能上對上述漏洞進行過濾。
IIS7/IIS7.5中的解析漏洞
漏洞影響 IIS7 及IIS7.5 在使FastCGI方式調(diào)用php時，在php.ini里設(shè)置cgi.fix_pathinfo=1
使得訪問任意文件URL時，在URL后面添加“/x.php”等字符時，該文件被iis當(dāng)php文件代碼解析。
如制作1.gif圖片馬（在圖片中插入php馬腳本）正常情況下訪問 http://127.0.0.1/1.gif 的內(nèi)容為正常的圖片，里面的php腳本并不會執(zhí)行，因為IIS7/IIS7.5只會按照圖片的解析格式來進行解析。當(dāng)訪問 http://127.0.0.1/1.gif/1.php可以看到1.gif里的php代碼被iis解析執(zhí)行了。 那么“黑客”在具體利用網(wǎng)站漏洞的時候，先可以通過網(wǎng)站提供的圖片上傳功能（也可以是其他的手段）上傳一個包含了惡意PHP代碼的圖片文件。然后通過上面描敘方法，讓iis解析執(zhí)行任意惡意的php代碼，控制網(wǎng)站及主機，最終導(dǎo)致網(wǎng)站被“脫庫”、“掛馬”、“植入非法seo鏈接”等等嚴(yán)重后果。
IIS7/IIS7.5解析漏洞的修復(fù)方案有如下幾個：
第1種方案：繼續(xù)使用FastCGI方式調(diào)用PHP，要解決這個安全問題可以在php.ini里設(shè)置 cgi.fix_pathinfo=0 ，修改保存后建議重啟iis(注意可能影響到某些應(yīng)用程序功能)。
第2種方案：使用ISAPI的方式調(diào)用PHP。（注意：PHP5.3.10已經(jīng)摒棄了 ISAPI 方式）
第3種方案：可以使用其他web服務(wù)器軟件，如Apache等。
IIS漏洞發(fā)展史
在文章的最后我們引用“千里目實驗室“搜集的近十五載的IIS相關(guān)漏洞，中、高危漏洞共計39個，其中15年爆發(fā)的(MS15-034)HTTP.sys 遠程執(zhí)行代碼漏洞和16年的(MS16-016)WebDAV 特權(quán)提升漏洞影響范圍尤其廣泛。
