推出 Cloudflare WAF 的完整交易偵測功能

今天，我們透過新增兩項新功能來擴展我們的 Web 應用程式防火牆 (WAF)：完整交易偵測和回應規則。完整交易偵測會評估每個 HTTP 請求及其回應，以識別是否有遭到利用的證據。它有助於回答兩個問題：「這個請求看起來是否惡意？」以及「應用程式處理它時發生了什麼事？」。然後，回應規則可以在來源回應到達請求者之前封鎖其回應。

這些都是極具價值的防護措施，因為最新的前沿模型正在發現廣泛使用的軟體中深埋的漏洞，這讓防禦者清楚知道該修補什麼，但同時也為攻擊者提供了新的利用途徑。最近的 ​php2shell 漏洞顯示了其中的風險：通用軟體元件中的缺陷可能會使網際網路上的應用程式面臨風險。AI 智慧體掃描漏洞可以非常持久，使用回饋調整有效負載，並連結漏洞、認證和權限。應用程式的回應可以揭示嘗試是否有效，並為攻擊者提供幫助他們更深入的資訊。

檢查傳入請求對於在攻擊到達應用程式之前就將其攔截，仍然至關重要。但有些威脅只有將請求與來源伺服器的回傳內容一起考量時才會變得清晰。一個可疑的輸入，若伴隨著暴露敏感資訊的回應，與相同個輸入得到拒絕或錯誤的回應，兩者所代表的意義截然不同。

透過這些新功能，客戶可以使用 Cloudflare 受管理防護，或是自行建立結合請求與回應屬性的政策。這擴展了我們全天候運作的應用程式安全框架，偵測結果可在 Security Analytics（安全分析）中查看，以協助調查。我們首批使用此功能的受管理防護措施，針對的正是最近揭露的 php2shell 漏洞。

最棒的部分是什麼？我們即將對所有 Cloudflare 客戶（包括 Free 方案）全面開放這些新功能。

僅對請求進行檢查是不夠的

Cloudflare WAF 透過受管理規則、自訂規則和限速來保護網站與 API。受管理規則針對已知的攻擊手法和漏洞提供防護，而自訂規則則讓團隊能使用 IP 位址、URL 路徑、標頭和請求主體等參數來建立自己的政策。這些控制措施在請求層級運作，以阻止惡意利用或未經請求的流量到達來源伺服器。

對於許多威脅來說，這是正確的應對位置。然而，將每個可疑請求都視為已確認的攻擊行為，會形成一個艱難的取捨。廣泛的請求特徵碼 (signature) 可以攔截更多潛在攻擊，但也可能產生「誤判」，例如將合法流量誤判為攻擊，進而導致應用程式故障。若只部署不會觸發誤判的規則，雖然能降低此風險，但卻可能讓更多模稜兩可的流量有機會到達伺服器。

回應提供了缺失的關鍵證據。Cloudflare 現在可以將回應與產生它的請求進行關聯，因此偵測可以將整個 HTTP 交易的結果納入考量。

舉一個說明性的例子，假設有一個應用程式允許使用者下載檔案。攻擊者操縱檔案參數，以請求許可目錄之外的私人設定檔：

GET /download?file=../../config/database.ini

請求檢查可以識別出這個路徑遍歷 (path traversal) 嘗試，並在它到達應用程式之前將其封鎖。然而，單靠請求是無法確認應用程式是否會暴露該檔案的。應用程式可能會拒絕該請求、忽略遍歷嘗試，或是回傳錯誤。如果請求到達了來源伺服器，像下面這樣的回應就會提供額外的證據：

200 OK
Content-Type: text/plain
[database]
username=app_service
password=EXAMPLE_SECRET

完整交易偵測補上了缺失的一環：它可以將嘗試進行的檔案存取，與具有私人設定檔特徵的回應內容進行關聯。類似設定的文字確實可能合法地出現在文件或範例下載中；但將其與路徑遍歷嘗試結合，就能提供比單一訊號更強的敏感資料外洩證據。接著，回應規則可以在回應送達請求者之前，用 Cloudflare WAF 的封鎖頁面和 HTTP 403 狀態碼來取代來源伺服器的回應，透過防止敏感資訊到達攻擊者，有效地阻擋這次攻擊。

偵測與緩解在設計上是分開的

完整交易偵測擴展了我們今年稍早推出的​全天候偵測框架。偵測機制會分析流量，並將中繼資料附加到請求與回應上；接著，規則會決定如何處理這些結果。

將這兩項工作分開，能讓客戶在設計政策之前先獲得可見性。資安團隊可以檢查自己流量中的偵測結果，瞭解涉及哪些端點和特徵碼，並選擇最適合其應用程式的回應方式。類似於基於請求的​攻擊特徵碼偵測 (Attack Signature Detection) 方法，偵測結果會儲存在特定欄位中，可在回應自訂規則中存取，或用於受管理偵測中以封鎖流量。

仿照請求偵測欄位，我們的平台新增了以下欄位：

首批完整交易偵測功能專注於高知名度漏洞的攻擊確認。它會將可疑的輸入與回應訊號進行關聯，以判斷攻擊是否可能已成功。

未來我們將擴大涵蓋範圍，支援其他使用案例，包括偵測資料暴露與資料外流訊號。這對整個網際網路（而不僅僅是任何單一應用程式）都至關重要：防禦機制可以區分單純的探測行為與實際造成影響的證據，而偵測暴露資料和服務的功能，也能惠及那些沒有專屬資安團隊來逐一調整每條 WAF 規則的客戶。

在回應階段建立規則

如果能即時採取行動，那麼偵測到攻擊證據才最具實用價值。回應自訂規則能將完整交易偵測轉化為即時防護，在來源伺服器的相符回應送達請求者之前將其封鎖。不過要注意，它無法逆轉來源端已經執行的動作。

資安團隊現在可以結合請求屬性、回應屬性與偵測結果，來決定要封鎖哪些回應。當封鎖規則相符時，Cloudflare 會用 WAF 封鎖頁面或自訂回應來取代來源伺服器的原始回應。

回應階段的控制項可在 Cloudflare 儀表板的 Security（安全性） > Security Rules（安全性規則）頁面底部找到，其中包含受管理防護和自訂規則。

我們已向所有方案（包括 Free 方案）發布受管理規則與自訂規則。隨著時間推移，我們將遵循與請求偵測相同的做法：針對免費方案的受管理偵測將​聚焦於高知名度漏洞，而付費客戶則能獲得更豐富的偵測項目目錄。

受管理偵測

所有客戶都能透過 Cloudflare Managed Response Firewall Default（Cloudflare 受管理回應防火牆預設）規則集，獲得完整交易偵測陣列的防護。此規則集專為簡單的一鍵部署與簡化的可設定性而設計。當特徵碼相符時，受管理偵測將會封鎖回應，並回傳標準的 WAF 封鎖頁面。

您可以編輯 Cloudflare Managed Response Firewall Default 的範圍，使其僅在應用程式的特定部分執行偵測，例如透過排除或限制對特定路徑的偵測。付費客戶則可以在自訂回應規則中使用偵測欄位，以建立更具針對性的政策。

自訂規則

自訂回應規則旨在讓客戶對規則邏輯擁有完全的控制權。一個實用的規則可以在驗證閘道尚未將請求標記為內部請求時，阻止管理介面被暴露。例如：

http.request.uri.path starts_with "/admin" and not http.request.headers["x-internal-user"][0] eq "true" and http.response.code eq 200 and http.response.headers["content-type"][0] contains "text/html"

這條規則僅在未經驗證的請求指向 /admin，且來源伺服器實際回傳了成功的 HTML 管理頁面時才會封鎖。它不會封鎖普通的驗證失敗、重新導向或非管理介面的流量。

所有客戶最多可以建立三條支援「記錄」(Log) 與「封鎖」(Block) 動作的自訂回應規則。回應自訂規則中可用的欄位與函式，與您現有方案中​請求自訂規則所能使用的權限相同。目前尚不支援針對回應主體建立規則。

遵循​攻擊特徵碼偵測的做法，付費客戶也可以透過上述 cf.waf.signature.response.* 欄位來取得攻擊偵測的結果。這些欄位可以與其他參數（例如主機名稱、URL 路徑、來源 IP、請求標頭）結合，以在單一路徑上啟用防護，或將政策限制在特定的應用程式情境內。我們目前正在將回應欄位逐步推展至所有帳戶。如果您尚未取得存取權限，請聯繫您的客戶團隊。

調查相符的請求

當受管理或自訂回應規則記錄或封鎖了一筆交易時，該事件會顯示在 Security Events（安全性事件）中。這意味著應變人員可以將任何偵測結果追溯至請求的完整脈絡，以及採取行動的特定規則。

目前，僅針對請求的規則與完整交易規則會一同顯示在同一個分析頁面中。在 Security Events 中，由回應規則產生的事件屬於 Managed Rules（受管理規則）或 Custom Rules（自訂規則）服務的一部分。您可以在相對應的規則清單區段中，篩選屬於特定規則 ID 的事件。

立即開始使用

完整交易偵測現已正式提供給所有透過 Cloudflare 代理流量的區域。若要確認您是否受到保護，請前往 Cloudflare 儀表板中的 Security（安全性）> Security Rules（安全性規則）。如果您想自訂政策，請先從 Security Analytics（安全分析）中檢視完整交易偵測，接著建立最適合您應用程式的回應階段政策。