解析 OWASP API Security Top 10

由於威脅範圍不斷擴大，加上業界對 API 的使用與日俱增，因此 OWASP API Security Top 10 Project 應運而生。這個計畫希望幫助組織、開發人員和資安團隊更了解 API 相關的風險。在 2019 年 9 月，OWASP API Security Top 10 最終測試版本已在 OWASP 官網上發佈。

重點介紹攻擊情境來闡明風險，幫助組織和最終使用者了解 API 實作不足的相關危險。此處將依照 OWASP API Security Top 10 中的弱點依序進行討論。

API1：2019-Broken Object Level Authorization (不安全的物件授權)

攻擊者可透過操作客戶端發送的 Object ID request，進而利用不安全授權的 API。這表示客戶端可以從 API 存取不該存取的資訊。這種攻擊通常會導致未授權的資訊洩露、資料被竄改或破壞。

攻擊情境範例

假設有一個電子商務平台，提供財務和託管服務給各式各樣的線上商店 (商家)。平台提供 API 來存取每間託管商店的收益圖表，而每間商店都只能存取自己的收益圖表。每次商店在查詢資料時會利用識別碼進行查詢，攻擊者便可利用這資料識別各家所使用之 URL，例如： /shops/{shop name}/revenue_data.json。攻擊者只要使用電子商務平台上託管的其他商店名稱，建立一個簡單的 script 來修改{shop name} 這個 ID 執行後續請求，就能任意存取其他商店的收益圖表。

API2：2019-Broken Authentication (無效身份認證)

與上述所討論的授權不同，身分認證在 API 中 是另一個相對複雜且混亂的機制。由於在設計上，身份認證端點是向所有人公開的，因此使用者身份認證的端點必須與一般 API 端點有所區別。除了暴力破解法和猜測 token 攻擊之外，還應針對帳密填充 (Credential Stuffing) 攻擊進行額外保護。

攻擊情境範例

假設因其他組織資料外洩，攻擊者獲得洩露的使用者帳號/密碼組合列表。如果 API 端點在處理身份認證時，未針對暴力破解法或帳密填充攻擊法進行保護，例如：CAPTCHA、速度限制、帳號鎖定等，則攻擊者可以運用使用者帳號/密碼組合列表反覆嘗試來取得權限， 就可以判定出正確的組合。

API3：2019-Excessive Data Exposure (資料暴露不當)

由於設計原因，API 端點經常會暴露機敏資訊，因為它們經常依賴客戶端應用程式執行資料過濾。攻擊者可以透過網路監聽流量對 response 進行分析，來尋找不應公開的敏感資料。資料應先在後端應用程式上進行過濾，再傳遞給使用者。

攻擊情境範例

思考一下，物聯網攝影機監視系統允許管理員添加新進的保全人員為系統使用者，且管理員希望確保新使用者僅能存取特定攝影機。保全人員在工作時可用行動應用程式存取攝影機。行動應用程式向終端發出 API 請求接收攝影機的相關資訊，並仰賴行動應用程式來過濾保全人員可以存取的攝影機。儘管行動應用程式只顯示保全人員可以存取的攝影機，但實際的 API 回應包含「所有的」 攝影機。攻擊者可以利用網路監聽來略過行動應用程式的過濾與限制，操作 API 請求顯示所有攝影機。

API4：2019-Lack of Resources & Rate Limiting (缺乏資源與速率限制)

API 常設計用來供查詢回傳資料，但往往未對 API 請求數量進行任何速率或資源的限制，可能導致消耗大量網路、CPU、記憶體和儲存空間。一般來說使用者輸入和業務邏輯決定 了請求所需的資源量。攻擊者利用這些問題造成阻斷服務攻擊 (DoS) 和相關端點中斷。

攻擊情境範例

假設攻擊者想對有大量使用者的特定 API 進行阻斷服務攻擊。攻擊者可以查詢使用者列 表，但是應用程式會限制使用者顯示數量 為 100 個。該程式的正常請求如下所示：/ api/users?page=1&size=100。在這種情況下， 該請求會和前 100 個使用者一起返回首頁。 如果攻擊者將 size 這個參數從 100 更改為 200,000，會因為目前的參數太大，導致後端資料庫效能出現問題。因此，API 就會變得毫無反應，且無法處理來自客戶端或其他客戶端的額外請求。

API5：2019-Broken Function Level Authorization (無效功能權限控管)

儘管與上述的 API1 不同，在這邊攻擊者需要將 API 請求發送到他們不應該存取，但暴露給匿名使用者或沒有權限的一般使用者的端點。攻擊者很容易能發現此類型的漏洞，且可以存取未經授權的功能。例如：管理功能是此類型攻擊的主要目標。

攻擊情境範例

假設某個應用程式僅允許受邀使用者加入。 在註冊時，行動應用程式觸發了對 GET/api/invites/{invite_guid}的 API 請求。GET 是一個標準 HTTP method，用於向特定資源請求資訊。在這種情況下，GET 的 response 涵蓋了 invite 相關的詳細資訊，包括使用者的角色和電子郵件地址。

現在，假設攻擊者複製請求，並將 GET 更改為 POST 來操縱 HTTP 方法。POST 是一種用於發送資訊以建立或更新資源 的 HTTP 方法。URL 如下：POST/api/ invites/new/{“email”：”hugo@malicious. com”,”role”：”admin”}。 在這種情況下， 攻擊者可以輕鬆利用此漏洞，發送電子郵件邀請自己建立管理員帳號。

API6：2019-Mass Assignment (批量配置不當)

現代的網頁程式框架支援自動將使用者輸入內容與 Function Object 的內部變數綁定在一起的功能，一般來說使用者應該能夠更新他的名稱、聯絡資料等 (例如個人資料) 但他們無法更改權限，如調整帳號餘額或操作類似於管理者權限的功能。但如果 API 端點自動將用戶端輸入的內容轉換為內部物件屬性，卻不考慮這些屬性的敏感度和可暴露度等級，則該 API 端點就很容易遭到惡意的攻擊，這將使得攻擊者可以非法更新他們不應該存取的內容。

攻擊情境範例

以共乘應用程式為例，其中提供了可以讓使用者編輯個人基本資料的功能。舉例來說，他們可以調整使用者名稱、年齡等基本資料。在這種情況下，API 的請求如下所示：
PUT /api/v1/users/me 並附上以下合法資料 {“user_name”：”john”,”age”：24} 但是，攻擊者透過測試判定請求 GET /api/v1/ users/me 中包括一個額外的 credit_balance 屬 性(欄位)，如下所示。 {“user_name”：”john”,”age”：24,”credit_ balance”：10}. 攻擊者希望增加自己的信用餘額，因此使用以下的 payload 重複了第一個請求： {“user_name”：”john”,”age”：24,”credit_ balance”：99999}

由於 API 易受大規模的批量攻擊，因此攻 擊者可以輕鬆調整自己的 credit_balance。例如：將 10 更改為 99,999，如上所示。

API7：2019-Security Misconfiguration (不安全的組態設定)

攻擊者通常會試圖找到未修補的漏洞、進入 點或未受保護的文件和目錄，以獲得未經授權的存取權限，或對要攻擊的系統進行了解。不安全的組態設定不僅會暴露敏感的使用者資訊，還有可能暴露可能導致伺服器完全受損的系統詳細資訊。

攻擊情境範例

舉例來說，攻擊者使用像 Shodan 這類型的搜尋引擎，搜索直接與網際網路相連的電腦和設備的資訊。例如：攻擊者發現一台運行中的資料庫管理系統的伺服器，正在監聽預設 的 TCP 端口。資料庫管理系統使用的是預設配置，在默認情況下會解除身份認證，因此攻擊者就可以存取數百萬則具有 PII 與個人喜好。

API8：2019-Injection (注入攻擊)

注入漏洞導致系統潛在地處理攻擊者所放入的惡意資料。簡而言之，攻擊者將程式碼注入易受攻擊的軟體中，並更改了執行軟體的方式。注入攻擊可能會導致一定程度的災難性影響，因為注入攻擊通常會導致資料遭竊、丟失、損壞或阻斷服務等。

攻擊情境範例

假設攻擊者開始檢視網頁瀏覽器的網路流量， 並識別出以下 API 為幫助使用者恢復密碼的請求。攻擊者確定負責啟動恢復密碼過程的 API 請求，如下所示： POST/api/accounts/recovery {“username”： “john@somehost.com”} 然後，攻擊者使用不同的 payload 重複請求： POST /api/account/recovery {“email”： “john@somehost.com’;WAITFOR DELAY ‘：：5’–“}
透過添加;WAITFOR DELAY ‘：：5’–”， 利用等待時間攻擊者發現，來自 API 的響應確 實額外花費了大約 5 秒的時間，此有助於確認 API 容易受到 SQL 注入攻擊。利用注入漏洞， 攻擊者就能夠獲得未經授權的系統存取權限。

API9：2019-Improper Assets Management (版本控管不當)

舊版本的 API 通常尚未修復與更新，因此可能淪為破壞系統的方法之一，透過攻擊尚未修復與更新的舊 API，而無需與最新的具安全性的新版 API 作鬥爭。攻擊者可能會存取敏感數據，甚至通過連接到同一資料庫尚未修復的舊版 API 來接管整個伺服器。

攻擊情境範例

若一個組織在重新設計其應用程式時，忽略了舊版 API(api.someservice.com/v1)，並使其未受保護，並可以存取使用者資料庫。在針對最新發布的應用程式時，攻擊者找到了 API 地址(api.someservice.com/v2)。將 URL 中的 v2 替換為 v1，使攻擊者可以存取舊的未受保護的 API，從而導致暴露了數百萬使用者的個人身份資訊 (PII)。

API10：2019-Insufficient Logging & Monitoring (紀錄與監控不足)

如果記錄日誌和監視有所欠缺或是不足，幾乎無法追蹤 API 的可疑活動並及時做出反應。由於無法了解正在進行的惡意活動，因此攻擊者有足夠的時間潛在地破壞系統並竊取資料。

攻擊情境範例

以一個影片共享平台遭到「大規模」帳號登錄攻擊為例。儘管記錄了失敗的登錄，但在攻擊持續時間內未觸發任何警報，所以攻擊得以持續進行而未引起任何注意。在使用者資料外洩投訴的反應，事件發生之後，對 API 日誌進行了分析並檢測到攻擊，但為時已晚。公司必須發布公告，要求使用者重設密碼，並將事件報告予監管機構。

上述的十種風險情況，可以很輕易想像出許多類似的攻擊情境。以上的範例只是各種 API 攻擊的冰山一角。希望您能看出上述風險主要是由錯誤或疏忽所導致，特別是現今組織使用 API 的方式。就可以輕鬆管理風險或甚至將風險排除。