毒性組合：當微小訊號累積成安全事件

凌晨三點，一個孤立的 IP 位址請求了登入頁面。乍看無害。但隨後，同一個來源開始在多個主機和路徑上，附加 ?debug=true 參數——這是攻擊者正在探查環境，評估技術堆疊以策劃入侵的跡象。

微小的設定錯誤、被忽略的防火牆事件，或是請求的異常，單獨來看都顯得無害。然而，當這些微小的訊號匯聚在一起時，它們可能引爆被稱為「毒性組合」的安全事故。這類型攻擊中，攻擊者會發現並疊加多個小問題——例如 Web 應用程式上被遺留的除錯旗標，或是一個未經身分驗證的應用程式路徑——進而入侵系統或竊取資料。

Cloudflare 的網路會觀察對您技術堆疊發出的請求，因此擁有能在這些毒性組合形成時，即時識別出來的資料。在這篇文章中，我們將展示如何從應用程式安全資料中提取這些訊號。我們會探討最常見的毒性組合類型及其帶來的危險漏洞，並說明如何利用這些情報辨識並修補您技術堆疊中的弱點。

「毒性組合」可以有幾種不同的定義方式，但我們根據分析自身資料集的方式，採用一個實務性的定義。大多數網頁攻擊最終會透過自動化進行規模化；一旦攻擊者找到可行的漏洞利用方式，通常會將其寫成指令碼並交由機器人完成攻擊。藉由分析機器人流量、特定應用路徑、請求異常與設定錯誤的交集，我們就能找出潛在的入侵行為。我們運用此框架來處理每秒數百萬筆請求。

雖然像 Web 應用程式防火牆 (WAF)、機器人偵測與 API 防護等單點防禦機制已逐步加入行為模式與信譽訊號，但它們仍主要著重於評估單一請求的風險。相較之下，Cloudflare 對「毒性組合」的偵測則轉換視角，關注的是整體意圖，分析多項訊號周圍的上下文交集，以識別正在醞釀的事件。

^{毒性組合作為情境化的偵測}

這樣的視角轉換很重要，因為許多真實的安全事件並沒有明顯的攻擊負載、沒有清晰的特徵碼，也沒有任何會直接高喊「這是攻擊」的單一事件。因此，接下來我們將結合下列上下文資訊來建構數種毒性組合：

• 機器人訊號

• 應用程式路徑，尤其是敏感性路徑：管理員介面、除錯功能、指標、搜尋、付款流程

• 異常情況，包括：非預期的 HTTP 狀態碼、地理位置跳轉、身分不符、ID 大量變更、規避速率限制（多個分散 IP 執行相同操作）、請求數或成功率異常飆升

• 漏洞或設定錯誤：缺少工作階段 Cookie 或驗證標頭、可預測的識別碼

我們分析了 Cloudflare 在 24 小時內的資料，觀察這些模式在熱門應用程式堆疊中實際出現的頻率。如下表所示，約有 11% 的受分析主機容易遭受這類組合的影響，這主要是因為存在弱點的 WordPress 網站拉高了比例。若排除 WordPress 網站，僅有 0.25% 的主機顯示出可被利用的毒性組合跡象。儘管比例不高，這些主機仍具備被入侵的風險。

為了讓資料更容易理解，我們將其分解為攻擊的三個階段：

• 估計受探查主機數：這是「廣撒網」的階段，統計我們觀察到針對特定敏感路徑（如 /wp-admin）發出 HTTP 請求的唯一主機數量。

• 估計符合毒性組合篩選條件的主機數：在此階段，我們將清單範圍縮小，只納入那些實際符合我們毒性組合標準的特定主機。

• 估計可觸及主機數：這是對入侵嘗試成功回應的唯一主機數量，是攻擊的「確鑿證據」。單純的 200 OK 回應（例如附加 ?debug=true 所觸發的）可能為誤判。我們已對路徑進行驗證，以濾除以下情況造成的雜訊：雖然回傳 200 狀態碼但實際需要憑證的已驗證路徑、掩蓋真實入侵路徑的重新導向，以及對無法到達路徑仍回傳成功代碼的源站設定錯誤。

在接下來的章節中，我們將深入探討具體的發現結果，以及產生這些結果的組合背後的邏輯。需要強調的是，所提供的偵測查詢雖屬必要，但若未經可觸及性測試則不夠充分；這些發現結果仍有可能是誤判。在某些情況下，可以使用 Cloudflare Log Explorer 在未經抽樣的 Cloudflare 記錄上執行這些查詢。

表 1. 毒性組合摘要

我們觀察到自動化工具掃描常見的管理登入頁面，例如 WordPress 管理面板 (/wp-admin)、資料庫管理工具與伺服器儀表板。下方是一個可在 Cloudflare Log Explorer 中執行的查詢範本：

SELECT
  clientRequestHTTPHost,
  COUNT(*) AS request_count
FROM
  http_requests 
WHERE
  timestamp >= '{{START_DATE}}'
  AND timestamp <= '{{END_DATE}}'
  AND edgeResponseStatus = 200
  AND clientRequestPath LIKE '{{PATH_PATTERN}}' //e.g. '%/wp-admin/%'
  AND NOT match( extract(clientRequestHTTPHost, '^[^:/]+'), '^\\d{1,3}(\\.\\d{1,3}){3}(:\\d+)?$') // comment this line for Cloudflare Log Explorer
  AND botScore < {{BOT_THRESHOLD}} // we used botScore < 30
GROUP BY
  clientRequestHTTPHost
ORDER BY
  request_count DESC;

公開可存取的管理面板可能導致暴力密碼破解嘗試。一旦成功，攻擊者便可進一步入侵該主機，將其加入殭屍網路，繼續探測其他網站是否存在類似漏洞。此外，這類毒性組合還可能引發以下風險：

• 漏洞掃描：攻擊者可辨識您正在執行的軟體版本（如 Tomcat 或 WordPress），並對已知漏洞 (CVE) 發動針對性攻擊。

• 使用者列舉：許多管理面板會意外洩露有效使用者名稱，協助攻擊者製作更具說服力的網路釣魚郵件或登入攻擊。

此毒性組合由「機器人自動化」與「暴露的管理介面」構成，這些介面包括：/wp-admin/、/admin/、/administrator/、/actuator/*、/_search/、/phpmyadmin/、/manager/html/ 以及 /app/kibana/。

成分	訊號	描述
機器人活動	機器人分數 < 30	具有漏洞掃描器特徵的機器人簽章
異常	重複探查	管理端點出現異常的大量命中
漏洞	可公開存取的端點	對管理端點的成功請求

1. 實施 Zero Trust 存取。

2. 如果因任何原因必須讓端點保持公開，請實作挑戰平台以增加機器人的操作阻力。

3. 實作 IP 允許清單：使用您的 WAF 或伺服器設定，確保僅能從公司 VPN 或特定辦公室 IP 位置存取管理路徑。

4. 隱藏管理員路徑：若平台支援，可重新命名預設管理 URL（例如將 /wp-admin 改為不易猜測的唯一字串）。

5. 部署地理封鎖：若管理員只從特定國家/地區操作，可封鎖所有來自其他地區對敏感路徑的流量。

6. 實施多重要素驗證 (MFA)：確保每個管理入口都要求進行第二因素驗證；僅靠密碼無法針對性的爬蟲。

我們發現某些 API 端點能被網際網路上的任何人直接存取，不需要密碼或登入（參見 OWASP: API2:2023 – 驗證失效）。更糟的是，這些端點用來識別記錄的方式仰賴簡單、可預測的 ID 編號（參見 OWASP: API1:2023 – 物件層級授權失效），讓攻擊者只要「遞增」資料庫中的數字，就能逐筆列舉甚至「爬取」您的商業記錄，完全不需要造訪您的網站。

SELECT
  uniqExact(clientRequestHTTPHost) AS unique_host_count
FROM  http_requests
WHERE timestamp >= '2026-02-13'
  AND timestamp <= '2026-02-14'
  AND edgeResponseStatus = 200
  AND bmScore < 30
  AND (
       match(extract(clientRequestQuery, '(?i)(?:^|[&?])uid=([^&]+)'),  '^[0-9]{3,10}$')
    OR match(extract(clientRequestQuery, '(?i)(?:^|[&?])user=([^&]+)'), '^[0-9]{3,10}$')
    OR length(extract(clientRequestQuery, '(?i)(?:^|[&?])uid=([^&]+)'))  BETWEEN 3 AND 8
    OR length(extract(clientRequestQuery, '(?i)(?:^|[&?])user=([^&]+)')) BETWEEN 3 AND 8
  )

這是一個「零利用」漏洞，意思是攻擊者不需要是駭客就能竊取您的資料；他們只需要變更 Web 連結中的一個數字即可。這可能導致：

• 大量資料外洩：整批客戶資料集遭到大規模爬取。

• 二次攻擊：竊取的資料可能被用於網路釣魚或帳戶盜用。

• 法規風險：暴露敏感的個人識別資訊 (PII)，違反 GDPR/CCPA 等隱私法規。

• 詐欺：競爭對手或惡意行為者可藉此窺探您的營運規模與客戶群。

此毒性組合由「缺乏安全控管」與「針對特定 API 端點的機器人自動化行為」構成。

成分	訊號	描述
機器人活動	機器人分數 < 30	來自單一用戶端特征碼的大量請求，遍歷不同的 ID。
異常	高基數的 tid 請求	一個訪客在很短的時間內存取成百上千個唯一資源 ID。
異常	穩定的回應大小	一致的 JSON 結構和檔案大小，表示每次猜測的 ID 都成功擷取了資料。
漏洞	缺少驗證訊號	請求完全缺乏 Session Cookie、Bearer 權杖或 Authorization 標頭。
設定錯誤	可預測的識別碼	tid 參數使用低熵、可預測的整數（如 1001、1002、1003）。

雖然查詢本身檢查了機器人分數與可預測識別碼，但高基數、穩定回應大小與缺少驗證等訊號是在符合查詢條件的流量樣本中測試的。

1. 強制實施驗證：立即針對受影響的端點要求有效的工作階段或 API 金鑰。不允許「匿名」存取任何包含個人識別資訊或商業機密的資料。

2. 實施授權（IDOR 檢查）：確保後端檢查已驗證的使用者是否真的有權限檢視其所請求的特定 tid。

3. 使用 UUID：將可預測的循序整數 ID 替換為長且隨機的字串（如 UUID），讓「猜測」識別碼的行為在計算上不可行。

4. 部署 API Shield：啟用 Cloudflare API Shield，搭配結構描述驗證（用於封鎖非預期輸入）和 BOLA 偵測。

我們發現攻擊者在 Web 路徑後附加 debug=true，用以揭露系統內部資訊。下方是一個可在 Cloudflare Log Explorer 中執行的查詢範本：

SELECT
  clientRequestHTTPHost,
  COUNT(rayId) AS request_count
FROM
  http_requests
WHERE
  timestamp >= '{{START_TIMESTAMP}}'
  AND timestamp < '{{END_TIMESTAMP}}'
  AND edgeResponseStatus = 200
  AND clientRequestQuery LIKE '%debug=false%'
  AND botScore < {{BOT_THRESHOLD}}
GROUP BY
  clientRequestHTTPHost
ORDER BY
  request_count DESC;

這雖然不會立即導致資料遭竊，但卻為攻擊者提供了您內部基礎架構的高解析度地圖。這類「偵察行為」會大幅提高後續攻擊的成功率，因為他們可以窺見：

• 隱藏資料欄位：原本不應對使用者顯示的敏感內部資訊。

• 技術堆疊詳細資料：特定的軟體版本和伺服器類型，使其能夠查找那些確切版本的已知漏洞。

• 邏輯提示：錯誤訊息或堆疊追蹤暴露了程式運作邏輯，有助於攻擊者找出可利用的弱點。

此毒性組合包含自動化探查與針對多主機與應用程式路徑的診斷旗標設定錯誤。

成分	訊號	描述
機器人活動	機器人分數 < 30	漏洞掃描程式活動
異常	回應大小增加	啟用 debug 旗標時，資料量明顯上升，表明有詳細資訊或堆疊追蹤洩漏。必要時可加入以下條件： 選取 AVG(edgeResponseBytes) AS avg_payload_size,  WHERE edgeResponseBytes > {{your baseline response size}}
異常	重複路徑探查	在各種不同的端點（例如 /api、/login、/search）進行快速連續的請求，專門測試相同的診斷觸發器。(必要時可加入以下條件： SELECT APPROX_DISTINCT(clientRequestPath) AS unique_endpoints_tested  HAVING  unique_endpoints_tested > 1
設定錯誤	允許偵錯參數	在正式環境的 URL 中，存在會改變應用程式行為的活躍「debug」、「test」或「dev」旗標。
漏洞	結構描述揭露	出現了僅供內部使用的 JSON 欄位，或「Firebase 風格」的 .json 資料傾印，揭露了底層的資料結構。

雖然查詢本身檢查了機器人分數與含有偵錯參數的路徑，但重複探查、回應大小與結構描述揭露等訊號是在符合查詢條件的流量樣本中測試的。

1. 在正式環境停用偵錯功能：確保在正式環境的部署設定中，所有「debug」或「development」環境變數都被嚴格設定為 false。

2. 在邊緣篩選參數：使用您的 WAF 或 API Gateway，在已知偵錯參數（例如 ?debug=、?test=、?trace=）到達您的應用程式伺服器之前，將其剔除。

3. 清理錯誤回應：設定您的 Web 伺服器（如 Nginx、Apache），使其顯示一般性的錯誤頁面，而不是詳細的堆疊追蹤或內部系統訊息。

4. 稽核 firebase/DB 規則： 如果您使用 Firebase 或類似的 NoSQL 資料庫，請確保透過嚴格的安全性規則限制對 /.json 路徑的存取，以防止公開使用者傾印整個結構描述或資料。

我們發現「健康檢查」與監控儀表板對整個網際網路可見。特別是像 /actuator/metrics 這類路徑，會回應任何人的請求。下方是一個可在 Cloudflare Log Explorer 中執行的查詢範本：

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
  AND edgeResponseStatus = 200
  AND clientRequestPath LIKE '%/actuator/metrics%' // an example
GROUP BY
  clientRequestHTTPHost
ORDER BY request_count DESC

為什麼這很嚴重？

雖然這些端點通常不會直接洩露客戶密碼，但它們為攻擊者策劃精密攻擊提供了一張高價值的「藍圖」。暴露會導致：

• 策略性時機選擇：攻擊者可以即時監控您的 CPU 和記憶體使用情況，以便在您的系統已經不堪重負的時候，準確地發起阻斷服務 (DoS) 攻擊。

• 基礎架構對應：這些記錄通常會顯示內部服務的名稱、相依項和版本號，幫助攻擊者找到已知漏洞並加以利用。

• 漏洞利用鏈結：關於執行緒數量與環境提示的資訊，可被用來繞過安全防護或在網路內部提升權限。

此毒性組合由「存取控制設定錯誤」與「針對特定資產/路徑的自動化偵察行為」構成，目標包括：/actuator/metrics、/actuator/prometheus 和 /health。

成分	訊號	描述
機器人活動	機器人分數 < 30	自動化掃描工具會系統地檢查特定路徑
異常	監控特徵碼	回應內文與已知格式（Prometheus、Micrometer 或 Spring Boot）相符，確認系統正在洩漏即時資料。
異常	HTTP 200 狀態	本應向公眾回傳 403 Forbidden 或 404 Not Found 的端點，卻成功進行了資料擷取。
設定錯誤	公開監控路徑	內部專用的端點（如 /actuator/*）被公開存取，這些端點旨在用於私人可觀測性。
漏洞	缺少驗證	這些端點無需工作階段權杖、API 金鑰或 IP 限制即可存取。

1. 透過 WAF 限制存取：立即建立防火牆規則，封鎖請求路徑包含 /actuator/ 或 /prometheus 的任何外部流量。

2. 繫結至 localhost：重新設定您的應用程式架構，以僅在 localhost (127.0.0.1) 或私人管理網路上為這些監控端點提供服務。

3. 強制執行基本驗證：如果必須透過 Web 存取這些網站，請確保透過強式驗證（至少採用複雜的基本驗證或 mTLS）對其進行保護。

4. 停用不必要的端點：在 Spring Boot 或類似的架構中，停用生產監控非嚴格要求的所有「Actuator」功能。

原本應供內部使用的搜尋端點（如 Elasticsearch 或 OpenSearch）對公眾完全開放。範本化查詢為：

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
  AND edgeResponseStatus = 200
AND clientRequestPath like '%/\_search%'
AND NOT match(extract(clientRequestHTTPHost, '^[^:/]+'), '^\\d{1,3}(\\.\\d{1,3}){3}(:\\d+)?$')
GROUP BY
  clientRequestHTTPHost

這是一項極為嚴重的漏洞，因為攻擊者無需任何技術能力即可利用，但造成的損害卻極為廣泛：

• 大量資料竊盜：攻擊者可以「傾印」整個索引，在幾分鐘內竊取數百萬筆記錄。

• 內部偵察：透過檢視您的「索引」（您儲存的內容清單），攻擊者可以識別您的網路中的其他高價值目標。

• 資料蓄意破壞：根據設定，攻擊者可能不僅會讀取資料，還可能修改或刪除您的整個搜尋索引，從而導致大規模服務中斷。

我們觀察到一組毒性組合，包含設定錯誤的暴露行為與針對 /search、/cat/indices、/_cluster/health 等路徑的自動化流量與資料列舉。

成分	訊號	描述
機器人活動	機器人分數 < 30	高速自動化特征碼，嘗試對大型資料集進行分頁並「爬取」整個索引。
異常	非預期的回應大小	JSON 回應檔案異常龐大，與簡單狀態檢查不符，而與大量資料擷取相符。
異常	重複查詢模式	系統性地「列舉」行為，攻擊者逐一嘗試所有可能的索引名稱以尋找敏感資料。
漏洞	/_search 或 /_cat/ 模式	直接暴露了不應透過公用 URL 存取的管理級和查詢級路徑。
設定錯誤	HTTP 200 狀態	端點主動回應來自未經授權的外部 IP 的請求，而不是在網路或應用程式層拒絕這些請求。

雖然查詢本身檢查了機器人分數與路徑，但重複查詢模式、回應大小與結構描述揭露等訊號是在符合查詢條件的流量樣本中測試的。

1. 限制網路存取：立即更新您的防火牆/網路安全群組，以確保只能從特定內部 IP 位址存取搜尋連接埠（如 9200、9300）和路徑。

2. 啟用驗證：為搜尋叢集啟用「安全性」功能（例如 Shield 或 Search Guard），要求每次 API 呼叫都提供有效的認證。

3. WAF 封鎖：部署 WAF 規則，以立即封鎖來自公用網際網路的任何包含 /_search、/_cat 或 /_cluster 的請求。

4. 稽核資料丟失：檢查資料庫記錄，尋找來自未知 IP 的大型「Scroll」或「Search」查詢，以確定究竟有多少資料外洩。

我們發現攻擊者傳送了惡意請求，具體來說，是旨在欺騙資料庫的 SQL 資料隱碼攻擊。下方是一個可在 Cloudflare Log Explorer 中執行的查詢範本：

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
AND wafmlScore<30
  AND edgeResponseStatus = 200
AND LOWER(clientRequestQuery) LIKE '%sleep(%'
GROUP BY
  clientRequestHTTPHost
ORDER BY request_count DESC

這是導致資料外洩的「靜默路徑」。由於系統回傳了成功狀態碼 (HTTP 200)，這類攻擊往往會與合法流量混雜在一起。若未及時處理，攻擊者可以：

• 改進攻擊方法：透過反覆嘗試，找到能夠繞過您篩選機制的精確惡意負載。

• 竊取資料：緩慢地榨取資料庫內容，或洩露在 URL 中傳遞的敏感機密（例如 API 金鑰）。

• 保持隱蔽：大多數自動化警示會尋找「被拒絕」的嘗試；而一次「成功」的攻擊在龐大記錄中極難被察覺。

我們觀察到一組毒性組合，包含自動化機器人訊號、異常行為與應用程式層漏洞，針對多個應用路徑發動攻擊。

成分	訊號	描述
機器人	機器人分數 < 30	高機率為自動化流量，其特徵與時間間隔符合攻擊指令碼行為模式。
異常	敏感路徑回傳 HTTP 200	本應觸發 WAF 封鎖的登入端點，卻回傳了成功的回應。
異常	重複的變異	相同請求的高頻率變化，表示攻擊者在「調整」他們的惡意負載。
漏洞	可疑的查詢模式	使用 SLEEP 指令和基於時間的模式，旨在探查資料庫的反應能力。

1. 立即進行虛擬修補：更新您的 WAF 規則，專門封鎖已識別的 SQL 模式（例如，基於時間的探查）。

2. 清理輸入內容：審查此路徑的後端程式碼，確保使用了預處理語句或參數化查詢。

3. 補救機密洩露：將任何敏感資料從 URL 參數移至請求內文或標頭中。輪換任何被標記為已洩露的金鑰。

4. 稽核記錄：檢查「HTTP 200」回應發生時間範圍內的資料庫記錄，以確認是否有任何資料被成功擷取。

信用卡測刷和信用卡盜刷是最常見的詐騙手法。攻擊者可能從暗網購買大批信用卡。接著，為了驗證有多少張卡仍有效，他們可能會在網站上透過進行小額交易來測試這些卡。一旦驗證成功，他們便可能使用這些卡片在熱門購物網站上進行消費，例如購買禮品卡。

在支付相關路徑（如 /payment、/checkout、/cart）中，我們發現某些時段的每小時機器人請求量或支付成功率，相較於過去 30 天的每小時基準線，出現超過 3 個標準差的異常波動。這可能代表攻擊者正利用自動化指令碼大量測試盜刷被盜的信用卡。當然，行銷活動也可能造成請求量激增，而支付系統中斷則可能導致成功率驟降，需一併考慮。

在沒有行銷活動、支付服務中斷或其他因素的情況下，支付成功率下降的同時伴隨著請求量激增，可能意味著機器人正在進行大規模的信用卡測刷行動。

我們結合了機器人訊號以及 /payment、/checkout、/cart 路徑上的異常行為來進行分析：

成分	訊號	描述
機器人	機器人分數 < 30	高機率為自動化流量，而非人為操作失誤
異常	流量 Z 值 > 3.0，該值根據特定小時在過去 30 天的請求量基準線計算得出，並每小時評估一次。此計算也考慮了每日的季節性變化。	規模化事件：攻擊者正在測試一批信用卡
異常	成功率 Z 值 > 3.0，該值根據特定小時在過去 30 天的成功率基準線計算得出，並每小時評估一次。此計算也考慮了每日的季節性變化。	成功率的突然下降可能意味著卡片因被通報遺失或被盜而遭到拒絕

使用過去 30 天支付路徑的每小時請求量基準值，作為支付路徑上所有機器人分數 < 30 的請求的每小時速率限制。

在支付流程路徑（如 /payment、/checkout、/cart）上，我們發現某些特定時段，來自真人（或偽裝成真人的機器人）的每小時請求量，或是每小時支付成功率，相較於過去 30 天的每小時基準線，出現了超過 3 個標準差的異常波動。這可能與信用卡盜刷有關，即攻擊者（無論是真人還是偽裝成真人的機器人）正使用有效但盜來的信用卡進行高頻次購物，以迅速耗盡其可用額度。當然，行銷活動也可能導致請求量和成功率同步上升，因此需結合特定 IP 的典型支付行為作為額外判斷依據，如圖所示。

在沒有行銷活動、支付服務中斷或其他因素的情況下，支付成功率飆升的同時伴隨著請求量激增和每個 IP 位址的高請求密度，可能意味著真人（或偽裝成真人的機器人）正在進行欺詐性購買。每一次成功的交易都可能直接造成收益損失，或未來衍生退單風險。

我們結合了機器人訊號以及 /payment、/checkout、/cart 路徑上的異常行為來進行分析：

成分	訊號	描述
機器人	機器人分數 >= 30	高機率為真人流量，照理應被允許
異常	流量 Z 值 > 3.0，該值根據特定小時在過去 30 天的請求量基準線計算得出，並每小時評估一次。此計算也考慮了每日的季節性變化。	攻擊者以高於一般購物者的速度購物
異常	成功率 Z 值 > 3.0，該值根據特定小時在過去 30 天的成功率基準線計算得出，並每小時評估一次。此計算也考慮了每日的季節性變化。	成功率驟升可能表示有效卡被核准購買
異常	IP 密度 > 5，計算方式為特定小時內每個 IP 的支付請求數，除以該小時在過去 30 天的平均支付請求數	真人的購買量是過去 30 天典型真人的 5 倍以上，這是一個危險訊號
異常	JA4 多樣性 < 0.1，計算方式為特定小時內每個支付請求的 JA4 指紋	在特定小時內進行異常大量購買的 JA4 指紋，很可能是偽裝成真人的機器人

基於身分的限速：使用 IP 密度，對支付端點上機器人分數 >= 30 的請求實施速率限制。

監控成功率：若機器人分數 ≥ 30 的「人類」流量在支付端點的成功率，偏離過去 30 天同時段基準值超過 3 個標準差，即觸發警示。

挑戰：如果一個高機器人分數的請求（可能是真人）在 10 分鐘內對支付流程的存取超過 3 次，則觸發一個挑戰來減緩其速度

我們目前正在將這些「毒性組合」偵測功能直接整合至 Security Insights 儀表板，讓您能即時察覺此類風險。未來的發展藍圖中，我們也計劃加入 AI 輔助的修復指引，讓儀表板不僅能呈現偵測到的毒性組合，還能自動建議可立即部署的 WAF 規則或 API Shield 設定，協助您迅速消除威脅。

我們誠摯邀請您試用內含毒性組合偵測功能的 Security Insights。您可以在此加入等候名單。