文件上傳解析漏洞

文件上傳漏洞

文件上傳漏洞是指網絡攻擊者上傳了一個可執行的文件到服務器並執行。這裡上傳的文件可以是木馬，病毒，惡意腳本或者WebShell等。

由於程序員在對用戶文件上傳部分的控制不足或者處理缺陷，而導致用戶可以越過其本身權限向服務器上傳可執行的動態腳本文件。

打個比方來說，如果你使用 windows 服務器並且以 asp 作為服務器端的動態網站環境，那麼在你的網站的上傳功能處，就一定不能讓用戶上傳 asp 類型的文件，否則他上傳一個 webshell，你服務器上的文件就可以被他任意更改了。因此文件上傳漏洞帶來的危害常常是毀滅性的，Apache、Tomcat、Nginx等都曝出過文件上傳漏洞。

文件上傳漏洞危害

上傳漏洞與SQL注入或 XSS相比，其風險更大，如果 Web應用程序存在上傳漏洞，攻擊者上傳的文件是Web腳本語言，服務器的Web容器解釋並執行了用戶上傳的腳本，導致代碼執行。如果上傳的文件是Flash的策略文件crossdomain.xml，黑客用以控制Flash在該域下的行為。

如果上傳的文件是病毒、木馬文件，黑客用以誘騙用戶或者管理員下載執行。如果上傳的文件是釣魚圖片或為包含了腳本的圖片，在某些版本的瀏覽器中會被作為腳本執行，被用於釣魚和欺詐。甚至攻擊者可以直接上傳一個webshell到服務器上 完全控制系統或致使系統癱瘓。

文件上傳漏洞原理

大部分的網站和應用系統都有上傳功能，而程序員在開發任意文件上傳功能時，並未考慮文件格式後綴的合法性校驗或者是否只在前端通過js進行後綴檢驗。

這時攻擊者可以上傳一個與網站腳本語言相對應的惡意代碼動態腳本，例如(jsp、asp、php、aspx文件後綴)到服務器上，從而訪問這些惡意腳本中包含的惡意代碼，進行動態解析最終達到執行惡意代碼的效果，進一步影響服務器安全。

文件上傳漏洞滿足條件

1. 文件上傳功能能正常使用

2. 上傳文件路徑可知

3. 上傳文件可以被訪問

4. 上傳文件可以被執行或被包含

文件上傳數據包解析

Content-Length：即上傳內容大小

MAX_FILE_SIZE：即上傳內容的最大長度

Filename：即上傳文件名

Content-Type：即上傳文件類型

請求包中的亂碼字段，即是所上傳文件的內容

文件上傳漏洞繞過技巧

1、客戶端校驗（js檢測）：

一般是在網頁上寫一段Js腳本，用Js去檢測，校驗上傳文件的後綴名的合法性問題。

在檢查擴展名是否合法的時候，有兩種策略：白名單策略和黑名單策略。

判斷方式：在瀏覽加載文件，但還未點擊上傳按鈕時便彈出對話框，內容如：只允許上傳.jpg/.jpeg/.png後綴名的文件，而此時並沒有發送數據包，所以可以通過抓包來判斷，如果彈出不準上傳，但是沒有抓到數據包，那麼就是前端驗證。其實，也可以直接查看網頁源代碼，源代碼中如果沒有js前端效驗，那麼就一定是後端效驗嘍。

繞過方法：這個限制是在客戶端進行的，這種限制形同虛設。傳正常文件改數據包就可以繞過，甚至關閉JS都可以嘗試繞過。

黑白名單機制：

黑名單：不允許上傳什麼，文件擴展名在黑名單中的為不合法。

白名單：只允許上傳什麼，文件擴展名不在白名單中的均為不合法。

白名單比黑名單更安全

2、服務端檢測：

檢查Content-Type （內容類型）

檢查後綴 （檢查後綴是主流）

檢查文件頭

繞過方法：假如將webshell代碼文件後綴改為其它被服務器認為是安全的後綴，再通過解析漏洞讓其按照腳本文件進行解析，就達到了最終的目的。

服務端MIME檢測繞過（Content-Type檢測）

HTTP協議規定了上傳資源的時候在Header中加上一項文件的MIMETYPE，來識別文件類型，這個動作是由瀏覽器完成的，服務端可以檢查此類型不過這仍然是不安全的,因為HTTP header可以被髮出者或者中間人任意的修改，不過加上一層防護也是可以有一定效果的。

繞過方法：使用burp代理，修改Content-Type的參數。

text/plain（純文本）

text/html（HTML文檔）

text/javascript（js代碼）

application/xhtml+xml（XHTML文檔）

image/gif（GIF圖像）

image/jpeg（JPEG圖像）

image/png（PNG圖像）

video/mpeg（MPEG動畫）

application/octet-stream（二進制數據）

application/pdf（PDF文檔）

application/(編程語言) 該種語言的代碼

application/msword（Microsoft Word文件）

message/rfc822（RFC 822形式）

multipart/alternative（HTML郵件的HTML形式和純文本形式，相同內容使用不同形式表示）

application/x-www-form-urlencoded（POST方法提交的表單）

multipart/form-data（POST提交時伴隨文件上傳的表單）

服務端擴展名檢測繞過：

在文件被上傳到服務端的時候，對於文件名的擴展名進行檢查，如果不合法，則拒絕這次上傳。在檢查擴展名是否合法的時候，有兩種策略：黑名單策略和白名單策略。

白名單策略是更加安全的，通過限制上傳類型為只有我們接受的類型，可以較好的保證安全，因為黑名單我們可以使用各種方法來進行注入和突破。

繞過方法：

文件名大小寫繞過，例如Php，AsP等類似的文件名

後綴名字雙寫嵌套，例如pphphp，asaspp等

可以利用系統會對一些特殊文件名做默認修改的系統特性繞過

可以利用asp程序中的漏洞，使用截斷字符繞過

可以利用不再黑名單列表中卻能夠成功執行的同義後綴名繞過黑名單的限制。

可以利用解析/包含漏洞配合上傳一個代碼注入過的白名單文件繞過。

1.老版本的IIS中的目錄解析漏洞，如果網站目錄中有一個 /.asp/目錄，那麼此目錄下面的一切內容都會被當作asp腳本來解析

2.老闆本的IIS中的分號漏洞：IIS在解析文件名的時候可能將分號後面的內容丟棄，那麼我們可以在上傳的時候給後面加入分號內容來避免黑名單過濾，如 a.asp;jpg

3.舊版Windows Server中存在空格和dot漏洞類似於 a.php. 和 a.php[空格] 這樣的文件名存儲後會被windows去掉點和空格，從而使得加上這兩個東西可以突破過濾，成功上傳，並且被當作php代碼來執行

4.nginx空字節漏洞 xxx.jpg%00.php 這樣的文件名會被解析為php代碼運行

5.apache的解析漏洞，上傳如a.php.rar a.php.gif 類型的文件名，可以避免對於php文件的過濾機制，但是由於apache在解析文件名的時候是從右向左讀，如果遇到不能識別的擴展名則跳過，rar等擴展名是apache不能識別的，因此就會直接將類型識別為php，從而達到了注入php代碼的目的

服務端文件頭內容檢測繞過：

這種方法利用的是每一個特定類型的文件都會有不太一樣的開頭或者標誌位。可以通過比如php的exif_imagetype()函數來檢測。

通過檢查頭幾位字節，可以分辨是否是圖片文件。

不同類型的文件都有對應的文件類型簽名（也叫類型幻數，簡稱文件頭），比如，PNG 的文件頭為十六進制的 89 50 4E 47 0D 0A 1A 0A；GIF 為 47 49 46 38 37 61、JPG 為 FF D8 FF E0。

通過在文件中添加正常文件的標識或其他關鍵字符繞過。

給上傳腳本加上相應的幻數頭字節就可以，php引擎會將

其他類型的二進制文件，也有相應的頭字節。

文件加載檢測繞過，針對渲染加載測試。

代碼注入繞過，針對二次渲染測試。

很多網站為了節省開發成本，直接使用現成的文本編輯器，如fckeditor，這種編輯器經常在網上被爆出漏洞，可以對這些漏洞進行利用。

3.1、文件解析漏洞

攻擊者在利用上傳漏洞時，通常會與Web容器的解析漏洞配合在一起。所以我們首先來了解一下解析漏洞，這樣才能更深入地瞭解上傳漏洞，並加以防範

常見的Web容器有ⅡS、Apache、Nginx、Tomcat等，下面主要講IIS、Apache、Nginx容器。

3.2、服務器解析漏洞

Apache1.x 2.x解析漏洞

Apache 解析文件的規則是從右到左開始判斷解析,如果後綴名為不可識別文件解析,就再往左解析，直到碰到認識的擴展名為止，如果都不認識，則會暴露其源代碼。

這種方法可以繞過基於黑名單的檢查。比如test.php.owf.rar。".owf"和".rar" 這兩種後綴是apache不可識別解析,apache就會把wooyun.php.owf.rar解析成php。

若一個文件名abc.x1.x2.x3，Apache會從x3開始解析，如果x3不是一個能解析的擴展名（mime.types文件裡面沒有定義的擴展名），就往前解析x2以此往復，直到能遇到一個能解析的文件名為止，如果都不認識就暴露源碼。

如果上傳的文件名使我們可以定義的，那麼我們可以完全上傳一個xxx.php.abc這樣名字的webshell，Apache仍然會當做PHP來解析。

IIS 5.x/6.0解析漏洞

asa cer cdx 也會被解析

IIS6.0除了將ASP後綴當做ASP進行解析的同時，當文件後綴名字為.asa、 .cer和 .cdx 也會當做asp去解析，這是因為IIS6.0在應用程序擴展中默認設置了.asa、.cer 和 .cdx 都會調用 asp.dll。

IIS 6.0在處理含有特殊符號的文件路徑時會出現邏輯錯誤，從而造成文件解析漏洞。IIS5.1和IIS7.5無此漏洞。

這一漏洞有兩種完全不同的利用方式文件解析和目錄解析：

1. 文件解析：分號後面的不被解析

test.asp;1.jpg 或者test.asp;.jpg 他將當做asp進行解析（特殊符號是";"）。

在IIS6.0下，分號後面的不被解析。

應用程序在驗證文件後綴的時候是驗證文件名最後的字串，如：text.asp;1.jpg，是圖片，但是在IIS6.0裡解析的時候，是忽略掉分號後面的字串，直接解析為test.asp。

2. 目錄解析：在文件夾為.asp和 .asa內的所有文件被當成解析文件解析

test.asp/1.jpg 他將當做asp進行解析（特殊符號是"/"）。

IIS6.0 在解析 asp 時，如果任意目錄名為 .asp、.asa 的文件夾，其目錄內的任何擴展名的文件都被IIS當作asp文件來解析並執行。

創建目錄test.asp，此目錄下的文件將被當作asp文件來執行。如果可以控制上傳文件夾路徑,就可以不管你上傳後你的圖片改不改名都能拿shell了。

IIS6.0解析原理：

請求 /test.asp;1.jpg

N1:從頭部查找,查找 "."號,獲得 .asp;1.jpg。

N2:查找";"號,如果有則內存截斷。

N3:查找"/",如果有則內存截斷。

最終,將保留下來 .asp 字符串,從META_SCRIPT_MAP腳本映射表裡與擴展名匹配對比,並反饋給了asp.dll處理。

IIS7.0/7.5 對php解析有所類似於 Nginx 的解析漏洞。只要對任意文件名在url後面追加上 字符串 / 任意文件名.php 就會按照php去解析。

舉個栗子：把一下代碼做成圖片馬text.jpg。

• 
  
• 
  
• 
  
• 
  

上傳test.jpg，然後訪問

test.jpg/.php或test.jpg/abc.php當前目錄下就會生成一句話木馬 123.php。

IIS 7.0/IIS 7.5/ Nginx <8.03畸形解析漏洞

在某些使用Nginx的網站中，訪問http://www.xxx.com/1.jpg/1.php，此時的1.jpg會被當作PHP腳本來解析，此時1.php是不存在的，卻可以看到1.jpg已經按照PHP腳本來解析了，問題就出現在這個"1.PHP"上（1.php並不是特定的，可以隨機命名）。這就意味著攻擊者可以上傳合法的"圖片"（圖片木馬），然後在URL後面加上"/xxx.php"，就可以獲得網站的WebShell。

這不是Nginx特有的漏洞，在IIS7.0、IIS7.5、Lighttpd等Web容器中也經常會出現這樣的解析漏洞。

這個解析漏洞其實是PHP CGI的漏洞，在PHP的配置文件中有一個關鍵的選項cgi.fix_pathinfo在本機中位於C:\\wamp\\bin\\php\\php5.3.10\\php.ini，默認是開啟的，當URL中有不存在的文件，PHP就會向前遞歸解析。

Nginx解析原理：

以下三個解釋，那個好理解就理解那個。

解釋一：

nginx在接受請求後會得到一個地址URL/abc.jpg/c.php

在經過location指令，將請求交給fastcgi處理，nginx為其設置環境變量SCRIPT_FILENAME,內容為/abc.jpg/c.php

後端的fastcgi在接受到該選項時，會根據PHP的fix_pathinfo配置決定是否對SCRIPT_FILENAME進行額外的處理，一般情況下如果不對fix_pathinfo進行設置將影響使用PATH_INFO進行路由選擇的應用，

所以該選項一般配置開啟。php通過該選項之後將查找其中真正的腳本文件名字，查找的方式也是查看文件是否存在，這個時候將分離SCRIPT_FILENAME和PATH_INFO分別為/scripts/abc.jpg和c.php

最後，以/scripts/abc.jpg作為此次請求需要執行的腳本，攻擊者就可以實現讓nginx以php來解析任何類型的文件了。

解釋二：

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,如果開啟了cgi.fix_pathinfo=1選項（這個默認值就是1，所以沒有設置過就是開啟），那麼就會觸發在PHP中的如下邏輯：

PHP會認為SCRIPT_FILENAME(絕對路徑)是phpinfo.jpg，而1.php是PATH_INFO，所以就會phpinfo.jpg作為PHP文件來解析了。也是一個邏輯問題，所以說我們只需要在正常的.jpg後面加/.php就可以成功的繞過解析。

解釋三：

IIS和Nginx在這一點上是一樣的，一看到URL中文件後綴是.php，便無論該文件是否存在，都直接交給php處理，而php又默認開啟"cgi.fix_pathinfo"，會對文件路徑進行"修理"，何謂"修理"？舉個例子，當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"，以此類推。

若有文件test.jpg，訪問時在其後加/.php，便可以讓IIS把"test.jpg/.php"交給php，php"修理"文件路徑"test.jpg/.php"得到"test.jpg"，該文件存在，便把該文件作為php程序執行了

asp沒有"cgi.fix_pathinfo"，所以不存在這一問題。

在默認Fast-CGI開啟狀況下,上傳一個名字為xx.jpg，內容為：

');?>

的文件，然後訪問xx.jpg/.php或xxx.jpg/1.php,在這個目錄下就會生成一句話木馬 shell.php文件。

Nginx <8.03 %00空字節執行php漏洞

Nginx如下版本：

0.5.*, 0.6.*, 0.7 <= 0.7.65, 0.8 <= 0.8.37

在使用PHP-FastCGI執行php的時候，URL裡面在遇到%00空字節時與FastCGI處理不一致，導致可在非php文件中嵌入php代碼，通過訪問url+%00.php來執行其中的php代碼。如：http://local/robots.txt%00.php會把robots.txt文件當作php來執行。

PHP的path_info

Path_info是什麼？

  Path_info是PHP的一種路由模式，需要PHP.ini中設置cgi.fix_pathinfo=1才能開啟該路由模式。該路由模式的URL格式為http://www.xxx.com/index.php/模塊/方法。

Path_info的運行機制

Apache容器

那在Apahce容器下，Path_info有什麼用呢？

  很多防火牆為了提高效率，遇到js,png,jpg等格式的後綴時，則不檢測後面參數中是否有非法數據，因此我們可以構造http://www.admintony.com/index.php/aaa.js?id=union select 1,2,3,4來繞過防火牆進行注入，當然也可以繞過防火牆進行代碼執行、命令執行等操作

IIS和Nginx容器

在IIS和Nginx容器下，相比Apache少了一步對文件後綴的檢測，因此產生了著名的安全問題CGI解析漏洞(也有稱Nginx解析漏洞)。

  其漏洞的利用方式就是上傳一個含Webshell的圖片，然後在圖片地址後面加上/a.php使圖片當作PHP解析。

比如 123.png/1.php,接收URL後，提取URL中請求的文件1.php，發現不存在就檢查是否存在上一級目錄，存在就把上級目錄當做請求文件，再判斷文件是否存在，文件123.png存在，然後就把123.png當做PHP解析執行，其中少了再次檢測存在文件的後綴名的操作就直接當做請求最開始文件的類型解析了。