Upload-Labs Pass-01 ~ Pass-05 通关记录前端校验、MIME、特殊后缀、.htaccess、大小写绕过0x00 前言上一篇文章记录了 Upload-Labs 靶场在 Windows 11 Docker Desktop 环境下的本地部署过程。本篇开始记录 Upload-Labs 前五关的通关过程主要涉及文件上传漏洞中的几种基础绕过方式Pass-01前端 JS 验证绕过Pass-02Content-Type / MIME 验证绕过Pass-03黑名单特殊后缀绕过Pass-04.htaccess 文件解析绕过Pass-05大小写绕过本文仅用于本地靶场学习与安全测试记录不涉及未授权测试。测试环境靶场Upload-Labs部署方式Docker 本地部署本地地址http://127.0.0.1:8080/抓包工具Burp Suite验证代码仅使用 echo “upload_ok” 进行测试0x01 通用测试文件说明前五关中测试文件基本使用同一个shell.jpg。「偽圖片馬雛形」前面有 GIF89a後面有 PHP 代碼文件内容如下GIF89a?phpechoupload_ok;?这里的 GIF89a 用来伪装图片文件头后面的 PHP 代码只用于本地靶场中验证是否成功解析执行。如果访问上传后的文件时页面输出GIF89a upload_ok说明 PHP 代码被成功解析执行。0x02 靶場實踐Pass-01前端 JS 验证绕过漏洞點只做前端 JS 後綴檢查服務端沒有嚴格校驗。實踐打開發現有任务上传一个webshell到服务器。上传区 选择要上传的图片自己做一個shell.jpgBP抓包shell.jpg改包shell.php成功上傳http://127.0.0.1:8080/upload/shell.php出現GIF89a upload_ok成功執行php語句修改 echo 內容重新測試確認 PHP 語句確實被執行結論Pass-01 的核心是前端校驗不可信。只要服務端沒有重新檢查文件後綴就可以通過抓包改文件名繞過。Pass-02Content-Type / MIME 验证绕过漏洞點本關服務端主要依賴請求中的Content-Type判斷文件類型。但Content-Type是由客戶端提交的攻擊者可以通過Burp Suite抓包修改因此不能作為可靠的文件類型判斷依據。實踐打開依舊要求上传一个webshell到服务器。構造兩個內容相同的測試文件開頭的通用shell.jpg和一個shell.txt内容相同。GIF89a ?phpechoupload_ok;?分別上傳txt和jpg抓包改filename後綴 如圖均改為shell02.php測試。txt的無法成功上傳之後jpg的成功了。訪問http://127.0.0.1:8080/upload/shell02.php成功上傳并執行php語句回去重試shell.txt改後綴 如圖改為shell02re.php測試並把MIME改動Content-Type: text/plain改成Content-Type: image/jpeg訪問http://127.0.0.1:8080/upload/shell02re.php發現成功上傳并執行php語句結論Pass-02 的關鍵不是文件一開始叫 jpg 還是 txt而是服務端信任了客戶端傳入的 Content-Type。只要把 Content-Type 偽造成 image/jpeg就可以繞過 MIME 類型檢查。防護思路不能只信任 Content-Type。服務端應該同時檢查後綴白名單、文件真實內容、文件頭並且上傳目錄不要允許 PHP 解析。Pass-03黑名单特殊后缀绕过漏洞點服務端使用黑名單過濾危險後綴但黑名單不完整。只限制常見 .php等未充分限制.phtml / .php3 / .php5等可被 PHP 解析的後綴。利用思路上傳帶有 GIF89a 文件頭的 PHP 代碼文件將文件名後綴改為 .php5 / .phtml 等特殊 PHP 後綴繞過黑名單。上傳成功後從 Response Raw 中獲取服務端重命名後的實際路徑再訪問該路徑驗證 PHP 是否執行。實踐打開依然是上传一个webshell到服务器。依然使用自己做的shell.jpg。改包.jpg後綴.php被攔截了。換phtml,php3,php5,pjipk(亂打測黑/白名單這裏亂打可以上傳是黑名單)可以上傳。輸入構造的url:ip:port/upload/shell03.phtml ip:port/upload/shell03.php5卻都是404 not found回到bp Raw仔細審查發現原來是上傳路徑被自動改成了時間戳如圖:…/upload/202605251711241151.php5訪問后發現果然成功在這裏執行注意上傳成功不等於執行成功。是否能執行取決於服務端 Apache/PHP 是否解析該特殊後綴。靶場環境可能圖中未成功解析遇到問題本地 Docker 版 upload-labs 中特殊後綴可以上傳成功但 Apache 默認未解析 .phtml / .php3 / .php5導致訪問後只顯示圖片/源碼不執行 PHP。()修復方式回cmddocker exec upload-labs ls-lah/var/www/html/upload二次確認確實成功上傳curl.exe-i http://127.0.0.1:8080/upload/202605251711241151.php5查看后?php echo upload_ok; ?説明未能成功解析docker exec-it upload-labs bash進入容器後新增 Apache PHP 後綴解析配置cat/etc/apache2/conf-available/php-extra-ext.conf EOFFilesMatch^.\.(php|phar|phtml|php3|php5)$ SetHandler application/x-httpd-php /FilesMatch EOF a2enconf php-extra-ext apachectl-k graceful apachectl-M|grep-i php grep-R-n-Ephp5|phtml|SetHandler/etc/apache2/conf-enabled/etc/apache2/mods-enabled|head-50讓 .phtml/.php3/.php5 交給 PHP handler 處理。exit退出再次驗證curl.exe -i http://127.0.0.1:8080/upload/202605251711241151.php5這回upload_ok 成功修復了靶場解析。結論不能只看黑名單不完整能不能上傳成功還要看服務端會把上傳文件自動重命名上傳後能不能被服務端解析執行。Pass-04.htaccess 文件解析绕过漏洞點服務端使用黑名單過濾危險後綴但沒有攔截.htaccess。如果 Apache 允許讀取 .htaccess就可以通過 .htaccess 修改當前目錄下文件的解析方式讓原本的 .jpg 被當成 PHP 執行。實踐打開依然是上传一个webshell到服务器。依然使用自己做的shell.jpg。先測試改包 php發現被攔截。其他一些主流特殊後綴比如 .php3 / .Php / .phtml 也不太合適。做一個.htaccessSetHandler application/x-httpd-php注意這裡文件名必須是真正的.htaccess。不要加前綴傳成了 1.htaccesstest.htaccess等那只是普通文本文件訪問時只會顯示 SetHandler application/x-httpd-php不會生效。Apache 只會把文件名完全等於 .htaccess 的文件當作目錄配置讀取。上傳 .htaccess 成功。再次直接上傳shell.jpg 成功解析因為 .htaccess 已經把當前目錄下的文件交給 PHP handler 處理所以訪問 shell.jpg 時PHP 語句成功執行只輸出 upload_ok。結論Pass-04 的核心是.htaccess解析繞過。服務端只攔了常見危險後綴但沒有攔 .htaccess導致攻擊者可以先上傳 .htaccess 改變解析規則再上傳帶 PHP 代碼的 jpg 文件。本關重點不是單純改後綴而是利用 Apache 的 .htaccess 機制改變解析方式。避坑.htaccess 必須叫 .htaccess不能叫 1.htaccess。上傳成功不等於生效要再訪問 shell.jpg 驗證 PHP 是否執行。如果只看到 PHP 源碼說明沒有被解析。如果只看到 SetHandler application/x-httpd-php說明你訪問到的是普通文件不是真正生效的 .htaccess。Pass-05大小写绕过漏洞點服務端使用黑名單檢查危險後綴但檢查時沒有先把後綴統一轉成小寫導致 .php 被攔截但 .phP / .Php / .pHp 這類大小寫混合後綴可以繞過。實踐打開依然是上传一个webshell到服务器。依然使用自己做的shell.jpg。這裏改包.jpg後綴任意大小寫混淆的.pHp.PHp.PhP…這類都可以成功上傳 路徑在BP裏仔細審查可以找到上傳路徑如圖,不是文件原名 被改成了時間戳訪問url:http://127.0.0.1:8080/upload/202605270941158915.phP成功執行結論需要看Response Raw找到服務端重命名後的真實路徑。本關重點是後綴大小寫繞過。
Upload-Labs Pass-01 ~ Pass-05 通關記錄：前端校驗、MIME、特殊後綴、.htaccess、大小寫繞過
发布时间：2026/5/29 6:56:10
Upload-Labs Pass-01 ~ Pass-05 通关记录前端校验、MIME、特殊后缀、.htaccess、大小写绕过0x00 前言上一篇文章记录了 Upload-Labs 靶场在 Windows 11 Docker Desktop 环境下的本地部署过程。本篇开始记录 Upload-Labs 前五关的通关过程主要涉及文件上传漏洞中的几种基础绕过方式Pass-01前端 JS 验证绕过Pass-02Content-Type / MIME 验证绕过Pass-03黑名单特殊后缀绕过Pass-04.htaccess 文件解析绕过Pass-05大小写绕过本文仅用于本地靶场学习与安全测试记录不涉及未授权测试。测试环境靶场Upload-Labs部署方式Docker 本地部署本地地址http://127.0.0.1:8080/抓包工具Burp Suite验证代码仅使用 echo “upload_ok” 进行测试0x01 通用测试文件说明前五关中测试文件基本使用同一个shell.jpg。「偽圖片馬雛形」前面有 GIF89a後面有 PHP 代碼文件内容如下GIF89a?phpechoupload_ok;?这里的 GIF89a 用来伪装图片文件头后面的 PHP 代码只用于本地靶场中验证是否成功解析执行。如果访问上传后的文件时页面输出GIF89a upload_ok说明 PHP 代码被成功解析执行。0x02 靶場實踐Pass-01前端 JS 验证绕过漏洞點只做前端 JS 後綴檢查服務端沒有嚴格校驗。實踐打開發現有任务上传一个webshell到服务器。上传区 选择要上传的图片自己做一個shell.jpgBP抓包shell.jpg改包shell.php成功上傳http://127.0.0.1:8080/upload/shell.php出現GIF89a upload_ok成功執行php語句修改 echo 內容重新測試確認 PHP 語句確實被執行結論Pass-01 的核心是前端校驗不可信。只要服務端沒有重新檢查文件後綴就可以通過抓包改文件名繞過。Pass-02Content-Type / MIME 验证绕过漏洞點本關服務端主要依賴請求中的Content-Type判斷文件類型。但Content-Type是由客戶端提交的攻擊者可以通過Burp Suite抓包修改因此不能作為可靠的文件類型判斷依據。實踐打開依舊要求上传一个webshell到服务器。構造兩個內容相同的測試文件開頭的通用shell.jpg和一個shell.txt内容相同。GIF89a ?phpechoupload_ok;?分別上傳txt和jpg抓包改filename後綴 如圖均改為shell02.php測試。txt的無法成功上傳之後jpg的成功了。訪問http://127.0.0.1:8080/upload/shell02.php成功上傳并執行php語句回去重試shell.txt改後綴 如圖改為shell02re.php測試並把MIME改動Content-Type: text/plain改成Content-Type: image/jpeg訪問http://127.0.0.1:8080/upload/shell02re.php發現成功上傳并執行php語句結論Pass-02 的關鍵不是文件一開始叫 jpg 還是 txt而是服務端信任了客戶端傳入的 Content-Type。只要把 Content-Type 偽造成 image/jpeg就可以繞過 MIME 類型檢查。防護思路不能只信任 Content-Type。服務端應該同時檢查後綴白名單、文件真實內容、文件頭並且上傳目錄不要允許 PHP 解析。Pass-03黑名单特殊后缀绕过漏洞點服務端使用黑名單過濾危險後綴但黑名單不完整。只限制常見 .php等未充分限制.phtml / .php3 / .php5等可被 PHP 解析的後綴。利用思路上傳帶有 GIF89a 文件頭的 PHP 代碼文件將文件名後綴改為 .php5 / .phtml 等特殊 PHP 後綴繞過黑名單。上傳成功後從 Response Raw 中獲取服務端重命名後的實際路徑再訪問該路徑驗證 PHP 是否執行。實踐打開依然是上传一个webshell到服务器。依然使用自己做的shell.jpg。改包.jpg後綴.php被攔截了。換phtml,php3,php5,pjipk(亂打測黑/白名單這裏亂打可以上傳是黑名單)可以上傳。輸入構造的url:ip:port/upload/shell03.phtml ip:port/upload/shell03.php5卻都是404 not found回到bp Raw仔細審查發現原來是上傳路徑被自動改成了時間戳如圖:…/upload/202605251711241151.php5訪問后發現果然成功在這裏執行注意上傳成功不等於執行成功。是否能執行取決於服務端 Apache/PHP 是否解析該特殊後綴。靶場環境可能圖中未成功解析遇到問題本地 Docker 版 upload-labs 中特殊後綴可以上傳成功但 Apache 默認未解析 .phtml / .php3 / .php5導致訪問後只顯示圖片/源碼不執行 PHP。()修復方式回cmddocker exec upload-labs ls-lah/var/www/html/upload二次確認確實成功上傳curl.exe-i http://127.0.0.1:8080/upload/202605251711241151.php5查看后?php echo upload_ok; ?説明未能成功解析docker exec-it upload-labs bash進入容器後新增 Apache PHP 後綴解析配置cat/etc/apache2/conf-available/php-extra-ext.conf EOFFilesMatch^.\.(php|phar|phtml|php3|php5)$ SetHandler application/x-httpd-php /FilesMatch EOF a2enconf php-extra-ext apachectl-k graceful apachectl-M|grep-i php grep-R-n-Ephp5|phtml|SetHandler/etc/apache2/conf-enabled/etc/apache2/mods-enabled|head-50讓 .phtml/.php3/.php5 交給 PHP handler 處理。exit退出再次驗證curl.exe -i http://127.0.0.1:8080/upload/202605251711241151.php5這回upload_ok 成功修復了靶場解析。結論不能只看黑名單不完整能不能上傳成功還要看服務端會把上傳文件自動重命名上傳後能不能被服務端解析執行。Pass-04.htaccess 文件解析绕过漏洞點服務端使用黑名單過濾危險後綴但沒有攔截.htaccess。如果 Apache 允許讀取 .htaccess就可以通過 .htaccess 修改當前目錄下文件的解析方式讓原本的 .jpg 被當成 PHP 執行。實踐打開依然是上传一个webshell到服务器。依然使用自己做的shell.jpg。先測試改包 php發現被攔截。其他一些主流特殊後綴比如 .php3 / .Php / .phtml 也不太合適。做一個.htaccessSetHandler application/x-httpd-php注意這裡文件名必須是真正的.htaccess。不要加前綴傳成了 1.htaccesstest.htaccess等那只是普通文本文件訪問時只會顯示 SetHandler application/x-httpd-php不會生效。Apache 只會把文件名完全等於 .htaccess 的文件當作目錄配置讀取。上傳 .htaccess 成功。再次直接上傳shell.jpg 成功解析因為 .htaccess 已經把當前目錄下的文件交給 PHP handler 處理所以訪問 shell.jpg 時PHP 語句成功執行只輸出 upload_ok。結論Pass-04 的核心是.htaccess解析繞過。服務端只攔了常見危險後綴但沒有攔 .htaccess導致攻擊者可以先上傳 .htaccess 改變解析規則再上傳帶 PHP 代碼的 jpg 文件。本關重點不是單純改後綴而是利用 Apache 的 .htaccess 機制改變解析方式。避坑.htaccess 必須叫 .htaccess不能叫 1.htaccess。上傳成功不等於生效要再訪問 shell.jpg 驗證 PHP 是否執行。如果只看到 PHP 源碼說明沒有被解析。如果只看到 SetHandler application/x-httpd-php說明你訪問到的是普通文件不是真正生效的 .htaccess。Pass-05大小写绕过漏洞點服務端使用黑名單檢查危險後綴但檢查時沒有先把後綴統一轉成小寫導致 .php 被攔截但 .phP / .Php / .pHp 這類大小寫混合後綴可以繞過。實踐打開依然是上传一个webshell到服务器。依然使用自己做的shell.jpg。這裏改包.jpg後綴任意大小寫混淆的.pHp.PHp.PhP…這類都可以成功上傳 路徑在BP裏仔細審查可以找到上傳路徑如圖,不是文件原名 被改成了時間戳訪問url:http://127.0.0.1:8080/upload/202605270941158915.phP成功執行結論需要看Response Raw找到服務端重命名後的真實路徑。本關重點是後綴大小寫繞過。
