新聞

網際網路標準制定組織（IETF）今年6月發布RFC 10008，正式定義新的HTTP「QUERY」方法。不過，SANS網路風暴中心（ISC）近日提醒，由於許多依賴HTTP method進行判斷的既有安全控制，都是在QUERY成為標準方法前設計，因此，WAF、API Gateway、CSRF防護及快取機制都需要重新檢視。若既有規則未將QUERY納入檢查與處理範圍，可能出現安全檢查未完整套用的情況。

多年以來，開發者在處理較複雜的查詢需求時，往往需要在GET與POST之間取捨。如今，QUERY提供新選項：如同GET，具備安全性與冪等性（idempotent），請求處理過程中不會改變狀態，並可自動重複或重啟，而無需擔心狀態的局部變化，又能如同POST一樣，將較複雜的查詢條件放在請求本文（request body）中。

但SANS ISC資深分析人員Xavier Mertens於9月18日發布專文指出，目前各類Web元件對QUERY已有不同程度的支援，但處理行為並不一致。例如curl已可發送QUERY請求，Caddy、Traefik及FastAPI特定路由也能處理，但Django的View類別會拒絕QUERY，Nginx的部分設定也可能擋下請求，顯示不同客戶端、伺服器、代理伺服器及框架對QUERY的處理仍有明顯差異。

更值得注意的是，既有的安全控制方式可能失效。Mertens舉例，若WAF僅針對POST的request body套用SQL Injection、XSS或Command Injection等偵測規則，卻未對QUERY進行相同的檢查，因此，同一組惡意內容可能在POST遭攔截，改以QUERY送出後卻能通過。

再者，由於QUERY依規範屬於可快取且安全（safe）的方法，若快取機制未將完整request body納入快取判斷條件，攻擊者可能藉此造成快取投毒，使後續使用者取得遭污染的內容；若CSRF防護只檢查POST、PUT、DELETE等傳統可能導致狀態變更的方法，一旦QUERY端點產生非預期的狀態變更，也可能繞過CSRF防護。Mertens因此提醒，應檢視並更新依賴HTTP method的規則與正規表示式，將QUERY納入既有處理邏輯。