文件上傳驗證繞過技術總結

文件上傳驗證繞過技術總結

 1.客戶端驗證繞過

很簡單啦，直接使用webscarab或者burp修改一下後綴名就行。

2.服務端驗證繞過-Content-type檢測

若服務端檢測文件類型時是檢測Content-type的值，也很簡單，在webscarab或者burp中修改Content-type。

如php中 if($_FILES['userfile']['type'] != 「image/gif」) 便是檢測Content-type值。

3.服務端驗證繞過-擴展名檢測

a. 尋找漏網之魚，如fckeditor 2.4.3 或以前版本的黑名單中就能夠上傳諸如asa，cer之類的文件。

b. 大小寫繞過，如aSp，pHp。

c. 特別文件名構造。

好比發送的http 包裏把文件名改爲help.asp. 或help.asp_(下劃線爲空
格)，這種命名方式在windows 系統裏是不被容許的，因此須要在burp 之類裏進行修改，然
後繞過驗證後，會被windows 系統自動去掉後面的點和空格。

d. IIS或者nginx文件解析漏洞。好比好比help.asp;.jpg 或http://www.xx.com/help.jpg/2.php。

e. 0×00截斷繞過。例如：help.asp .jpg(asp後面爲0×00)，在判斷時，大多函數取後綴名是從後往前取，故可以經過，可是在保存時，卻被保存爲help.asp。

f. 雙擴展名解析繞過攻擊（1）

若是上傳一個文件名爲help.php.123首先擴展名123 並無在擴展名blacklist 裏，而後擴展名123 也沒在Apache 可解析擴展名
list 裏，這個時候它會向前搜尋下一個可解析擴展名，或搜尋到.php，最後會以php 執行。

g. 雙擴展名解析繞過攻擊(2)

若是在Apache 的conf 裏有這樣一行配置

AddHandler php5-script .php

這時只要文件名裏包含.php,即便文件名是test2.php.jpg 也會以php 來執行。

h. 危險解析繞過攻擊- 基於web 服務的解析方式

若是在Apache 的conf 裏有這樣一行配置
AddType application/x-httpd-php .jpg
即便擴展名是jpg，同樣能以php 方式執行

a. 特別文件名構造（同黑名單攻擊 列c）

b.IIS或者ngnix文件解析漏洞（同黑名單攻擊 列d）

c. 0×00截斷繞過 （同黑名單攻擊 列e）

不管是黑名單仍是白名單，再直接點就是直接攻擊.htaccess 文件，在PHP manual 中提到了下面一段話
move_uploaded_file section, there is a warning which states ‘If the destination file already exists, it will be overwritten.’
若是PHP 安全沒配置好就能夠經過move_uploaded_file 函數把本身寫的.htaccess 文件覆蓋掉服務上的這樣就能任意定義解析名單了。

4 服務端驗證繞過（文件完整性檢測）

（1）文件頭檢測

（2）文件大小及相關信息檢測

經常使用的就是getimagesize()函數只須要把文件頭部分僞造好就ok 了，就是在幻數的基礎上還加了一些文件信息有點像下面的結構
GIF89a(…some binary data…)<?php phpinfo(); ?>(… skipping the rest of binary data …)

（3）文件加載檢測

該方法是比較變態的檢測方法，通常是調用API函數去進行文件加載測試，常見的是文件渲染測試，再變態是二次渲染。針對這種類型，通常是進行渲染測試繞過，或者攻擊加載器自己。

a. 渲染測試繞過

先用GIMP 對一張圖片進行代碼注入用winhex 看數據能夠分析出這類工具的原理是在不破壞文件自己的渲染狀況下找一個空白區進行填充代碼通常是圖片的註釋區對於渲染測試基本上都能繞過。

b. 但若是碰到變態的二次渲染基本上就無法繞過了，估計就只能對文件加載器進行攻擊了，好比上傳文件前，文件的數據以下。

而後上傳這個jpg 但把它從新下載回本地發現了奇怪的地方

上傳後圖片被二次渲染過新的JPG 圖片內容裏含有這個 CREATOR: gd-jpeg v1.0 (using IJG JPEG v62) 貌似是調用的GD php 的gd 庫。

通常進行過二次渲染再想繞過我的經驗是幾乎不可能了。若是要對文件加載器進行攻擊，常見的就是溢出攻擊，上傳本身的惡意文件後，服務上的文件加載器進行加載測試時，被觸發攻擊執行shellcode好比access/mdb 溢出你們能夠參考下 http://lcx.cc/?FoxNews=1542.html。

4 各類攻擊方式的相互關係及組合

首先客戶端端驗證和服務端驗證是相互獨立的，因此分開繞過就好了，主要難點是在服務端驗證的組合上。

文件完整性檢測已經包含文件頭檢測和圖像大小及相關信息檢測，但不包含文件擴展名檢測。它是以加載來做爲檢測的方式，好比用圖像渲染函數去渲染一張圖片。文件擴展名檢測和文件頭檢測都是同級的，相互獨立，因此若是是文件擴展名+文件頭檢測能夠同時分開繞過。

5 圖像代碼注入後的攻擊

代碼注入到圖片中，若是沒法正常解析，也沒法執行。

你們能夠參考下http://hi.baidu.com/hackercasper/blog/item/38aa658ee1ca00f6f11f3649.html
常見的是結合LocalFileInclude 漏洞來解析咱們的圖片
(RemoteFileInclude 和RemoteCodeExecution 在這裏就有點大才小用了哈)

好比某個站有這樣一個URL
www.website.com/view.php?page=contact.php
咱們替換contact.php 爲../
www.website.com/view.php?page=../
獲得一個報錯
Warning: include(../) [function.include]: failed to open stream: No such file or directory in
/home/sirgod/public_html/website.com/view.php on line 1337就說明存在LFI 漏洞，這個時候找到咱們的圖片文件路徑用一句話client 去鏈接www.website.com/view.php?page=../upload/help.jpg就能夠成功的獲得shell 了還有像nginx(php-fpm)解析漏洞，也能夠直接解析圖片裏的代碼因此你們要了解哪些環境下才能對圖片裏的代碼進行解析這樣才能結合上傳繞過最後獲得webshell