今天，我們推出了適用於 API 的 Cloudflare 序列分析。透過序列分析，訂閱 API Gateway 的客戶就能夠檢視對其端點最重要的 API 呼叫序列。這項新功能可協助客戶將保護功能優先套用至最重要的端點。
什麼是序列？簡單地說，序列就是特定訪客在瀏覽網站、使用行動應用程式或透過 API 與 B2B 合作夥伴互動時所發出之 HTTP API 請求的時間順序清單。例如，在銀行資金轉帳期間所執行之序列的一部分可能如下所示：
| 順序 | 方式 | 路徑 | 描述 |
|---|---|---|---|
| 1 | GET | /api/v1/users/{user_id}/accounts | user_id 是活躍使用者 |
| 2 | GET | /api/v1/accounts/{account_id}/balance | account_id 是其中一個使用者帳戶 |
| 3 | GET | /api/v1/accounts/{account_id}/balance | account_id 是屬於使用者的不同帳戶 |
| 4 | POST | /api/v1/transferFunds | 包含一個請求正文，其中詳細說明了要從中轉移資金的帳戶、要向其轉移資金的帳戶以及要轉移的金額 |
為什麼關注 API 安全性的序列很重要？如果上述 API 在收到 POST /api/v1/transferFunds 請求之前未收到前面的任何請求，則會很可疑。想一想：API 用戶端如何在不列出使用者的相關帳戶 ID 情況下得知相關資訊？API 用戶端如何得知有多少資金可供轉帳？雖然此範例可能很明顯，但對任何特定生產性 API 的海量 API 請求可能使分析人員難以發現可疑的使用情況。
在安全方面，防禦無法由人類團隊篩選之海量威脅的其中一種方法是建立正面安全性模型。依預設，您將允許所有已知的安全或良性流量並阻止其他所有流量，而不是嘗試阻止所有可能構成威脅的內容。
客戶可能已經在兩個主要領域使用 API 閘道建立正面安全性模型： 大規模濫用防護和結構描述驗證。序列將構成 API 流量正面安全性模型的第三個支柱。API 閘道將能夠在任何指定 API 序列中強制實施端點的優先順序。透過在 API 序列中建立優先順序，API 閘道將記錄或阻止任何不符合預期的流量，從而減少濫用流量。
依序列偵測濫用
當攻擊者試圖以濫用方式使資料外流時，很少會遵循預期的 API 流量模式。攻擊通常使用特殊軟體來「模糊」API，傳送具有不同請求參數的多個請求，以期從 API 中找到指示資料外流機會的意外回應。攻擊者還可以手動傳送請求至 API，試圖誘騙 API 執行未經授權的動作，例如透過損壞的物件層級驗證 (Broken Object Level Authentication) 攻擊授予攻擊者更高的權限或資料存取權。利用速率限制保護 API 是一種常見的最佳做法；但是，在上述兩個範例中，攻擊者可能會故意緩慢執行請求序列，以試圖阻止大規模濫用偵測。
再次考慮上面的請求序列，但這次假設攻擊者複製合法的資金轉帳請求並修改請求有效負載以試圖欺騙系統：
| 順序 | 方式 | 路徑 | 描述 |
|---|---|---|---|
| 1 | GET | /api/v1/users/{user_id}/accounts | user_id 是活躍使用者 |
| 2 | GET | /api/v1/accounts/{account_id}/balance | account_id 是其中一個使用者帳戶 |
| 3 | GET | /api/v1/accounts/{account_id}/balance | account_id 是屬於使用者的不同帳戶 |
| 4 | POST | /api/v1/transferFunds | 包含一個請求正文，其中詳細說明了要從中轉移資金的帳戶、要向其轉移資金的帳戶以及要轉移的金額 |
| … 攻擊者將請求複製到偵錯工具，如 Postman … | |||
| 5 | POST | /api/v1/transferFunds | 攻擊者修改了 POST 正文以試圖欺騙 API |
| 6 | POST | /api/v1/transferFunds | 進一步修改 POST 正文以試圖欺騙 API |
| 7 | POST | /api/v1/transferFunds | 又進一步修改了 POST 正文以試圖欺騙 API |
如果客戶事先知道資金轉帳端點對於保護至關重要，並且在一個序列中只會發生一次，他們就可以編寫規則來確保永遠不會連續呼叫兩次，並且 GET /balance 一律優先於 POST /transferFunds。但是，如果事先不知道哪些端點序列對於保護至關重要， 客戶如何才能知道要定義哪些規則？低速率限制風險太大，因為 API 使用者可能會合法地在短時間內執行多個資金轉帳請求。在現實中，能夠防止此類濫用的工具很少，大多數客戶在濫用發生後只能被動地與應用程式團隊和防欺詐部門一起清理濫用行為。
最終，我們認為，要讓客戶能夠定義關於 API 請求序列的正面安全性模型，需要採取三管齊下的方法：
- 序列分析：判定 API 請求的哪些序列發生以及何時發生，並將資料匯總為易於理解的表單。
- 序列濫用偵測：判定哪些 API 請求序列可能是良性或惡意來源。
- 序列緩解：判定有關 API 請求序列的相關規則，以決定允許或阻止哪些流量。
建立序列時可能遇到的挑戰
序列分析帶來了一些比較難以解決的技術挑戰，因為工作階段可能存留很長時間，並且可能包含很多請求。因此，僅透過工作階段識別碼來定義序列還不夠。因此，我們有必要開發一種能夠自動識別特定工作階段中發生的多個序列的解決方案。此外，由於重要序列不一定僅以容量為特性，並且可能的序列集會很大，因此有必要開發一種能夠識別重要序列的解決方案，而不是簡單地呈現頻繁執行的序列。
為了幫助使用 api.cloudflare.com 範例說明這些挑戰，我們可以按工作階段對 API 請求進行分組，並標繪出不同序列的數量與序列長度的關係：
我們將基於一個小時的快照進行標繪，其中包含大約 88,000 個工作階段和 2.6 億個 API 請求，具有 301 個不同的 API 端點。我們對每個工作階段套用固定長度的滑動視窗，然後計算由於套用滑動視窗而觀察到之不同固定長度序列的總數（「n-grams」），以此來處理資料。繪圖中將顯示視窗大小（「n-gram length」）在 1 到 10 個請求之間變化的結果。不同序列範圍的的數量從 301（1 個請求的視窗大小）到約 780,000（10 請求的視窗大小）。根據繪圖，我們觀察到大量可能的序列，這些序列隨著序列長度的增大而成長：隨著滑動視窗大小的增加，我們看到範例中有越來越多的不同序列。平滑趨勢可以由以下事實來解釋：我們套用了滑動視窗（工作階段本身可能包含許多序列）並與相對於序列長度的大量長工作階段相結合。
鑑於可能的序列數量眾多，嘗試找到濫用序列簡直就是「大海撈針」。
序列分析簡介
下面是 API 閘道儀表板的螢幕截圖，其中突出顯示了序列分析：
讓我們來詳細了解螢幕截圖中看到的新功能。
API 閘道使用前文所述的方法智慧地判定 API 使用者發出的請求序列。API 閘道按照我們稱為相關性分數的指標對序列進行評分。序列分析按最高相關性分數顯示前 20 個序列，我們將這些序列稱為最重要的序列。高重要性序列包含可能按順序一起發生的 API 請求。
您應該檢查每個序列以了解序列的相關性分數。相關性分數較高的序列可能包含很少使用的端點（潛在的異常使用者行為）以及常用的端點（可能是良性使用者行為）。由於在這些序列中找到的端點通常一起出現，因此可以代表 API 的真實使用模式。您應將所有可能的 API 閘道保護措施套用於這些端點（速率限制建議、結構描述驗證、JWT 驗證和 mTLS），並與開發團隊一起檢查特定的端點順序。
我們知道，客戶希望在現今 API 閘道提供的主動保護之外，對其 API 明確地設定允許的行為。我們即將發佈序列優先順序規則，並實現基於這些規則阻止請求的功能。新的序列優先順序規則將允許客戶為允許的 API 請求指定確切順序，從而提供另一種建立正面安全性模型的方法，以保護您的 API 免遭未知威脅。
如何開始使用
所有 API Gateway 客戶現在都可以存取序列分析。導覽到 Cloudflare 儀表板中的區域，然後按一下「安全性」索引標籤 >「API 閘道」索引標籤 >「序列」索引標籤。您將看到 API 使用者請求的最重要序列。
尚未購買 API 閘道的企業客戶可以在 Cloudflare 儀表板中啟用 API 閘道試用版或聯絡客戶經理以開始使用。
下一步驟
基於序列的偵測是一項強大而獨特的功能，可解鎖大量識別和阻止攻擊的新機會。隨著我們調整了識別這些序列並將其部署到全球網路的方法，我們將在未來推出自訂序列匹配和即時緩解功能。我們還將確保您擁有可執行的情報，以便向您的團隊報告試圖請求與原則不相符之序列的 API 使用者。