Web應用安全之八種安全的文件上傳方式
為了讓最終用戶將文件上傳到您的網站，就像是給危及您的服務器的惡意用戶打開了另一扇門。即便如此，在今天的現代互聯網的Web應用程序，它是一種常見的要求，因為它有助于提高您的業務效率。在Facebook和Twitter等社交網絡的Web應用程序，允許文件上傳。也讓他們在博客，論壇，電子銀行網站，YouTube和企業支持門戶，給機會給最終用戶與企業員工有效地共享文件。允許用戶上傳圖片，視頻，頭像和許多其他類型的文件。
向最終用戶提供的功能越多，Web應用受到攻擊的風險和機會就越大，這種功能會被惡意用戶利用，獲得到一個特定網站的權限，或危及服務器的可能性是非常高的。
當在測試幾個Web應用程序時，我們注意到，相當多的知名Web應用程序，不具備安全的文件上傳形式。這些漏洞很容易被利用，我們可以訪問這些Web應用程序的服務器托管到文件系統。在這篇文章中，我們為您介紹8種常見的方式，我們遇到過的安全文件上傳表單。同時，還將展示一個惡意的用戶，可以輕松地繞過這些安全措施。
案例1：沒有任何驗證的簡單文件上傳表單
一個簡單的文件上傳表單通常包含一個HTML表單和PHP腳本。HTML表單的形式呈現給用戶，而需要文件上傳功能的PHP腳本中包含的代碼。這種形式和PHP腳本下面是一個例子：
HTML Form:
- view source
- <form enctype="multipart/form-data" action="uploader.php" method="POST">
- <input type="hidden" name="MAX_FILE_SIZE" value="100000" />
- Choose a file to upload: <input name="uploadedfile" type="file" /><br />
- <input type="submit" value="Upload File" />
- </form>
PHP Code:
- <?php
- $target_path = "uploads/";
- $target_path = $target_path . basename($_FILES['uploadedfile']['name']);
- if (move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target_path)) {
- echo "The file " . basename($_FILES['uploadedfile']['name']) . " has been uploaded";
- echo "There was an error uploading the file, please try again!";
- } else {
- }
- ?>
當PHP接收POST請求且編碼類型是multipart/form-data，它會創建一個臨時文件名隨機的臨時目錄中(例如/ var/tmp/php6yXOVs)。 PHP也將填充全局數組$_FILES上傳的文件的信息:
- $ _FILES ['UploadedFile的'] ['名稱']：在客戶機上的文件的原始名稱
- $ _FILES ['UploadedFile的'] ['類型']：文件的MIME類型
- $ _FILES ['UploadedFile的'] ['大小']：文件的大小（以字節為單位）
- $_FILES ['UploadedFile的']['不對tmp_name']：上傳的文件存儲在服務器上的臨時文件名。
PHP 函數move_uploaded_file將用戶提供的臨時文件移動到一個位置。在這種情況下，目的地是服務器根目錄以下。因此，文件可以使 用的URL，如：http://www.domain.tld/uploads/uploadedfile.ext訪問。在這個簡單的例子中，有允許上傳 的文件類型沒有限制，因此攻擊者可以上傳一個PHP或NET帶有惡意代碼的文件，可導致服務器妥協。
這可能看起來像很幼稚的例子，但我們在一些Web應用中沒有遇到這樣的代碼。#p#
案例2：Mime類型驗證
另 一個常見的錯誤Web開發人員確保文件上傳表單時，只檢查從PHP返回mime類型。當一個文件被上傳到服務器，PHP將設置變 量$_FILES['UploadedFile']['type']所提供的Web瀏覽器客戶端使用的MIME類型。然而，文件上傳表單驗證不能依賴于這 個值。惡意用戶可以輕松地使用腳本或其他一些自動化的應用程序，允許發送HTTP POST請求，這讓他送一個假的mime類型的文件上傳。
案例3：限制危險的拓展
在另一個例子里，我們遇到了文件上傳使用黑名單的做法，作為一項安全措施。從開發者收集制定的危險列表，如果正在上傳的文件包含在列表中，訪問會被拒絕。
使用危險的文件擴展名，其主要缺點之一是，它幾乎不可能編制一份完整的清單，包括攻擊者可以使用的所有可能的擴展名。例如如果代碼運行在托管環境中，通常這樣的環境讓大量的腳本語言，如Perl，Python和Ruby等，列表可以是無窮無盡的。
惡意用戶可以很容易地繞過該檢查上傳一個文件名為“.htaccess”，其中包含類似于下面的一行代碼：
AddType application/x-httpd-php .jpg
上 面的代碼行，指示ApacheWeb服務器執行jpg圖片，好像他們是PHP腳本。攻擊者現在可以上傳一個jpg擴展名的文件，其中包含PHP代碼。正如 下面的截圖，通過web瀏覽器請求一個jpg文件，其中包含PHP的命令phpinfo()函數，它仍然是從Web服務器執行：
#p#
案例4: 雙擴展名 (第1部分)
本案例中使用的安全策略和案例3中所使用的非常相近. 盡管方式換成了簡單的檢查文件名具有的擴展名, 開發者通過在文件名中查找 ‘.’ 字符并提取點號之后的字符串來得到文件擴展名.
繞過該途徑的方法有點兒復雜, 但是仍然是現實的. 首先, 讓我們看看 Apache 是怎么處理具有多重擴展名的文件的. Apache 手冊中有如下一段陳述:
“文 件可以有多個擴展名, 這些擴展名的順序一般情況下是無關緊要的.例如: 如果文件 welcome.html.fr 被映射為內容類型是 text/html ,語言是法語的話, 文件welcome.fr.html 將被映射為完全相同的內容. 如果一個以上的擴展名映射到同種類型的元信息上, 那么將使用最右邊的那個, 除了語言和內容編碼. 比如: .gif 的MIME類型是 image/gif , .html 的 MIME 類型是 text/html , 那么 welcome.gif.html 的MIME類型將是text/html .”
因此一個名為 ‘filename.php.123’ 的文件將會被解釋為一個PHP文件并被執行.這僅限于最后的那個擴展名(本例中是 .123)沒有在web服務器的 mime-types列表中被指定.web開發者通常不會意識到Apache還存在這么一個 ‘特性’, 出于某些原因來說這可能非常危險.知道了這個以后,一個攻擊者可以上傳一個名為 shell.php.123 的文件并繞過文件上傳保護機制.后臺腳本將會計算出最后的擴展名(.123)并作出該擴展名并不在危險的擴展名列表內的結論.話雖如此,想要預防某惡意用 戶可能會使用的所有隨機擴展名來上傳一個文件到你的web服務器上是不可能的.
案例5: 雙擴展名 (第2部分)
一個更好的增強文件上傳表單的安全性的途徑就是白名單機制. 在本例中, 開發者定義了一個 已知/可接受 的擴展名列表并且不允許使用未在名單中指定的擴展名.
然 而, 在某些情況下該途徑不會像期待的方式那樣工作. 當 Apache 被配置為執行 PHP 代碼的時候, 存在兩種方式來實現該機制: 使用 AddHandler 指令, 或者使用 AddType 指令. 如果 AddHandler 指令被使用, 所有包含 ‘.php’ 擴展名的文件名(例如: ‘.php’ , ‘.php.jpg’)均被作為 PHP 腳本來執行. 因此, 如果你的 Apache 配置文件包含如下一行的話, 你可能很容易受到攻擊:
AddHandler php5-script .php
一個攻擊者可以上傳名為 ‘filename.php.jpg’ 的文件并繞過保護機制, 然后執行其中的代碼.
案例 6: 檢查圖片頭部
當 僅允許上傳圖片的時候, 開發者通常使用 PHP 的 getimagesize 函數來檢測圖片的頭部信息. 該函數在被調用時將會返回圖片的尺寸, 如果圖片經驗證為無效的, 也就是說圖片頭部信息不正確, 則會返回 false 值. 因此一個開發者一般會檢查該函數是否返回 true 或 false, 并且通過該信息來驗證上傳的文件. 所以, 如果一個惡意用戶試著上傳一個內嵌有簡單 PHP shell 的 jpg 文件的話, 該函數會返回 false 然后他將不允許上傳此文件. 然而, 即使這種方式也能被很容易的繞過. 如果一個圖片在一個圖片編輯器內打開, 就如 Gimp, 用戶就可以編輯圖片的注釋區, 那兒就能插入 PHP 代碼, 就如下圖所示.
該圖片仍然有一個有效的頭部; 因此就繞過了 getimagesize 函數的檢查. 從下面截圖中可以看到, 當一個普通的 web 瀏覽器請求該圖的時候, 插入到圖片注釋區的 PHP 代碼仍然被執行了:
#p#
案例7：通過.htaccess保護上傳文件夾
另一種流行的穿件安全的文件上傳表單的方法是適用.htaccess保護好上傳文件存放的文件夾。辦法是限制這個文件夾里的腳本文件的執行。這種情形一下，一個.htaccess文件一般包含下面的代碼：
AddHandler cgi-script .php .php3 .php4 .phtml .pl .py .jsp .asp .htm .shtml .sh .cgi
Options –ExecCGI
上面的是另一種形式的黑名單，本身并不是很安全。在PHP手冊中，move_uploaded_file一章中，有一個warning:若目標文件已經存在，則會覆蓋原文件。
因為上傳的文件能夠而且會覆蓋已經存在的同名文件，一個惡意用戶很輕易就能用他自己修改過的.htaccess替換掉原來的。這使得他可以執行特定的將會幫助他危害服務器的腳本。
案例8：客戶端驗證
另一種在文件上傳表單中常用的安全技術是在客戶端驗證上傳的文件。一般而言，該技術在ASP.NET應用中更通用一些，因為ASP.NET提供了易用的驗證控件。
這些驗證控件允許開發者對要上傳的文件做正則檢查，以查出待上傳的文件擴展名是否在允許列表中。下面是一段來自微軟網站的示例代碼:
- <asp:FileUpload ID="FileUpload1" runat="server" />
- <asp:Button ID="Button1" runat="server" OnClick="Button1_Click" Text="Upload File" />
- <asp:Label ID="Label1" runat="server"></asp:Label>
- <asp:RegularExpressionValidator id="RegularExpressionValidator1" runat="server"
- ErrorMessage="Only mp3, m3u or mpeg files are allowed!"
- ValidationExpression="^(([a-zA-Z]:)|({2}w+)$?)((w[w].*))
- +(.mp3|.MP3|.mpeg|.MPEG|.m3u|.M3U)$" ControlToValidate="FileUpload1"></asp:RegularExpressionValidator>
- <asp:RequiredFieldValidator id="RequiredFieldValidator1" runat="server"
- ErrorMessage="This is a required field!"
- ControlToValidate="FileUpload1"></asp:RequiredFieldValidator>
-
這段ASP.NET代碼使用了驗證控件，所以最終用戶只被允許上傳.mp3,.mpeg,或者.m3u文件到服務器。若文件類型和這三個指定的文件類型不一致，驗證控件將跑出異常，文件也就不會被上傳。
由于這種文件驗證是在客戶端完成的，惡意用戶很容易就能繞過這一檢查。寫一段客戶端腳本來替換web應用的驗證腳本做驗證并非不可能。不用web瀏覽器，入侵者可以使用可以發送HTTP POST請求的程序來實現上傳文件。#p#
推薦的解決方案
在允許上傳文件的網站和web應用中，應當應用下面的一系列最佳實踐方法。這些實踐方法將有助于你保證web應用的上傳文件的安全性。
定義一個.htaccess文件，只允許訪問指定擴展名的文件。
不要把.htaccess文件和上傳文件放在同一個目錄里，應該放在父目錄里。
一個典型的只允許 gif, jpg, jpeg 和 png文件的.htaccess文件應當包含下面的代碼(根據你的需求做調整)。這樣也能阻止雙擴展名攻擊.
- deny from all
- <Files ~ "^w+.(gif|jpe?g|png)$">
- order deny,allow
- allow from all
- </Files>
如果可能，把文件上傳到root目錄以外的目錄里。
禁止覆蓋已存在的文件(以阻止.htaccess覆蓋攻擊)
創建一個mime-type白名單列表。(只允許這個列表里的Mime-type)
生成一個隨機的文件名，并且加上此前生成的文件擴展名、
不要只依賴客戶端驗證，這不夠。理想的是既有客戶端驗證也有服務器端驗證。
總結
如上所述，惡意用戶有很多手段繞過文件上傳表單安全驗證。因此，在web應用中實現文件上傳表單時，應當尊徐正確的安全指導，并且做恰當的測試。不幸的是要做足夠的測試將會需要很多時間和更多的安全專家。
還好有了Acunetix WVS，不需要安全專家就可以自動完成上傳表單脆弱性檢查，Acunetix WVS用最少的時間為開發者提供了足夠多的能夠追蹤并修復問題的信息。
