web安全之文件上傳漏洞總結

一 前言:

       在針對web的攻擊中,攻擊者想要取得webshell,最直接的方式就是將web木馬插入服務器端進行成功解析,那麼如何歷劫成功解析?假設服務器爲php語言結構,那麼針對上傳點就是利用PHP木馬,而且要求木馬的後綴爲.php進行保存。所以,上傳木馬的過程當中就是在web系統中新增一個頁面,若是能成功上傳,咱們就能夠用菜刀工具進行鏈接,成功拿下webshell。erphp

二 文件上傳的業務流程 :

     上傳功能看似簡單,用戶選擇需上傳的文件,點擊上傳便可。可是事實上,服務器須要進行多個步驟,方可完成整個上傳流程。linux

  上傳攻擊思路如圖(畫的太醜請見整體來講,上傳功能的期間涉及的功能點較多,整個過程可分爲三大步驟:nginx

(1)客戶端上傳功能:web

  用戶提交上傳表單,利用HTML格式,實現上傳格式的編制,在封裝到HTTP包中,開始傳輸。shell

(2)中間件上傳功能:apache

  中間件主要有三個流程:windows

    1.接收用戶提交的表單安全

    2.將表單內容存儲爲臨時文件服務器

    3.根據安全規範,將臨時文件保存爲正式文件app

(3)服務器存儲及調研

  服務器會存儲正式文件,並將其存放在中間件規定的真實路徑中。

  上面給出了完整的上傳業務流程,那麼接下來咱們再看看上傳功能的具體實現方式,經過具體的流程來分析其中的安全隱患

三 上傳攻擊的條件:

  1.目標網站具備上傳功能

  上傳攻擊的前提是:目標網站具備上傳功能,能夠上傳文件,而且上傳文件,而且文件上傳到服務器能被存儲。

  2.上傳的目標文件可以被Web服務器解析執行

  因爲上傳文件須要依靠中間件解析執行,所以上傳文件後綴應爲可執行格式。在APache+PHP環境下,要求上傳的web木馬採用.php後綴名(或者能有以PHP方式解析的後綴名),而且存放上傳文件的目錄要有執行腳本的權限。以上兩種缺一不可。

  3.知道文件上傳到服務器後的存放路徑和文件名稱

    許多web應用都會修改上傳文件的文件名稱,這時就須要結合其餘漏洞獲取這些信息。

    若是不知道上傳的存放路徑和文件名稱,即便上傳成功也沒法訪問。所以,若是上傳成功但不知道真實路徑,那麼攻擊沒有任何意義。

  4.目標文件可被用戶訪問

    若是文件上傳後,卻不能經過Web訪問,或者真實路徑沒法獲取,木馬這沒法攻擊者打開,那麼就不能成功實施攻擊。

四 上傳檢測繞過技術

  在上傳過程當中,既要保證上傳功能的正常開展,又要對攻擊者的木馬狀況進行過濾。

1.客戶端校驗繞過:

      (1)直接修改js代碼或者使用抓包的方法修改請求內容繞過,能夠先上傳一個gif木馬,經過抓包修改成 jsp/php/asp,只用這種方法來檢測是確定能夠繞過的。

     (2)更簡單的方法是直接關掉JS

2.服務端繞過MIME 檢測

    校驗請求頭content-type字段繞過:

經過抓包來修改Http頭的content-type便可繞過,也確定是能夠繞過這種檢測

 

  1.   POST /upload.php HTTP/1.1

  2.   TE: deflate,gzip;q=0.3

  3.   Connection: TE, close

  4.   Host: localhost

  5.   User-Agent: libwww-perl/5.803

  6.   Content-Type: multipart/form-data; boundary=xYzZY

  7.   Content-Length:155

  8.   --xYzZY

  9.   Content-Disposition: form-data; name="userfile"; filename="shell.php"

  10.                       Content-Type: image/gif (原爲Content-Type: text/plain)

  11.                       <?php system($_GET['command']);?>

  12.                       --xYzZY-

    文件幻數(文件頭)檢測繞過:

  在木馬內容的前面插入對應的文件頭內容,例如:GIF89a ,更保險的方法是在可上傳的文件中插入木馬代碼,而後修改後綴

 文件加載檢測:

  經過例如加載文件進行圖像渲染的方式來測試,這個時候就通常須要在正常的文件中插入木馬代碼了,例如圖像,那麼插入的代碼通常會放在圖像的註釋區,所以不會影響圖像正常渲染繞過這種檢測,此時可使用工具(稱爲插馬器)來進行插入,例如edjpgcom,或者直接用copy命令來合成也能夠。固然這種檢測不必定可以徹底繞過

   後綴名檢測

   後綴黑名單檢測:找查blacklist(黑名單列表)的漏網之魚,例如

  o  大小寫:若是檢測的時候不忽略大小寫,那麼能夠改變後綴名的大小寫繞過

  o  擴展名:列表中若是忽略了某些後綴

  3.       能被解析的文件擴展名列表:

  4.       jsp jspx jspf

  5.      asp asa cer aspx

  6.      php php php3 php4 pht

  7.      exe exee

   後綴白名單檢測:白名單檢測仍是會比黑名單強一點,常見的繞過方法有%00截斷,還有服務器的解析漏洞

    %00截斷漏洞:若是存在這類漏洞,那麼後綴名的檢測均可以繞過,此時咱們能夠以下命名一個上傳文件

   test.php%00.jpg

 解析漏洞:這類漏洞是自己服務器的中間件產生的,例如apache,nginx都被爆出過存在解析漏洞,存在解析漏洞的話,上傳的安全性幾乎就徹底失去了,下面再詳細分析。

和其餘漏洞結合的上傳

服務器解析漏洞

IS5.x-6.x解析漏洞

  使用iis5.x-6.x版本的服務器,大多爲windows server 2003,網站比較古老,開發語句通常爲asp;該解析漏洞也只能解析asp文件,而不能解析aspx文件。

目錄解析(6.0)

  形式:www.xxx.com/xx.asp/xx.jpg 原理: 服務器默認會把.asp,.asp目錄下的文件都解析成asp文件。

  文件解析

  形式:www.xxx.com/xx.asp;.jpg 原理:服務器默認不解析;號後面的內容,所以xx.asp;.jpg便被解析成asp文件了。 解析文件類型

  IIS6.0 默認的可執行文件除了asp還包含這三種 :

  1. /test.asa

  2./test.cer

  3./test.cdx

apache解析漏洞

  漏洞原理

  Apache 解析文件的規則是從右到左開始判斷解析,若是後綴名爲不可識別文件解析,就再往左判斷。好比 test.php.qwe.asd 「.qwe」和」.asd」 這兩種後綴是apache不可識別解析,apache就會把wooyun.php.qwe.asd解析成php。

漏洞形式

  www.xxxx.xxx.com/test.php.php123

  其他配置問題致使漏洞

  1.   若是在 Apache 的 conf裏有這樣一行配置 AddHandler php5-script .php 這時只要文件名裏包含.php 即便文件名是 test2.php.jpg 也會以 php 來執行。

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

修復方案

  1.   apache配置文件,禁止.php.這樣的文件執行,配置文件裏面加入

  2.   用僞靜態能解決這個問題,重寫相似.php.*這類文件,打開apache的httpd.conf找到LoadModulerewritemodule modules/modrewrite.so 把#號去掉,重啓apache,在網站根目錄下創建.htaccess文件

  1. <IfModulemod_rewrite.c>

  2. RewriteEngineOn

  3. RewriteRule.(php.|php3.) /index.php

  4. RewriteRule.(pHp.|pHp3.) /index.php

  5. RewriteRule.(phP.|phP3.) /index.php

  6. RewriteRule.(Php.|Php3.) /index.php

  7. RewriteRule.(PHp.|PHp3.) /index.php

  8. RewriteRule.(PhP.|PhP3.) /index.php

  9. RewriteRule.(pHP.|pHP3.) /index.php

  10.        RewriteRule .(PHP.|PHP3.) /index.php

  11.        </IfModule>

nginx解析漏洞

  漏洞原理

  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,可是PHP爲何會接受這樣的參數,並將phpinfo.jpg做爲PHP文件解析呢?這就要說到fix_pathinfo這個選項了。若是開啓了這個選項,那麼就會觸發在PHP中的以下邏輯:

PHP會認爲SCRIPTFILENAME是phpinfo.jpg,而1.php是PATHINFO,因此就會將phpinfo.jpg做爲PHP文件來解析了

  漏洞形式

  www.xxxx.com/UploadFiles/image/1.jpg/1.php

  www.xxxx.com/UploadFiles/image/1.jpg %00.php

  www.xxxx.com/UploadFiles/image/1.jpg/%20\0.php

  另一種手法:上傳一個名字爲test.jpg,而後訪問test.jpg/.php,在這個目錄下就會生成一句話木馬shell.php。

IIS7.5解析漏洞

  IIS7.5的漏洞與nginx的相似,都是因爲php配置文件中,開啓了 cgi.fix_pathinfo,而這並非nginx或者iis7.5自己的漏洞。

操做系統相關

  1.   上傳不符合windows文件命名規則的文件名

  1. test.asp.

  2. test.asp(空格)

  3. test.php:1.jpg

  4. test.php::$DATA

  5. shell.php::$DATA…….

  會被某些版本的windows系統自動去掉不符合規則符號後面的內容。

  1.  linux下後綴名大小寫

  linux是大小寫敏感的,所以通常檢測也會區分大小寫,但某些解析器是不區分大小寫的,例如PHP,上傳php不被解析,能夠試試上傳pHp後綴的文件名。

  2.  CMS、編輯器漏洞

   CMS漏洞: 能夠針對不一樣CMS存在的上傳漏洞進行繞過。

   編輯器漏洞:好比FCK,ewebeditor等,能夠針對編輯器的漏洞進行繞過。

常見WAF繞過姿式

  1.  大小上限:WAF對校驗的用戶數據設置大小上限,此時能夠構造一個大文件的木馬,前面都是填充的垃圾內容

  2.  filename:針對早期版本的安全狗,能夠多加一個filename來繞過,

 

  或者能夠經過吧filename放在很是規的位置來繞過(這裏的filename指在http請求頭中上傳的文件名字)

 

  3.  post/get:若是WAF規則是:只檢測特定請求類型的數據包,但服務端接收的時候卻用了request來,此時經過修改請求頭的請求方法就能夠繞過

  4.  利用waf自己的缺陷,對於不一樣的waf產品能夠搜索其對應的漏洞缺陷,進行繞過

  5.  利用NTFS ADS特性:ADS是NTFS磁盤格式的一個特性,用於NTFS交換數據流。在上傳文件時,若是waf對請求正文的filename匹配不當的話可能會致使繞過

  6.  文件重命名繞過:若是web程序會將filename除了擴展名的那段重命名的話,那麼還能夠構造更多的點、符號等等。

和其餘規則結合

  1.  截斷:例如 %00, 0x00等

  test.php(0x00).jpg

  test.php%00.jpg

  路徑/upload/1.php(0x00),文件名1.jpg,結合/upload/1.php(0x00)/1.jpg

僞代碼演示:

  1. name= getname(httprequest) //假如這時候獲取到的文件名是help.asp.jpg(asp 後面爲 0x00)

  2. type =gettype(name)        //而在 gettype()函數裏處理方式是從後往前掃描擴展名,因此判斷爲 jpg

  3. if(type == jpg)

  4.    SaveFileToPath(UploadPath.name, name)   //但在這裏倒是以 0x00 做爲文件名截斷

  5. //最後以 help.asp 存入路徑裏

  1.   可上傳.htaccesss,上傳當前目錄的.htaccess 文件而後修改成如下內容:

  1. AddTypeapplication/x-http-php .jpg   #(上傳的jpg 均以php執行)

  把.htaccess 上傳後,且上傳成功後,再上傳內容爲一句話的jpg文件

文件校驗的建議

  § 文件擴展名服務端白名單校驗。

  § 文件內容服務端校驗。

  § 上傳文件重命名。

  § 隱藏上傳文件路徑。

以上幾點,能夠防護絕大多數上傳漏洞,可是須要跟服務器容器結合起來。若是解析漏洞依然存在,那麼沒有絕對的安全。

 

參考書籍《Web安全防禦指南》

相關文章
相關標籤/搜索