HTTP Status Code Analysis

發佈日期: 作者:

HTTP 狀態碼是 Web 安全分析中低成本、高回報的數據來源，對資安人員（不論是紅隊滲透測試、藍隊 SOC 監控、或是 DevSecOps 應用程式安全開發）而言，HTTP Status Codes是網路流量中最直觀、也最富含情報量的「第一線偵測指標」。

基本概念

HTTP 狀態碼（HTTP Status Code） 是伺服器在回應用戶端（例如瀏覽器、App、API 呼叫端）的請求時，用來表示「這次請求處理結果」的一組三位數數字代碼。

當你在瀏覽器輸入網址、點擊連結，或是程式發送 API 請求時，背後其實是這樣的流程：

1.用戶端 (Client) ──發送請求 (Request)──> 伺服器 (Server)
2.用戶端 (Client) <──回傳回應 (Response)── 伺服器 (Server)

伺服器在回應（Response）的開頭，就會附上一個狀態碼，讓用戶端知道：

  • 請求成功了嗎？
  • 需要做什麼後續動作嗎？
  • 是我（用戶端）的問題，還是伺服器的問題？

狀態碼用途

如果沒有狀態碼，用戶端就無法「自動判斷」請求到底成功還是失敗，只能靠人眼去看回傳的內容，這對程式來說非常不方便。有了標準化的狀態碼，瀏覽器、程式、API 都能依照統一規則來處理：

  • 瀏覽器看到 404，會顯示「找不到網頁」
  • 程式看到 401，會自動跳轉去登入頁
  • 下載工具看到 206，知道可以續傳

五大類狀態碼

狀態碼由三位數字組成，第一位數字決定它屬於哪個大類：

開頭類別意義
1xx資訊性 (Informational)請求已收到，仍在處理中
2xx成功 (Success)請求成功處理
3xx重新導向 (Redirection)需要進一步動作（如跳轉）
4xx用戶端錯誤 (Client Error)請求本身有問題
5xx伺服器錯誤 (Server Error)伺服器處理時出錯

這套標準是由 IETF 制定並記錄在 RFC 文件中（主要是 RFC 9110），目前主流瀏覽器、Web 伺服器、API 框架幾乎都遵循這套規範。

2xx – 成功 (Success)

表示請求已被伺服器成功接收並處理，常見有以下：

  • 200 OK：請求成功，最常見的狀態碼
  • 201 Created：請求成功且建立了新資源（常用於 POST）
  • 204 No Content：請求成功，但沒有回傳內容（常用於 DELETE）
  • 206 Partial Content：只回傳資源的部分內容

HTTP 200 – OK

  • 簡介：表示請求已成功處理，伺服器依據請求內容傳回對應的資料或處理結果。
  • 正常與攻擊行為出現機率（估計，僅供參考）：
    • 正常行為：約 95%（常態業務流量、靜態資源載入、一般 API 正常調用）。
    • 攻擊行為：約 5%（L7 CC 攻擊耗盡資源，或暴力破解/憑證填充成功繞過驗證）。
  • 正常行為的判斷方式：請求均勻分散於網站頁面、靜態資源與常態 API；IP 來源廣泛且符合真實使用者瀏覽行為與時段起伏；回應時間與流量體積維持在正常基準線。
  • 攻擊行為的判斷方式：
    • 判斷特徵：大量請求高度集中於高運算 API（如搜尋、複雜報表）或登入端點；來自少數 IP 高頻發送，或 Botnet 以極固定併發節奏存取；登入 API 在大量 200 回應中伴隨持續變化的帳密 Payload。
    • 原因與情境：L7 HTTP Flood / CC 攻擊、暴力破解成功（Successful Brute Force）。攻擊者發送大量合法請求耗盡伺服器 CPU、記憶體或資料庫；或是自動化腳本撞庫成功，伺服器回傳 200 與 Token，代表已入侵成功。
  • 異常行為建議處置方式：
    • 在 WAF / API Gateway 設定 Rate Limiting 與 IP 限制。
    • 對登入與高耗能 API 強制啟用驗證碼（CAPTCHA）或多因素驗證（MFA）。

HTTP 204 – No Content

  • 簡介：表示請求已成功處理，但伺服器意圖不傳回任何 Response Body（常見於 Ajax 跨域預檢與數據打點）。
  • 正常與攻擊行為出現機率（估計，僅供參考）：
    • 正常行為：約 98%（SPA 框架自動發起的 CORS OPTIONS 預檢、前端埋點/統計 Analytics Beacon）。
    • 攻擊行為：約 2%（利用未授權 API 進行批量數據刪除，或 CORS 防火牆探針）。
  • 正常行為的判斷方式：請求方法多為前端瀏覽器自動發起的 CORS OPTIONS 預檢，或是頁面操作時觸發的背景數據打點，請求頻率與使用者瀏覽行為呈現正相關。
  • 攻擊行為的判斷方式：
    • 判斷特徵：大量請求集中於資料刪除（DELETE）或批量更新（PUT）端點；或自動化腳本在短時間內發送極大量無效的 OPTIONS 跨域請求。
    • 原因與情境：未授權批量刪除（Unauthorized Mass Deletion / BOLA）、CORS 防火牆探針。攻擊者利用未適當鑑權的 API 漏洞，透過自動化腳本批量發送 DELETE 請求清空資料庫；或高頻發送 OPTIONS 進行跨域探針與資源消耗。
  • 異常行為建議處置方式：
    • 嚴格實施 API 資源層級的權限驗證（Broken Object Level Authorization 防護）。
    • 在 API Gateway 層針對無效 OPTIONS 請求進行速率限制。

HTTP 206 – Partial Content

  • 簡介：表示伺服器已成功處理部分 GET 請求，僅傳回資源的特定區段（常用於影音串流與斷點續傳）。
  • 正常與攻擊行為出現機率（估計，僅供參考）：
    • 正常行為：約 95%（影音網站播放、大檔案分段下載或下載中斷後續傳）。
    • 攻擊行為：約 5%（發送極度混亂或重疊的 Range Header 進行 Range Header DoS 攻擊）。
  • 正常行為的判斷方式：集中於影音或大檔下載服務，請求 Header 中的 Range 為連續且合理的位元組區段（如 bytes=0-1023），伺服器 CPU 與記憶體消耗平穩。
  • 攻擊行為的判斷方式：
    • 判斷特徵：請求 Header 中的 Range 包含大量重複、重疊、極多混亂的小區段或異常數值，且伴隨伺服器記憶體與 CPU 瞬間飆升至 100%。
    • 原因與情境：Range Header DoS 攻擊（此類手法在早期 Apache 曾有知名漏洞案例，俗稱 Apache Killer）。攻擊者在請求中構造極其複雜或大量重疊的 Range 範圍，迫使伺服器在記憶體中進行多次檔案切割與重組，導致記憶體爆滿與 CPU 耗盡。
  • 範例：
GET /large-archive.zip HTTP/1.1
Host: example.com
Range: bytes=0-,5-1,5-2,5-3,5-4,5-5,5-6...
  • 異常行為建議處置方式：
    • 在 Web 伺服器（Nginx/Apache）上限制單一請求中 Range 區段的最大數量（如限制最大 5 個）。
    • 更新 Web 伺服器至已修補歷史 Range Header 漏洞的版本。

3xx – 重新導向 (Redirection)

表示需要進一步的動作才能完成請求，通常是跳轉到另一個網址，常見的有以下。

  • 301 Moved Permanently：資源永久搬移到新網址
  • 302 Found：資源暫時搬移
  • 304 Not Modified：資源未變更，可使用快取版本

HTTP 304 – Not Modified

  • 簡介：表示請求的資源自上次存取後並未變更，指示客戶端直接讀取本地快取以節省頻寬。
  • 正常與攻擊行為出現機率（估計，僅供參考）：
    • 正常行為：約 90%（使用者瀏覽頁面時，瀏覽器對靜態檔案進行快取驗證）。
    • 攻擊行為：約 10%（攻擊者利用低頻寬成本發送高頻快取驗證請求進行資源耗盡）。
  • 正常行為的判斷方式：請求目標集中在 .css、.js、.png 等靜態檔案；IP 分佈廣泛；且該 IP 在出現 304 前曾有過先取得資源的 200 OK 紀錄，網路出方向頻寬低且 CPU/資料庫負載平穩。
  • 攻擊行為的判斷方式：
    • 判斷特徵：請求集中在動態 API 端點（如 /api/v1/users）；無前置 200 OK 紀錄（持硬編碼 ETag 盲打）；單一 IP 極高頻發送或 If-None-Match 值長期固定；伺服器頻寬極低但 CPU 使用率飆升、資料庫 Connection Pool 被占滿。
    • 原因與情境：此處姑且稱為「快取驗證資源耗盡攻擊」（此為概念性描述，非業界正式命名的攻擊類別）。原理是伺服器要決定是否回傳 304，必須先執行後端邏輯生成當前內容再計算 ETag 比對；攻擊者利用「低上行頻寬成本、高後端算力消耗」的不對稱特性耗盡伺服器算力與連線池。
  • 範例：
GET /api/v1/products/search?keyword=phone HTTP/1.1
Host: example.com
User-Agent: python-requests/2.31.0
If-None-Match: "w/9876543210"
  • 異常行為建議處置方式：
    • 靜態資源改由 CDN/反向代理直接處理快取比對，避免請求穿透至後端應用伺服器。
    • 對於高耗能動態 API 停用 ETag 生成，或在 CDN 層進行快取防護。

4xx – 用戶端錯誤 (Client Error)

表示請求本身有問題，通常是用戶端（瀏覽器/呼叫端）的錯誤，常見的有以下。

  • 400 Bad Request：請求格式錯誤
  • 401 Unauthorized：未經授權（需要登入/驗證）
  • 403 Forbidden：伺服器拒絕存取（權限不足）
  • 404 Not Found：找不到該資源
  • 405 Method Not Allowed：使用了該資源不支援的 HTTP 方法（例如對唯讀資源發送 POST）
  • 409 Conflict：請求與伺服器目前的資源狀態衝突（例如同時編輯造成版本衝突、重複建立已存在的資源）
  • 426 Upgrade Required：伺服器要求用戶端切換到不同的協定才能繼續（例如要求從 HTTP 升級為 HTTPS 或 WebSocket）

HTTP 400 – Bad Request

  • 簡介：表示客戶端發送的請求存在語法錯誤、格式不符或 Header 異常，伺服器無法解析。
  • 正常與攻擊行為出現機率（估計，僅供參考）：
    • 正常行為：約 70%（前端程式碼 Bug、API 版本變更導致 Request Body 格式不相容、Cookie 過長）。
    • 攻擊行為：約 30%（自動化掃描器進行 Fuzzing 測試、注入畸形 Payload 或測試 HTTP Smuggling）。
  • 正常行為的判斷方式：多集中在特定新上線或有 Bug 的 API 路徑，主因為前端程式碼 Bug（如 JSON 少了雙引號或型態不符）或舊版 App/Web 頁面規格不相容。
  • 攻擊行為的判斷方式：
    • 判斷特徵：請求全面性覆蓋全站各個端點；Payload 或 Header 帶有 SQL 語法符號、腳本標籤（<script>）、過長/畸形 Header，或非 UTF-8 變碼字元。
    • 原因與情境：Web 自動化模糊測試（Fuzzing）、漏洞掃描、HTTP Desync / Request Smuggling 前置測試。攻擊者利用工具注入異常字元、畸形 Payload、過長 Header，試圖尋找系統未處理的例外、毀損解析器或測試 HTTP 走私漏洞。
  • 範例：
POST /api/v1/user HTTP/1.1
Host: example.com
X-Custom-Header: %00%0d%0a
Content-Length: -1

{"username": "admin' OR '1'='1"}
  • 異常行為建議處置方式：
    • 在 WAF 設定嚴格的 Request Validation 與異常字元過濾規則。
    • 阻斷連續觸發大量 400 錯誤的來源 IP。

HTTP 401 – Unauthorized

  • 簡介：表示請求缺乏有效的身份驗證憑證，或是身份驗證失敗（需要登入或提供 Token）。
  • 正常與攻擊行為出現機率（估計，僅供參考）：
    • 正常行為：約 60%（使用者 Session 過期後前端未適當跳轉登入頁，導致背景輪詢 API 持續拋錯）。
    • 攻擊行為：約 40%（自動化黑客工具發動暴力破解或憑證填充攻擊）。
  • 正常行為的判斷方式：請求多集中在一般業務 API，主因是使用者 Session 過期後前端未適當跳轉登入頁，導致相同的過期 Token 在背景重複送出（計時器死迴圈）。
  • 攻擊行為的判斷方式：
    • 判斷特徵：請求高度集中在登入驗證端點（/api/auth/login）；Payload 中的帳號或密碼欄位持續變動，且請求常來自大量分散的 IP（Botnet）。
    • 原因與情境：暴力破解（Brute Force）、憑證填充（Credential Stuffing）——這兩者為業界通用術語。攻擊者持字典檔嘗試爆破帳密，或使用外洩的帳密庫進行批量自動化測試，嘗試獲取合法存取權限。
  • 異常行為建議處置方式：
    • 針對登入端點部署 Account Lockout 機制與 IP 級別 Rate Limiting。
    • 引入憑證填充防護（Credential Stuffing Protection）與人機驗證（CAPTCHA）。

HTTP 403 – Forbidden

  • 簡介：表示伺服器理解請求，但拒絕提供存取權限（已確認身份但權限不足，或被 WAF 防火牆阻斷）。
  • 正常與攻擊行為出現機率（估計，僅供參考）：
    • 正常行為：約 30%（使用者存取未授權頁面、伺服器內部檔案權限配置錯誤）。
    • 攻擊行為：約 70%（攻擊者探測敏感目錄、越權存取，或 WAF 精準攔截惡意攻擊 Payload）。
  • 正常行為的判斷方式：多為使用者點擊了權限不足的頁面，或是系統檔案目錄權限（Directory Permission）配置錯誤，觸發點零星且隨機。
  • 攻擊行為的判斷方式：
    • 判斷特徵：請求集中在敏感系統目錄（/.git、/admin、/.env）；請求參數常含有跨站腳本（XSS）、SQL 注入等惡意特徵；或 Response 日誌中帶有 WAF（如 Cloudflare, ModSecurity）攔截標記。
    • 原因與情境：敏感目錄探測、越權存取嘗試（IDOR/BOLA）、WAF 大量攔截惡意攻擊。攻擊者嘗試存取未授權的後台或敏感檔案；或是攻擊者發送的 SQLi/XSS Payload 被防火牆精準偵測並阻斷。
  • 異常行為建議處置方式：
    • 審視目錄安全與 .env / .git 等敏感資源的存取管制（Web Server Level Deny）。
    • 若為 WAF 攔截，持續維護規則並封鎖高風險惡意 IP。

HTTP 404 – Not Found

  • 簡介：表示伺服器找不到請求的目標資源或網頁。
  • 正常與攻擊行為出現機率（估計，僅供參考）：
    • 正常行為：約 50%（網站死連結 Dead Links、前端靜態資源路徑引用錯誤、改版未設定 301 轉址）。
    • 攻擊行為：約 50%（自動化掃描器進行敏感路徑爆破、檔案枚舉與弱點掃描）。
  • 正常行為的判斷方式：多為網站死連結（Dead Links）、靜態資源路徑引用錯誤，或網站改版未設定 301 轉址，觸發頻率與使用者點擊正相關。
  • 攻擊行為的判斷方式：
    • 判斷特徵：請求大量不存在的後台、腳本名稱或備份檔名（如 /wp-admin、/backup.zip），且由自動化掃描器（如 Gobuster, dirsearch）以異常高頻連續爆破。
    • 原因與情境：路徑與敏感檔案探測（Web Path / Sensitive File Discovery）。攻擊者使用字典檔爆破枚舉隱藏路徑、後台登入頁、殘留的原始碼備份檔或已知漏洞套件。
  • 異常行為建議處置方式：
    • 部署 Fail2ban 或 WAF 自動封鎖短時間內觸發大量 404 錯誤的 IP。
    • 在網關層模糊化敏感路徑回應，避免洩漏後端技術棧資訊。

HTTP 405 – Method Not Allowed

  • 簡介：表示請求使用的 HTTP 方法（GET, POST, PUT, DELETE 等）不被該目標資源支援。
  • 正常與攻擊行為出現機率（估計，僅供參考）：
    • 正常行為：約 80%（前端工程師 API 呼叫寫錯，如 POST 錯寫成 GET，或對靜態檔發送 POST）。
    • 攻擊行為：約 20%（黑客進行 HTTP Method Tampering 測試，嘗試繞過 ACL 或測試 TRACE 漏洞）。
  • 正常行為的判斷方式：多為前端開發者寫錯 API 調用方式（如把 POST 錯寫成 GET，或對靜態檔發送 POST），集中在特定 API 端點。
  • 攻擊行為的判斷方式：
    • 判斷特徵：大量使用該端點原本不支援、且非典型 REST 操作的 HTTP 方法（如 TRACE、CONNECT、PROPFIND 等 WebDAV/除錯用方法），且針對全站多個端點進行地毯式測試。
    • 原因與情境：HTTP 方法竄改（Method Tampering）、TRACE 漏洞探針（跨站追蹤 / Cross-Site Tracing, XST，屬已知漏洞類別）。攻擊者嘗試利用罕見 Method 繞過基於特定 Method 設定的防火牆 ACL 規則，或測試伺服器是否開啟不安全的 TRACE 功能。
  • 異常行為建議處置方式：
    • 在 Web 伺服器全局停用不必要的 HTTP 方法（如停用 TRACE、TRACK 等危險方法），並確保跨域端點依需求精準開放 OPTIONS，各資源端點依 REST 設計精準開放其實際需要的 PUT/PATCH/DELETE。
    • 在路由層精準限制每個端點僅允許合法的 HTTP Method。

HTTP 409 – Conflict

  • 簡介：表示請求與目標資源當前的伺服器狀態發生衝突（如重複註冊、資料版本不一致），導致伺服器無法執行該請求。
  • 正常與攻擊行為出現機率（估計，僅供參考）：
    • 正常行為：約 80%（使用者手動連續點擊按鈕、前端缺乏防重複點擊機制，或高併發下的資料庫樂觀鎖比對失敗）。
    • 攻擊行為：約 20%（自動化腳本利用併發請求嘗試搶購、重複兌換優惠券或重複扣款）。
  • 正常行為的判斷方式：同一個使用者/IP 的重複請求間隔在「數秒級」（符合人類手動連點或頁面重新整理的速度）；來自真實瀏覽器 IP，且分佈隨機；請求集中於一般表單送出或資料更新端點。
  • 攻擊行為的判斷方式：
    • 判斷特徵：同一帳號或 Token 在「微秒（μs）或毫秒（ms）」等級的時間差內，從多執行緒同時發送數十至數百個完全相同的請求；目標高度集中在搶購、兌換等端點。
    • 原因與情境：競態條件（Race Condition）類型的資源搶奪攻擊。攻擊者利用系統在「檢查狀態」與「更新資料」之間的微秒時間差，試圖在伺服器還沒來得及把資源標記為「已使用」前，用併發請求繞過數量限制。
  • 異常行為建議處置方式：
    • 在關鍵交易端點引入 Redis 分散式鎖（Distributed Lock）或資料庫排他鎖，確保請求原子化處理（Atomic Operation）。
    • API Gateway 針對單一 Token/IP 設定嚴格的 Rate Limiting，並在前端按鈕加上 Debounce / Throttle 機制。

HTTP 426 – Upgrade Required

  • 簡介：表示伺服器拒絕使用當前的協定處理請求，並要求客戶端升級至指定協定（如更高版本 HTTP 或改用 WebSocket）後再重新傳送，此為應用層明確回應的正式狀態碼。
  • 正常與攻擊行為出現機率（估計，僅供參考）：
    • 正常行為：約 70%（伺服器/應用邏輯要求特定端點必須升級協定，如強制要求 WebSocket 升級，導致舊版 App、舊 SDK 呼叫失敗）。
    • 攻擊行為：約 30%（低階自動化攻擊腳本使用不支援的協定嘗試存取，觸發應用層明確拒絕）。
  • 正常行為的判斷方式：多發生在應用程式明確要求協定升級的端點（如即時通訊需求的 WebSocket 端點），因舊版 App 或未更新的 SDK 仍以舊協定發送請求而被拒絕。
  • 攻擊行為的判斷方式：
    • 判斷特徵：流量多來自撰寫粗糙的舊版腳本或爬蟲，對明確要求協定升級的端點持續以舊協定發送請求，且無視伺服器回應持續重試。
    • 原因與情境：低階自動化攻擊工具對特定協定升級端點的錯誤存取嘗試，通常代表工具本身老舊或未正確處理協定升級流程，較少屬於刻意的攻擊行為，多為背景雜訊。
  • 異常行為建議處置方式：
    • 維持入口網關的安全政策（強制 TLS 1.2+／HTTP/2），但此類政策通常在連線層而非應用層執行。
    • 若為正常 App 流量，提醒用戶更新 App 版本以正確支援協定升級流程。

HTTP 499 – Client Closed Request（Nginx 非標準）

  • 簡介：為 Nginx 自定義狀態碼（僅出現於 Nginx 存取日誌，不會實際回傳給客戶端），表示伺服器還在處理請求時，客戶端（瀏覽器/前端）主動中斷了 TCP 連線。
  • 正常與攻擊行為出現機率（估計，僅供參考）：
    • 正常行為：約 80%（後端 API 處理過慢導致使用者等不及而關閉/重新整理網頁，或前端 Timeout 設定過短）。
    • 攻擊行為：約 20%（攻擊者觸發高耗能 API 後故意立即斷開連線，進行慢速/非同步資源耗盡攻擊）。
  • 正常行為的判斷方式：伴隨後端 API 執行時間過長（如 10 秒以上報表查詢），使用者等不及而關閉或重新整理網頁；或前端 AJAX Timeout 設定過短。
  • 攻擊行為的判斷方式：
    • 判斷特徵：針對極高耗能端點，發送請求後在極短時間之內（如 100ms）故意主動切斷連線，並利用腳本高頻重複此動作。
    • 原因與情境：攻擊者觸發後端高負載運算（如複雜 SQL 或密碼 Hash）後立即斷開連線，避開自身維持連線的開銷，但迫使後端繼續完成高耗能運算，藉此快速耗盡伺服器的 CPU 與 Connection Pool。
  • 異常行為建議處置方式：
    • 確保後端應用程式框架（如 Go Context、Node.js Request Abort、Java Thread Interrupt）有正確監聽連線中斷事件以釋放資源。
    • 優化後端 API 查詢效能，並在 API Gateway 設定合理的 Request Timeout。

5xx – 伺服器錯誤 (Server Error)

表示伺服器在處理請求時發生錯誤，是伺服器端的問題，常見的有以下：

  • 500 Internal Server Error：伺服器內部發生未預期的錯誤
  • 502 Bad Gateway：伺服器作為閘道/代理時收到無效回應
  • 503 Service Unavailable：伺服器暫時無法處理請求（如過載或維護中）

HTTP 500 – Internal Server Error

  • 簡介：表示伺服器端發生未預期的程式錯誤或未處理的例外（Unhandled Exception），導致無法完成請求。
  • 正常與攻擊行為出現機率（估計，僅供參考）：
    • 正常行為：約 70%（程式碼 Bug、資料庫連線池耗盡 Connection Pool Exhaustion、第三方依賴服務崩潰）。
    • 攻擊行為：約 30%（攻擊者傳入惡意 Payload 故意觸發系統例外，嘗試獲取 Stack Trace 或發動 RCE/SQLi）。
  • 正常行為的判斷方式：集中在特定新上線功能、後端程式 Bug、資料庫連線池滿或第三方服務崩潰，請求 Payload 通常無惡意字元。
  • 攻擊行為的判斷方式：
    • 判斷特徵：請求參數帶有單引號（'）、特殊字元序列、反序列化標頭或系統命令符號（;, |），發生在攻擊者嘗試注入 Payload 的參數點。
    • 原因與情境：應用程式漏洞探測（SQLi, RCE, Command Injection, Deserialization）——皆為業界公認之正式漏洞分類。攻擊者輸入惡意 Payload 故意觸發未處理例外，試圖從 500 的 Error Stack Trace 中獲取敏感資訊（如資料庫類型、絕對路徑、套件版本）；或是漏洞已成功執行並造成後端程式崩潰。
  • 異常行為建議處置方式：
    • 關閉生產環境的 Debug 模式與詳細 Stack Trace 回應（統一傳回通用 500 頁面）。
    • 進行全站 Input Validation 與 Parameterized Queries（預編譯查詢），修補 SQLi/RCE 漏洞。