祇限 pull request 新增或變更 API 端點會改變 API 的攻擊面。大多數 API 安全工具只有在端點上線並開始接收流量後才會發現問題。到那時,修復不再是程式碼審查中一行程式碼的修改就能解決的問題,而是需要進行事件回應討論。
API 安全是指發現並消除應用程式公開其端點時存在的風險:誰可以呼叫它們,它們會傳回什麼數據,以及它們是否按照文件所述執行操作。
目前針對此問題開發的大多數工具都是在運行時從外部測試 API,就像攻擊者一樣。這種方法雖然有效,但前提是 API 已經部署完畢。 Xygeni 它會走較早的路徑:在發出任何請求之前,它會讀取你的原始碼和 API 規格。
測試 API 的四種方法,以及每種方法回答的問題
大多數成熟的程式都會運行其中不只一項:
- 靜態測試 它會在部署前分析原始程式碼和 API 規範,回答「我們剛剛暴露了什麼?」這個問題。本文將重點放在這種方法。
- 動態測試(DAST) 向正在運行的 API 發送真實流量並觀察其回應。它回答了「目前哪些內容是實際可訪問和可利用的?」這個問題。
- 起毛 它會向端點拋出格式錯誤或意外的輸入,以暴露崩潰和極端情況下的故障。它回答了「在未預料到的輸入下,哪些程式會崩潰?」這個問題。
- 手動滲透測試 它透過引入人工判斷來發現自動化工具遺漏的邏輯缺陷。它回答了「一個聰明的攻擊者會如何將各種邏輯漏洞串聯起來?」這個問題。
這些方法彼此並不取代。它們在生命週期的不同階段回答不同的問題,而大多數專案存在的缺點在於第一階段。
為什麼大多數 API 安全工具發現風險為時已晚
執行時間 API 安全測試會向執行中的應用程式發送流量並觀察其回應。這是一個合法且必要的安全層。但從本質上講,它也是一種滯後指標:只有當端點存在、已部署且可存取時,執行時間掃描器才能對其發出任何警報。掃描器發現的任何安全漏洞,在掃描運行期間都已經暴露在外。
除了上述時序問題之外,還有第二個缺陷。運行時工具只能測試已知存在的內容。如果某個端點從未被記錄,或者 OpenAPI 規範在新路由發布後立即過時,運行時掃描器就無法得知它的存在。它測試的是地圖,而不是實際的路徑。
靜態 API 安全性測試透過將檢查移至定義端點的位置(即部署前的程式碼和 API 規格)來彌補這兩個漏洞。 pull request 引入終點的是 pull request 這會暴露出其風險。
靜態API安全性的真正意義
Xygeni 從兩個來源建立您的 API 清單:您的應用程式原始碼和您的 API 規範,包括 OpenAPI 和 Swagger。
僅包含規範的清單顯示了有人記得記錄的介面。僅包含程式碼的清單顯示了已存在的功能,但不一定顯示了它們的預期用途。同時閱讀這兩份清單以獲得完整的概覽:包括團隊記錄的接口,以及無人記錄的接口。
庫存是其他一切的基礎:
- 已發現的 API 總數以及與基線相比有風險的資產
- 按 HTTP 方法細分的端點
- 按服務分組的問題
- 每個端點及其方法、路徑、服務、模組、身份驗證狀態和風險評分
您的工程主管無需提交任何工單即可了解您的 API 架構。
Xygeni 找到的每個端點,包括其方法、身份驗證狀態和風險評分,都是根據代碼和規範共同建構的。
Production note 從任何 API 安全螢幕截圖中裁切 AI 分診面板。
已對應到 OWASP API 安全 Top 10
調查結果與您的安全團隊和審計人員已使用的框架相符。 Xygeni 可偵測 OWASP API 安全性方面的風險。 前 10 名(2023):
| OWASP | 風險 | 實際意義 |
|---|---|---|
API1 | 損壞的對象級別授權 | 端點傳回或修改屬於其他使用者或租用戶的數據 |
API2 | 未經認證的端點 | 無需任何身份驗證即可到達某條路由 |
API3 | 過度資料外洩 | 回應傳回的欄位比呼叫者需要或應該看到的要多。 |
API3 | 大量分配 | 一個端點接受並應用了它原本不應該接受的字段。 |
API3 / API10 | 回覆中包含敏感數據 | PII、PCI 或 PHI 從不應該發送它們的端點到達客戶端。 |
API4 | 缺少速率限制 | 端點沒有針對濫用或暴力破解呼叫的保護措施 |
API5 | 功能等級授權故障 | 端點執行特權操作時,未檢查呼叫者是否具有該權限。 |
API7 | SSRF | 攻擊者可以誘騙 API 代表其發出請求。 |
API8 | JWT配置錯誤 | 令牌驗證、簽名或過期設定不正確 |
API8 | CORS配置錯誤 | 跨域規則過於寬鬆,容易被利用。 |
API9 | 殭屍和孤兒端點 | 已棄用或已被遺忘但仍可存取的路由,以及無人擁有的路由。 |
有一個類別被刻意忽略了。 API6,即“對敏感業務流程的無限制存取”,需要理解業務流程應該允許什麼,而任何靜態分析器都無法可靠地檢測到這一點。任何聲稱可以做到這一點的供應商,都只是在兜售一個複選框而已。這個複選框應該由你的威脅建模人員和滲透測試人員來處理。
並非所有發現都同等重要:數據敏感性和毒性組合
如果將未經驗證的健康檢查端點與傳回客戶記錄的未經驗證的端點視為同一類別問題,那麼列表式的檢查結果實際上並不相同。如果優先級模型對它們採用相同的評分標準,就會讓團隊養成忽略該清單的習慣。
Xygeni 對每個端點處理的資料進行分類,在請求參數和回應中標記 PII、PCI 和 PHI,並將其與端點的身份驗證狀態配對。
它還會關聯出現在同一端點上的發現,並在發現多個此類問題時提高嚴重程度。回應中的個人識別資訊外洩本身就是一個嚴重的問題。同樣,在無需身份驗證的端點上發生的洩漏則更為嚴重,平台會根據具體情況進行評分,而不是讓用戶手動發現連線問題。
殭屍端點與孤兒端點:程式碼與規範之間的鴻溝
由於 Xygeni 會並排讀取您的程式碼和 API 規範,因此它可以發現它們之間的差異。這種差異會以三種可辨識的模式表現出來:
- 未記錄的端點。 它們存在於程式碼中,從未被加入到規範中。
- 殭屍終點站。 它們被標記為已棄用或已停用,但仍然可以存取。
- 孤立端點。 目前球隊中沒有人擁有這些球衣。
這些都不會出現在僅包含規格的清單中,因為規格本身就缺少它們。
您可以採取行動的證據,而不是需要調查的罰單
每項發現都指向負責的特定處理程序:文件、類別、方法以及引入缺陷的具體程式碼行,並附有相應的錯誤代碼。每項發現還包含其嚴重程度、OWASP API 安全 Top 10 類別、CWE 編號、端點的身份驗證狀態以及所涉及資料的敏感度分類。
如果只是指出某個端點,開發人員就得在程式碼庫中苦苦搜尋才能開始修復。如果直接指出是哪一行程式碼,他們就能立即找到修復方案。
研究結果以 JSON、CSV、Markdown 和 SARIF 2.1.0 格式匯出,因此它們會保存在 t 目錄中。團隊已經在使用的工具。
處理程序、行號以及引入漏洞的程式碼。無需提交工單進行調查。
為什麼它只存在於一個平台,而不是另一個主機平台?
Xygeni 同時運行 API 安全 SAST, SCA, 機密安全, IaC 以及 達斯特 在單一平台內,透過以下方式關聯 ASPM而不是將其作為單獨的工具發布。 login 以及它自身的積壓工作。
這一點很重要,因為靜態檢測結果和運行時檢測結果針對的是同一個端點的不同問題,而且它們結合起來比單獨使用更有用。靜態偵測結果會在端點上線前就指出其風險。而運行時安全測試 (DAST) 則會在端點運行後確認其實際可存取性和可利用性。
將相關風險分散到兩個控制台,就變成了兩個不相關的待辦事項。沒有人會協調它們,而那個既沒有文件記錄又未經身份驗證的端點,既不在任何一個待辦事項清單中。
查看您真實的 API 攻擊面。 API 安全性可作為一項功能提供。 Enterprise Xygeni 平台的一個附加元件,會對您自己的基礎架構內的您自己的儲存庫進行掃描。
常見問題
它能否識別哪些端點處理敏感資料?
是的。 Xygeni 會在終點參數和反應中標記 PII、PCI 和 PHI,並使用該分類按實際暴露情況對結果進行排序。
它能在所有設備上運作嗎? pull request?
是的。增量掃描僅分析已變更的端點,並且它產生的清單可以將後續的 DAST 掃描集中在這些相同的端點上,因此靜態和執行時間測試與實際變更的內容保持一致。
我的程式碼會離開我的環境嗎?
不。掃描在您自己的基礎架構上運作。只有結果會被上傳,並在傳輸和儲存過程中受到保護。
如何獲得 API 安全性?
API 安全性可作為一項功能提供。 Enterprise 附加組件。請申請概念驗證,我們會與您共同確定範圍。





