案例場景

開發者尋求 UTF-8 轉 GB2312 解決方案無果，嘗試入侵目標 WAP 站點獲取原始碼。目標為自建系統，發現 /wapadmin 管理目錄，且文章提交頁面存在上傳功能，但限制副檔名。

繞過演進

第一嘗試：雙重副檔名

上傳 shell.asp. (尾隨點號)，系統將點號替換為底線，生成 shell_asp，失效。

第二嘗試：URL 編碼繞過

利用 %2E 代表點號，檔名設為 shell%2Easp.，系統未解碼即過濾，上傳成功但檔名變為 shell.asp.。Windows 忽略尾隨點號，瀏覽器訪問 shell.asp 即可執行。

技術根因

• 過濾邏輯順序錯誤：先過濾再解碼，導致編碼字元繞過檢查。
• 檔名正規化不一致：Windows 檔案系統自動移除尾隨點號，Web 伺服器解析時仍視為 ASP。
• 執行權限控制缺失：上傳目錄具備腳本執行權限。

防禦對策

1. 統一編碼處理：在任何安全檢查前，先將輸入完全解碼 (URL、Unicode、Base64 等)，再進行規則匹配。
2. 白名單驗證：僅允許預期副檔名 (如 .jpg, .png, .gif)；拒絕多重副檔名、特殊字元。
3. 檔案內容驗證：讀取檔案頭 (Magic Number) 確認圖片格式；使用影像處理庫重繪/轉碼剝離潛在腳本。
4. 儲存隔離與執行禁用：上傳目錄設為不可執行 (IIS 移除執行權限、Apache SetHandler none)；檔案重新命名為隨機字串無副檔名；透過下載腳本輸出並設定 Content-Disposition: attachment。
5. WAF 規則：攔截包含 %2E, %00, 雙重副檔名等惡意上傳請求。

總結

看似簡單的編碼繞過，實則暴露輸入驗證、檔案處理、伺服器配置多層缺陷。上傳功能為高風險入口，必須實施「驗證、轉換、隔離、監控」全生命週期防護。