API 自動化測試 - API 生態的除蟲者

根據 OWASP 組織公布常見的 API 安全漏洞描述，可以得知目前常見的安全測試，如網頁弱點掃描 ( 黑箱 )、 源碼檢測 ( 白箱 ) 是無法掃出 API 的商業邏輯漏洞以及模擬駭客在營運環境的攻擊方式。我們需要一種專屬 API 的自動化測試，來幫我們找出 API 的邏輯漏洞， 而不是任由駭客竊取非授權的客戶資料。

什麼是API商業邏輯漏洞？

我們用捷運的驗票閘門來舉例，在測試環境打造出閘門後，透過一系列安全測試來驗證其功能性與安全性。首先，檢查一些過往已知的安全漏洞，例如：閘門所使用的材料是否安全、裡面的機械零件是否沒有生鏽、電路與電壓是否符合法規的要求……等。接著，測試人員在刷卡進站的過程中，是否有出現例外狀況，例如：票卡無法正常扣款、閘門關閉的速度不符合手冊所描述、閘門用腳一踢就開了……等。

那商業邏輯漏洞就是，能否在不刷卡的情況下成功進站。先拉開與閘門的距離準備助跑，開跑後在靠近閘門三步的距離時，奮力一跳成功越過閘門。在這情況下，不需要破壞閘門或偷取捷運員工證，就能免費進站搭捷運。

若將上述例子搬到 API 的情形，最鮮為人知的就是全國繳費網的案例。有使用者發現，可以使用他人的帳戶來幫自己繳帳單，而在這情境下，使用者只需得知被害者的帳戶號碼就能繳費成功，且被害者不會收到任何轉帳通知。

現有的各種安全測試

網頁弱掃 ( 黑箱測試 )

測試人員將系統視為黑盒子，根據暴露的輸入與輸出，來評估系統或應用程式的安全性。透過實際測試系統來發現潛在的已知安全漏洞和弱點，例如： CVE、CWE，以確保系統能夠抵禦未授權的存取或攻擊。但是對於未知的攻擊行為，無法在第一時間偵測出來。

源碼檢測 ( 白箱測試 )

透過檢查程式碼、文檔或設計來評估系統或應用程式的安全性。測試人員會仔細檢查程式碼，以確保沒有安全漏洞或弱點存在。這種測試方法通常涉及靜態代碼分析、安全代碼審查等。但是誤報率高且無法模擬出駭客的攻擊行為。

滲透測試

模擬真實攻擊的測試方法，旨在評估系統、網路或應用程式的安全性。測試人員會以攻擊者的身份，使用各種工具和技術來尋找系統中的弱點，並試圖進行未授權的存取、數據竊取、系統破壞等行為。不過每一支 API 就像一塊拼圖，需要蒐集知識與了解這塊拼圖的目的以及跟哪些拼圖有關聯，但在時間壓力下，最終只能單獨測試拼圖的安全性而非找出會洩漏客戶資訊的拼法。

紅隊藍隊演練

評估組織的整體安全性和應急響應能力。紅隊是由資安專家扮演攻擊者的角色進行攻擊，試圖進入組織的系統、網路或設施，並盡可能地取得敏感資料，最喜歡利用的是資產管理系統這類管理許多用戶端的平台，其次就是每個員工都會使用到的重要平台，直接把後台資料庫的資料全偷出來。藍隊是組織的內部安全團隊，他們會模擬攻擊情境，試圖檢測和阻止紅隊的攻擊，並恢復受影響的系統或應用程式。

API 自動化測試

專注於 API 的自動化測試需要包含哪些條件：

OWASP 測試腳本

基於 OWASP TOP 10 API，涉及模擬駭客的攻擊以檢測 API 中的業務邏輯漏洞。

驗證測試

匯入 API 文檔，在測試的過程中確保 API 以正確的格式傳回預期結果。驗證測試涉及檢查輸入參數、輸出格式、回應代碼和資料類型是否正確。

功能測試

驗證 API 功能是否正確並符合所需的規格。此類測試可以包括測試 API 的業務邏輯、輸入驗證、輸出驗證和錯誤處理。

安全測試

旨在識別 API 中與安全相關的漏洞和缺陷，並確保 API 符合所需的安全標準。此類測試包括 SQL 注入、跨站腳本(XSS)、 跨站請求偽造 (CSRF) 等漏洞測試。

模糊測試

涉及向 API 提供意外和無效的輸入，以測試其處理意外輸入和從錯誤中恢復的能力。此類測試可以發現 API 中的安全漏洞或意外行為。 沒有發現並解決 API 商業邏輯漏洞，最嚴重的後果就是資料外洩。如果攻擊者獲得 API 的存取權限，他們能夠竊取或修改敏感數據，甚至破壞，導致服務中斷或停機。

Noname Security - 完整且主動的API 安全平台

Noname Security 是業界唯一一家對 API 安全採取全面且主動做法的公司。 Noname 與 20% 的財星全球 500 大企業合作，涵蓋整個 API 安全範圍的三大支柱——狀態管理、Runtime 安全與 API SDLC 安全。