HTTP QUERY 新方法引發安全機制挑戰

HTTP QUERY 新方法引發安全機制挑戰

IETF 於 2024 年 6 月正式將 QUERY 方法納入 HTTP 標準（RFC 10008），這個介於 GET 與 POST 之間的全新動作，讓既有的 Web 安全機制出現了灰色地帶。SANS 網路風暴中心（ISC）警示，若防火牆、API Gateway、CSRF 防護與快取等控制未將 QUERY 列入判斷，可能導致安全檢查失效，成為攻擊者的新入口。

背景與影響

為何需要 QUERY

長期以來，開發者在處理複雜查詢時只能在 GET（安全、冪等）與 POST（可攜帶大量請求本文）之間取捨。QUERY 結合兩者特性：

• 安全（safe）：不會改變伺服器狀態，符合 HTTP 規範的安全動作。
• 冪等（idempotent）：同一請求可安全重複或重啟。
• 請求本文（request body）可放置複雜條件，避免 URL 過長。

現有元件支援差異

根據 ISC 資深分析師 Xavier Mertens（9 月 18 日）指出，市場上對 QUERY 的支援仍不統一：

• curl 已能發送 QUERY；
• Caddy、Traefik 以及 FastAPI 的特定路由可處理；
• Django 的 View 類別會直接拒絕；
• Nginx 的某些設定亦可能阻擋。

這種客戶端、伺服器、代理伺服器與框架的行為差異，使得安全控制的覆蓋範圍變得模糊。

可能的安全漏洞

1. WAF（Web 應用防火牆）規則缺失

   若僅在 POST 的請求本文上套用 SQL Injection、XSS、Command Injection 等偵測規則，QUERY 的本文將不受檢查，同樣的惡意載荷可能在 QUERY 中繞過防護。

2. 快取投毒

   QUERY 被定義為可快取且安全的方法；若快取機制未把完整的請求本文納入快取鍵值，攻擊者可利用不同本文的 QUERY 造成快取污染，進而向後續使用者分發被竄改的內容。

3. CSRF（跨站請求偽造）防護盲點

   現行 CSRF 防護多檢查 POST、PUT、DELETE 等會改變狀態的動作。若某個 QUERY 端點意外產生狀態變更，則可能繞過 CSRF 防護，形成新型攻擊向量。

未來展望與建議

• 更新規則庫：所有依賴 HTTP 方法進行判斷的 WAF、API Gateway、IDS/IPS 必須將 QUERY 納入正規表示式與偵測規則。
• 快取策略調整：快取層應將請求本文納入快取鍵，或對 QUERY 設定更嚴格的快取失效條件，以防止投毒。
• CSRF 防護擴充：開發團隊應重新審視 CSRF Token 的適用範圍，將可能產生狀態變更的 QUERY 端點列入防護清單。
• 框架與伺服器支援統一：社群與標準制定者可協作，提供一致的 QUERY 處理指南，避免因實作差異產生安全盲點。

結語：QUERY 為 Web 應用帶來更彈性的查詢方式，但同時也挑戰了既有的安全防線。唯有在規則、快取與防偽機制上同步升級，才能確保新方法的安全落地，避免成為攻擊者的「新入口」。