Upload-Labs Pass-01 ~ Pass-05 通關記錄：前端校驗、MIME、特殊後綴、.htaccess、大小寫繞過

Upload-Labs Pass-01 ~ Pass-05 通关记录：前端校验、MIME、特殊后缀、.htaccess、大小写绕过

0x00 前言

上一篇文章记录了 Upload-Labs 靶场在 Windows 11 + Docker Desktop 环境下的本地部署过程。

本篇开始记录 Upload-Labs 前五关的通关过程，主要涉及文件上传漏洞中的几种基础绕过方式：

• Pass-01：前端 JS 验证绕过
• Pass-02：Content-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<?phpecho"upload_ok";?>

• 这里的 GIF89a 用来伪装图片文件头，后面的 PHP 代码只用于本地靶场中验证是否成功解析执行。

• 如果访问上传后的文件时页面输出：
  GIF89a upload_ok
  说明 PHP 代码被成功解析执行。
  

0x02 靶場實踐

Pass-01：前端 JS 验证绕过

• 漏洞點：
  只做前端 JS 後綴檢查，服務端沒有嚴格校驗。

• 實踐：

• • 打開發現有：
    任务：上传一个webshell到服务器。
    上传区 （选择要上传的图片）
• • 自己做一個shell.jpg
    BP抓包shell.jpg改包shell.php
    
    
    
• • 成功上傳http://127.0.0.1:8080/upload/shell.php
    出現GIF89a upload_ok，成功執行php語句（修改 echo 內容重新測試，確認 PHP 語句確實被執行）

• 結論：
  Pass-01 的核心是前端校驗不可信。
  只要服務端沒有重新檢查文件後綴，就可以通過抓包改文件名繞過。

Pass-02：Content-Type / MIME 验证绕过

• 漏洞點：
  本關服務端主要依賴請求中的Content-Type判斷文件類型。
  但Content-Type是由客戶端提交的，攻擊者可以通過Burp Suite抓包修改，因此不能作為可靠的文件類型判斷依據。

• 實踐：

• • 打開依舊要求上传一个webshell到服务器。
    
    構造兩個內容相同的測試文件：開頭的通用shell.jpg和一個shell.txt，内容相同。

GIF89a <?phpecho"upload_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。()

• 修復方式回cmd：

docker 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 <<'EOF'<FilesMatch"^.+\.(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-E"php5|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 也不太合適。
• • 做一個.htaccess

SetHandler application/x-httpd-php

• 注意：
  這裡文件名必須是真正的.htaccess。
  不要加前綴傳成了 1.htaccess，test.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找到服務端重命名後的真實路徑。
  本關重點是後綴大小寫繞過。