設計安全的檔案上傳功能

       

         源文章連結地址：http://www.2cto.com/Article/200808/28797.html

      

簡易程式員收藏本文

作者：刺

這兩天我們的老朋友PDP在BlackHat 08上做了一個關於GIFAR的演講。和往常一樣，PDP的東西基本上都很猥瑣，這個也是。主題是關於是如何把GIF或者 JPG檔案和JAR檔案捆綁在一起，然後欺騙伺服器以為是GIF或JPG檔案，結果卻是在用戶端的JVM中執行JAR的例子。

他還舉了些欺騙的例子，比如在office2007中，doc檔案實際上就是zip格式了，裡面都是些xml，那麼他把jar檔案打包在zip檔案裡，再把尾碼改成doc，來達到欺騙的目的。

在這裡是用戶端的問題，我想到的則是其他的問題，比如安全上傳。

根據以往的經驗看來，我們可能會設計如下檔案上傳的安全規則：
1. 檔案上傳的目錄設定為不可執行
2. 判斷檔案類型
3. 單獨設定檔案伺服器的網域名稱
4. 改寫檔案名稱，檔案路徑不可預測

第一點規則是顯而易見的，是為了減小執行動態語言指令碼的風險。如果被成功上傳了一個webshell，但是不能執行，還是能夠起到深度防禦的作用。

第二點，在判斷檔案類型的時候，我們一般要求使用白名單，而不是黑名單，因為黑名單可能會列不全，還可能會造成一些bypass的風險。

比如以前老版本的 FCKEditor就出過這種問題，只做了黑名單的控制，最後被bypass。

而apache有個特性，是解析第一個“ . ”後的檔案尾碼作為檔案類型，比如 fvck.php.rar.rar.rar 會被apache當作 fvck.php解析。 我最近看了下php的手冊，在安裝文檔裡，針對這個問題，專門有一個指導：

15. Tell Apache to parse certain extensions as PHP.  For example, lets have
    Apache parse .php files as PHP.  Instead of only using the Apache AddType
    directive, we want to avoid potentially dangerous uploads and created
    files such as exploit.php.jpg from being executed as PHP.  Using this
    example, you could have any extension(s) parse as PHP by simply adding
    them.  Well add .phtml to demonstrate.

      <FilesMatch .php$>
          SetHandler application/x-httpd-php
      </FilesMatch>
IIS6也有這種類似的特性，即在檔案夾名字為 fvck.asp 時(fvck可替換為任意值)，該檔案夾下任何檔案都會被當作asp來執行，
至今似乎也未見到微軟有把這個特性當作bug來fix的跡象。
所以如果不熟悉這些webserver的特性，你可能會覺得漏洞來的如此神奇：我明明做了充分限制，為什麼還是被“做伏地挺身”了？
在判斷檔案類型的時候，大多數程式都是使用的採用檢查檔案尾碼的方法，這裡主要需要注意的hacking trick是某些檢查函數是否會以0位元組作為結束的判斷，以前動網就出過類似的漏洞，上傳 fvck.jpg%00.asp即可繞過檔案類型檢查。

我也見過只檢查檔案頭部的，這種也很好欺騙，構造一個合法的gif檔案頭部，然後將webshell貼在後面，在尾碼合法的情況下，一樣能夠被瀏覽器解析：

GIF89a ?
<? phpinfo(); ?>

比較進階一點的是做更多的檔案格式檢查，比如檢查圖片裡像素的長寬等，然後再對圖片做一次壓縮，這樣出來的圖片基本都變形了，有啥webshell也被破壞了。

而檢查檔案格式時候一般會用到一些網上已經封裝好的類，在掃描檔案格式方面還是比較有優勢的。但是在檢查大檔案的時候效率顯然是一個需要考慮的問題，很多程式員出於效率原因可能不太會願意選擇這種方式。

但是今天從PDP的這個繫結檔案的猥瑣方法看來，詳細檢查檔案格式的方法還是非常有必要的，因為攻擊者的目標可能不光是伺服器，還是用戶端，如果要對用戶端有所保證，就必須要詳細檢查檔案格式，使之落在白名單中。

第三點，單獨設定檔案伺服器網域名稱，也是一種針對用戶端的保護。這樣可能會避免許多跨域的問題。如果發生了XSS，攻擊者可能還需要突破跨域的限制才能進一步擴大戰果。再比如如果被上傳了crossdomain.xml，可能就會導致flash的跨域問題，這些都是實實在在的風險。

第四點，改寫檔案名稱，隨機檔案路徑。這是把風險藏起來，現在基本上盡職一點的程式員都會這麼設計，這也是最大程度減小風險的非常切實有效手段。

需要注意的是構造隨機檔案名稱或路徑的演算法需要足夠“隨機”，而不要從比如cookie之類的地方直接取一段hash出來。比較好的做法是在server上用類似random()一類的函數來產生，相信程式員們這點意識還是有的，不再贅述了。