一. 什么是文件上傳漏洞
Web應用程序通常會有文件上傳的功能, 例如在 BBS發布圖片 , 在個人網站發布ZIP 壓縮 包, 在辦公平台發布DOC文件等 , 只要 Web應用程序允許上傳文件, 就有可能存在文件上傳漏 洞.
什么樣的網站會有文件上傳漏洞?
大部分文件上傳漏洞的產生是因為Web應用程序沒有對上傳文件的格式進行嚴格過濾 , 還有一部分是攻擊者通過 Web服務器的解析漏洞來突破Web應用程序的防護, 后面我們會講 到一些常見的解析漏洞, 最后還有一些不常見的其他漏洞, 如 IIS PUT 漏洞等 .
二. 文件上傳漏洞的危害
上傳漏洞與SQL注入或 XSS相比 , 其風險更大 , 如果 Web應用程序存在上傳漏洞 , 攻擊者甚至 可以直接上傳一個webshell到服務器上 .
三. 常見的解析漏洞
1.IIS 解析漏洞
IIS6.0 在解析文件時存在以下兩個解析漏洞 .
①當建立 *.asa 、*.asp 格式的文件夾時 , 其目錄下的任意文件豆漿被 IIS 當作 asp 文件 來解析 .
② 在 IIS6.0 下 , 分 號 后面 的 擴 展 名 不 會 被 解 析 , 也 就 是 說 當 文 件 為 *.asp;.jpg
時,IIS6.0 同樣會以 ASP腳本來執行 .
2.Apache 解析漏洞
在 Apache 1.x 和 Apache 2.x 中存在解析漏洞 , 但他們與 IIS 解析漏洞不同 .
Apache 在解析文件時有一個規則 : 當碰到不認識的擴展名時 , 將會從后向前解析 , 直到 碰到認識的擴展名位置 , 如果都不認識 , 則會暴露其源碼 . 比如 :
1.php.rar.xx.aa
Apache 首先會解析 aa 擴展名 , 如果不認識則接着解析 xx 擴展名 , 這樣一直遍歷到認識 的擴展名為止 , 然后再將其進行解析 .
3.PHP CGI 解析漏洞
在 PHP的配置文件中有一個關鍵的選項 : cgi.fi: x_pathinfo. 這個選項在某些版本是
默認開啟的 , 在開啟時訪問 url, 比如 :http://www.xxx.com/x.txt/x.php,x.php 是不存在的 文件 , 所以 php 將會向前遞歸解析 , 於是就造成了解析漏洞 . 由於這種漏洞常見於 IIS7.0 、 IIS7.5 、 Nginx 等 Web服務器 , 所以經常會被誤認為是這些 Web服務器的解析漏洞 .
4.Nginx <8.03 空字節代碼執行漏洞
影響版本 :0.5,0.6,0.7<=0.7.65 0.8<=0.8.37
Nginx 在圖片中嵌入 PHP代碼 , 然后通過訪問 xxx.jpg%00.php 可以執行其中的代碼 .
5. 其他
在 windows 環境下， xx.jpg[ 空格 ] 或 xx.jpg. 這兩類文件都是不允許存在的 , 若這樣命 名,windows 會默認除去空格或點 , 攻擊者可以通過抓包 , 在文件名后加一個空格或者點繞過 黑名單 . 若上傳成功 , 空格和點都會被 windows 自動消除 , 這樣也可以 getshell.
如果在 Apache 中 .htaccess 可被執行 . 且可被上傳 . 那可以嘗試在 .htaccess 中寫入 :
SetHandlerapplication/x-httpd-php
然后再上傳名稱為 shell.jpg 的 webshell, 這樣 shell.jpg 就可解析為 php 文件 .
四. 文件上傳漏洞的防御方法
很多開發者僅僅通過使用 javascript 來防御非法文件上傳 , 這樣驗證對於一些普通用戶防 止上傳錯誤還可以 , 對專業的技術人員來說 , 這是非常低級的驗證 . 攻擊者可以通過非常多的 方法來突破前端驗證 , 下面舉兩個例子 :
1. 使用 FireBug
FireBug 是一款開源的瀏覽器插件 , 它支持 Firefox,Chrome 等瀏覽器 . 它可以讓 Web開 發者輕松地調試 HTML、javascirpt 、 AJAX、 CSS等前端腳本代碼 . 正是因為 FireBug 功能強 大, 所以也成為了黑客的必備利器 .
如何使用 FireBug 繞過客戶端檢測 .
當單擊提交按鈕后 ,Form 表單將會觸發 onsubmit 事件 ,onsubmit 事件將會調用 checkFile 函數 .checkFile 函數將會檢測文件擴展名是否合法 , 並返回一個布爾值 , 如果 checkFile 函數返回 true, 則表單提交 , 反之則攔截要上傳的文件 . 知道這一點后 , 可以用 FireBug 將 onsubmit 事件刪除 , 這樣就可以繞過 javascript 函數驗證 .
2. 中間人攻擊
中間人攻擊和使用 FireBug 的方法完全不同 ,FireBug 是刪除客戶端的 javascript 驗證 , 而使用 Burp Suite 等抓包軟件則是按照正常的流程通過 javascript 驗證 , 然后在傳輸中的 HTTP層做修改 .
首先把木馬文件的擴展名字改為一張正常圖片或文檔的擴展名 , 如 jpg 擴展名 , 在上傳 時使用 Burp 攔截上傳數據 , 再將其中的擴展名 jpg 修改成 jsp, 就可以繞過客戶端驗證 .
通過以上例子 , 大家可以看出前端腳本驗證是一種非常不可靠的驗證方式 , 不管是對文 件上傳 、XSS還是別的漏洞來說都是如此 , 當然這並不是說完全不需要做前端驗證 , 而是要把 前端驗證和服務器端驗證相結合 .
我們來看服務端檢測 , 在上傳文件時 , 大多開發者會對文件擴展名檢測 , 驗證文件擴展名 通常有兩種方式 : 黑名單和白名單 .
黑名單過濾是一種不安全的方式 , 黑名單定義了一系列不安全的擴展名 , 服務器端在接 收文件后 , 與黑名單擴展名對比 , 如果發現文件擴展名與黑名單里的擴展名匹配 , 則認為文件 不合法 .
為什么黑名單過濾是一種不安全的方式呢 ?
比如一個 Web服務器為 IIS6.0,Web 語言為 asp 的網站 , 假定開發者使用了黑名單過濾 ,
過濾了 asp、 asa、 cer 等文件格式 , 那么可以嘗試以下幾種方式來繞過 : 1. 大小寫 , 比如 AsP、 cER等.
2. 被忽略的擴展名 ,IIS6.0 會把 cdx 格式的文件當成 asp 來解析 .
3. 配合解析漏洞 , 上傳 asp;.jpg 格式文件 .
4. 如果 Web服務器開啟了其他語言的支持 , 比如可以解析 php 文件 , 那么可以上傳 php
格式的木馬 .
5. 利用 Windows 系統自動去除 . 和空格的特性 , 如上傳擴展名 asp. 格式的文件來繞過 .
通過以上幾個例子可以看出 , 黑名單過濾的可靠性並不高 , 白名單過濾相對來說較為可靠.
白名單與黑名單的機智恰恰相反 , 黑名單是定義不允許上傳的擴展名 , 白名單則是定義允許 上傳的擴展名 , 雖然采用白名單可以防御未知風險 , 但是不能完全依賴白名單 , 因為白名單不 能完全防御上傳漏洞 , 例如各種解析漏洞等 , 白名單僅僅是防御上傳漏洞的第一步 . 通常會結 合其他驗證方式來使用 , 雖然不能完全防御文件上傳漏洞 , 但也基本上規避了絕大部分風險.。
其他幾種文件上傳漏洞防御方法 :
1. 檢查文件上傳路徑 ( 避免 0x00 截斷、 IIS6.0 文件夾解析漏洞、目錄遍歷 )
2. 文件擴展名檢測 ( 避免服務器以非圖片的文件格式解析文件 )
3. 文件 MIME驗證 ( 比如 GIF 圖片 MIME為 image/gif,CSS 文件的 MIME為 text/css 等 ) 3. 文件內容檢測 ( 避免圖片中插入 webshell)
4. 圖片二次渲染 ( 最變態的上傳漏洞防御方式 , 基本上完全避免了文件上傳漏洞 )
5. 文件重命名 ( 如隨機字符串或時間戳等方式 , 防止攻擊者得到 webshell 的路徑 )
另外值得注意的一點是, 攻擊者上傳了webshell之后需要得到webshell 的路徑才能通過工 具連接 webshell, 所以盡量不要在任何地方 ( 如下載鏈接等 ) 暴露文件上傳后的地址, 在這里 必須要提一點 , 就是有很多網站的上傳點在上傳了文件之后不會在網頁上或下載鏈接中暴露 文件的相對路徑, 但是在服務器返回的數據包里卻帶有文件上傳后的路徑 .