文件解析漏洞

文件解析漏洞，是指中間件（Apache、nginx、iis等）在解析文件時出現了漏洞，從而，黑客能夠利用該漏洞實現非法文件的解析。

須要注意的是解析漏洞與上傳漏洞是兩碼事，文件解析漏洞是基於文件上傳以後而言的。

好比，Apache中間件，是c、c++混合寫成的，當Apache中間件出現瞭解析漏洞，即：c、c++編程出現了漏洞，不管咱們php代碼層面如何的安全，都沒辦法抵擋黑客的攻擊，由於如今的漏洞已經與php代碼層無關了，已是底層的安全問題了，文件解析漏洞就是由於Apache中間件c、c++編程出現了漏洞，致使黑客能夠利用該漏洞解析非法文件。

因此，底層安全比任何安全都要重要，至少咱們從如今起，要開始重視底層安全了。

Apache解析php文件原理：

Apache（httpd.exe）運行以後，而後開始監聽web瀏覽器發送的php請求，攔截php請求，簡單處理以後，再將該請求告知php解析器（Apache module 或者 fast-CGI）解析特定的php文件，php解析器解析文件完成以後，返回html頁面給Apache，Apache再將html頁面響應到web瀏覽器，就這樣如此循環。

Apache有兩種方式解析php文件：

一、 module方式

二、 fast-cgi方式

任何一種方式均可以在httpd.conf文件中設置

一、CGI方式

PHP 在 Apache 2.0 中的 CGI 方式

ScriptAlias /php/ "c:/php/"

AddType application/x-httpd-php .php

# 對 PHP 4 用這行

Action application/x-httpd-php "/php/php.exe"

# 對 PHP 5 用這行

Action application/x-httpd-php "/php/php-cgi.exe"

二、APACHE Module方式

PHP 在 Apache 2.0 中的模塊方式

# 對 PHP 4 用這兩行：

LoadModule php4_module "c:/php/php4apache2.dll"

# 別忘了從 sapi 目錄中把 php4apache2.dll 拷貝出來！

AddType application/x-httpd-php .php

# 對 PHP 5 用這兩行：

LoadModule php5_module "c:/php/php5apache2.dll"

AddType application/x-httpd-php .php

# 配置 php.ini 的路徑

PHPIniDir "C:/php"

這兩種解析方式的區別：

在CGI模式下，若是客戶機請求一個php文件，Web服務器就調用php.exe去解釋這個文件，而後再把解釋的結果以網頁的形式返回給客戶機。而在模塊化(DLL)中，PHP是與Web服務器一塊兒啓動並運行的。因此從某種角度上來講，以apache模塊方式安裝的PHP4有着比CGI模式更好的安全性以及更好的執行效率和速度。

Fast-CGI是什麼？

FastCGI是語言無關的、可伸縮架構的CGI開放擴展，其主要行爲是將CGI解釋器進程保持在內存中並所以得到較高的性能。衆所周知，CGI解釋器的反覆加載是CGI性能低下的主要緣由，若是CGI解釋器保持在內存中並接受FastCGI進程管理器調度，則能夠提供良好的性能、伸縮性、Fail-Over特性等等。

Fast-CGI的工做原理：

一、 Web Server 啓動時載入FastCGI進程管理器（IIS ISAPI或Apache Module）

二、FastCGI進程管理器自身初始化，啓動多個CGI解釋器進程 (在任務管理器中可見多個php-cgi.exe)並等待來自Web Server的鏈接。

三、當客戶端請求到達Web Server時，FastCGI進程管理器選擇並鏈接到一個CGI解釋器。Web server將CGI環境變量和標準輸入發送到FastCGI子進程php-cgi.exe。

四、FastCGI子進程完成處理後將標準輸出和錯誤信息從同一鏈接返回Web Server。當FastCGI子進程關閉鏈接時，請求便告處理完成。FastCGI子進程接着等待並處理來自FastCGI進程管理器（運行在 WebServer中）的下一個鏈接。 在正常的CGI模式中，php-cgi.exe在此便退出了。

在上述狀況中，你能夠想象 CGI一般有多慢。每個Web請求PHP都必須從新解析php.ini、從新載入所有dll擴展並重初始化所有數據結構。使用FastCGI，全部這些都只在進程啓動時發生一次。一個額外的好處是，持續數據庫鏈接(Persistent database connection)能夠工做。

接下里，回到正題

在Apache解析正常php文件的時候，固然是沒有什麼大問題的，可是，當出現畸形文件的時候，Apache又該如何處理呢？

其實，在httpd.conf文件中，有個設置：DefaultType text/plain

這個設置告訴咱們，Apache在遇到沒法識別的文件時，他會作出怎麼的反應

DefaultType text/plain

在這樣的設置前提下，當Apache遇到沒法識別的文件時，就會將這些沒法識別的文件統統做爲文本文件來解析。

在此，沒法識別是什麼意思呢？

原來，在Apache的conf目錄下面有個mime.types文件（Linux在etc/mime.types），這個文件的內容就是Apache預約義的一些能夠正常解析的文件。

好比，圖片文件：

image/g3fax g3

image/gif gif

image/ief ief

# image/jp2

image/jpeg jpeg jpg jpe

# image/jpm

# image/jpx

# image/naplps

image/png png

當Apache遇到正常文件，卻沒法解析的時候，你能夠在這裏面手動添加解析類型

好比，你想下載一個word文檔，可是，webserver（Apache）卻把word文檔以rar文件的形式返回給你，這種狀況，就是由於Apache沒有在mime.types文件（或是httpd.conf文件）中識別到word文檔，那麼，他只能經過分析該文檔的自己內容，認爲他是一個壓縮文件，最後，就返回給你一個壓縮文件了，至因而什麼格式的壓縮文件，只有Apache才知道了。

此時，若是咱們要Apache能正常識別word文檔，就須要在mime.types文件中加上如下三句話：

application/vnd.ms-word.document.macroEnabled.12 docm

application/vnd.openxmlformats-officedocument.wordprocessingml.document docx

application/vnd.openxmlformats-officedocument.wordprocessingml.template dotx

這樣，Apache就能夠正常給你返回word文檔了。

其實，也能夠在http.conf文件中設置文件解析類型

使用Apache的AddType 指令設置：

AddType application/vnd.ms-word.document.macroEnabled.12 docm

AddType application/vnd.openxmlformats-officedocument.wordprocessingml.document docx

AddType application/vnd.openxmlformats-officedocument.wordprocessingml.template dotx

建議不要去修改mime.types文件，添加文件解析類型推薦使用Apache的AddType指令。

所以，在mime.types文件或者httpd.conf文件中都沒法識別的文件解析類型，Apache就會默認按照DefaultType text/plain這個字段給出的值來解析這個沒法識別的文件，也許在使用這個值以前，還有一段解析驗證，好比，下載word文檔而返回rar文件，這個還有待考證。

有興趣的能夠研究下Apache的源代碼

|-- build      安裝腳本

|    |-- pkg

|    |-- rpm

|    `-- win32

|-- docs      文檔

|    |-- cgi-examples

|    |-- conf

|    |-- docroot

|    |-- error

|    |-- icons

|    |-- man

|    `-- manual

|-- include   頭文件

|-- modules      apache模塊

|    |-- aaa      各類auth,都是a開頭的，因此叫aaa?

|    |-- arch     和系統相關的mod

|    |-- cache    緩存相關。disk/file/mem cache

|    |-- database mod_dbd是用來鏈接關係數據庫的

|    |-- dav       mod_dav

|    |-- debug    幾個調試相關的mod mod_dumpio mod_bucketeer

|    |-- echo      代碼很短。這個mod應該是mod開發參考用的吧

|    |-- experimental mod_example是一個註釋很詳細的mod，果真是mod——example

|    |-- filters     過濾器：mod_filter

|    |-- generators 處理器mod： asis info cgi(d) status autoindex suexec

|    |-- http       mod_mine : 根據文件擴展名決定應答的行爲和內容

|    |-- ldap       mod_ldap : 提供ldap鏈接

|    |-- loggers    各類日誌 ：mod_logconfig mod_log_forensic mod_logio

|    |-- mappers    在客戶端到generator過程當中進行重定向的許多mod

|    |-- metadata 感受像Miscellaneous，許多東西，不知道爲何放在一塊兒

|    |-- proxy      天然是mod_proxy,將請求proxy到其餘程序

|    |-- ssl        提供ssl鏈接

|    `-- test

|-- os         操做系統相關的東西，各個不一樣的操做系統須要定義各自的宏，還有少許特別的函數

|    |-- beos

|    |-- bs2000

|    |-- netware

|    |-- os2

|    |-- tpf

|    |-- unix

|    `-- win32

|-- server   apache核心程序httpd就是這裏來的

|    `-- mpm

|-- srclib   

|    |-- apr   apr和apr-util是apache的底層庫，強調的是Portable

|    |-- apr-util

|    `-- pcre   PCRE是一個Perl庫，包含了perl兼容的正規表達式庫

|-- support    apache運行的一些工具，bin裏面除了httpd幾乎都在這裏了

|    |-- SHA1

|    `-- win32

`-- test

這是Apache的源代碼結構

那麼，咱們的文件解析漏洞是發生在那個分支上呢？

這個問題就留給你們去解決了。

接下里，說一下filefuzz技術

文件解析漏洞的挖掘，推薦兩款框架/工具：Sulley Fuzz、Peach Fuzz

其實，這兩款框架/工具學起來仍是比較費時的，我再推薦一款簡單的fuzz插件

Fuzzdb：fuzzdb是一個應用程序模糊測試(fuzzing)數據庫，fuzzdb彙集到最全面的惡意軟件和惡意的輸入測試用例的開放源碼數據庫的攻擊模式。

該數據庫收集了大量已知的攻擊模式，如XSS，Xpath注入，SQL注入，XML攻擊，本地文件包含，路徑遍歷，遠程文件包含，ldap攻擊，格式化字符串，http協議攻擊等。

該插件與burpsuite的intruder功能結合，十分強大，可與AWVS、sqlmap、pangolin等工具匹敵了！