【風險通告】OWASP 2019 API安全Top10

0x00 風險概述

眾所周知,網路安全已成為大多陣列織的頭等大事,尤其是那些處理敏感客戶資訊的行業。隨著這些企業致力於構建穩健的安全策略,因此防範各種威脅和漏洞至關重要。

API安全是需要嚴格審查的領域之一。API 是應用程序程式設計接口的縮寫,已成為數字化組織的常用構建塊。它們促進了溝通和關鍵業務運營,還支持重要的數字化轉型。

但從某些安全方面講,API 會暴露應用程序邏輯和敏感資料,例如個人身份資訊 (PII),因此越來越頻繁地成為攻擊者的目標。

OWASP API 安全項目旨在通過強調不安全 API 的潛在風險並說明如何減輕這些風險來為軟體開發人員和安全評估人員提供價值。為了促進實現這一目標,OWASP API 安全項目創建和維護API 安全風險Top 10文件,以及創建或評估 API 時最佳實踐的文件門戶。

OWASP API 安全項目2019 年首次發佈了API 安全Top 10,旨在讓軟體開發人員和安全評估人員了解和減輕應用程序程式設計接口 (API) 的獨特漏洞和安全風險。

0x01 風險詳情

2019年API安全Top 10包括:

lAPI1:2019破壞對象級別授權

API往往會暴露出處理對象識別符號的端點,從而產生一個廣泛的攻擊面級別的訪問控制問題。在使用使用者的輸入訪問資料來源的每個函數中都應考慮對象級授權檢查。

攻擊者可以通過操縱請求中發送的對象的ID,來利用容易受到破壞的對象級授權的API端點。這可能導致對敏感資料的未授權訪問。這個問題在基於API的應用程序中極為常見,因為伺服器元件通常不會完全跟蹤客戶端的狀態,而是更多地依賴客戶端發送的對象ID等參數來決定訪問哪些對象。

防禦:

ü實施依賴於使用者策略和層次結構的適當授權機制。

ü使用授權機制來檢查登入使用者是否有權在使用客戶端輸入訪問資料庫中記錄的每個函數中對記錄執行請求的操作。

ü傾向於使用隨機和不可預測的值作為記錄ID的GUID。

ü編寫測試來評估授權機制。不要部署破壞測試的易受攻擊的更改。

lAPI2:2019損壞的使用者認證

認證機制的實施往往是不正確的,允許攻擊者破壞認證令牌或利用實施缺陷暫時或永久地使用其他使用者的身份。破壞了系統識別客戶/使用者的能力,從整體上損害了API的安全性。

API 中的身份驗證是一種複雜且令人困惑的機制。該問題大概可分為兩個子缺陷:

1. 缺乏保護機制:負責身份驗證的 API 端點必須與常規端點區別對待,並實施額外的保護層

2. 機制實施不當:使用/實施機制時未考慮攻擊向量,或者它是錯誤的用例(例如,為 IoT 客戶端設計的身份驗證機制可能不是 Web 應用程序的正確選擇)。

如果 API 存在以下情況,則該 API 很容易受到攻擊:

ü允許憑據填充,攻擊者藉此獲得有效使用者名和密碼的列表。

ü允許攻擊者對同一使用者帳戶執行暴力攻擊,而無需提供驗證碼/帳戶鎖定機制。

ü允許弱密碼。

ü發送敏感的身份驗證詳細資訊,例如 URL 中的身份驗證令牌和密碼。

ü不驗證令牌的真實性。

ü接受未簽名/弱簽名的 JWT 令牌 ( “alg”:”none”)/不驗證它們的到期日期。

ü使用純文字、未加密或弱哈希密碼。

ü使用弱加密金鑰。

防禦:

ü確保您知道所有可能的流程以向 API 進行身份驗證(移動/網路/實現一鍵式身份驗證的深層連結等)。

ü閱讀您的身份驗證機制。確保您了解它們的用途和使用方式。OAuth 不是身份驗證,API 金鑰也不是。

ü不要在身份驗證、令牌生成、密碼儲存方面重新發明輪子,使用標準。

ü在暴力破解、速率限制和鎖定保護方面,憑證恢復/忘記密碼端點應被視為登入端點。

ü使用OWASP 身份驗證備忘單。

ü在可能的情況下,實施多因素身份驗證。

ü實施反暴力破解機制,以減輕對身份驗證端點的憑據填充、字典攻擊和暴力破解攻擊。這種機制應該比 API 上的常規速率限制機制更嚴格。

ü實施帳戶鎖定/驗證碼機制以防止針對特定使用者的暴力破解。實施弱密碼檢查。

üAPI 金鑰不應用於使用者身份驗證,而應用於客戶端應用程序/項目身份驗證。

lAPI3:2019過度的資料暴露

期待通用的實現,開發人員傾向於暴露所有對象的屬性,而不考慮它們各自的敏感性,依靠客戶端在顯示給使用者之前進行資料過濾。

API 按照設計將敏感資料返回給客戶端。這些資料通常在呈現給使用者之前在客戶端進行過濾。攻擊者可以輕鬆嗅探流量並查看敏感資料。

防禦:

ü永遠不要依賴客戶端來過濾敏感資料。

ü查看來自 API 的響應以確保它們僅包含合法資料。

ü後端工程師在暴露一個新的API端點之前,應該總是問自己 “誰是資料的消費者?

ü避免使用通用方法,例如to_json()和to_string()。相反,挑選你真正想要返回的特定屬性。

ü對您的應用程序儲存和使用的敏感資訊和個人身份資訊 (PII) 進行分類,審查所有返回此類資訊的 API 調用,以查看這些響應是否會帶來安全問題。

ü實施基於模式的響應驗證機制作為額外的安全層。作為此機制的一部分,定義並強制執行所有 API 方法返回的資料,包括錯誤。

lAPI4:2019缺乏資源和速率限制

很多時候,API並沒有對客戶/使用者可以請求的資源的大小或數量進行任何限制。這不僅會影響API伺服器的性能,導致拒絕服務(DoS),而且還為暴力攻擊等認證缺陷打開了大門。

防禦:

üDocker 可以很容易地限制記憶體、CPU、重啟次數、 檔案描述符和進程。

ü對客戶端在定義的時間範圍內調用 API 的頻率實施限制。

ü當超過限制時,通過提供限制編號和重置限制的時間通知客戶。

ü為查詢字串和請求正文參數添加適當的伺服器端驗證,特別是控制要在響應中返回的記錄數的參數。

ü定義並強制執行所有傳入參數和有效負載的最大資料大小,例如字串的最大長度和陣列中元素的最大數量。

lAPI5:2019損壞的功能級別授權

具有不同層次、組和角色的複雜訪問控制策略,以及管理和常規功能之間不明確的分離,往往會導致授權缺陷的出現。通過利用這些問題,攻擊者獲得了對其他使用者的資源和/或管理功能的訪問。

防禦:

ü執行機制應該默認拒絕所有的訪問,要求明確授予特定角色對每個功能的訪問。

ü針對功能級別的授權缺陷審查您的API端點,同時牢記應用程序和組的層次結構的業務邏輯。

ü確保您所有的管理控制器都繼承自管理抽象控制器,該控制器根據使用者的組/角色來實現授權檢查。

ü確保常規控制器內的管理功能根據使用者的組和角色實現授權檢查。

lAPI6:2019批量分配

將客戶端提供的資料(如JSON)與資料模型綁定,而沒有根據允許列表進行適當的屬性過濾,通常會導致大規模分配。無論是猜測對象屬性、探索其他API端點、閱讀文件,還是在請求有效載荷中提供額外的對象屬性,都允許攻擊者修改他們不應該修改的對象屬性。

防禦:

ü如果可能,請避免使用自動將客戶端輸入綁定到程式碼變數或內部對象的函數。

ü僅將客戶端應更新的屬性列入白名單。

ü使用內建功能將不應由客戶端訪問的屬性列入黑名單。

ü如果適用,明確定義和實施輸入資料有效負載的架構。

lAPI7:2019安全配置錯誤

安全配置錯誤通常是不安全的默認配置、不完整或臨時配置、開放的雲儲存、錯誤配置的HTTP頭、不必要的HTTP方法、允許的跨源資源共享(CORS)以及包含敏感資訊的冗長錯誤資訊。

攻擊者通常會嘗試尋找未修補的缺陷、常見端點或未受保護的檔案和目錄,以獲得未經授權的訪問或對系統的了解。在以下情況下,API 可能容易受到攻擊:

ü應用程序堆疊的任何部分都缺少適當的安全加固,或者它對雲服務的許可權配置不當。

ü缺少最新的安全補丁,或者系統已過時。

ü啟用了不必要的功能(例如,HTTP verbs)。

ü傳輸層安全性(TLS) 缺失。

ü安全指令不會發送給客戶端(例如,安全標頭)。

ü跨域資源共享 (CORS) 策略缺失或設置不當。

ü錯誤訊息包括堆疊跟蹤,或暴露其他敏感資訊。

防禦:

API 生命週期應包括:

ü可重複的強化過程可以快速輕鬆地部署正確鎖定的環境。

ü審查和更新整個 API 堆疊的配置的任務。審核應包括:編排檔案、API 元件和雲服務(例如,S3 儲存桶許可權)。

ü所有 API 互動訪問靜態資產(例如,圖像)的安全通訊通道。

ü一個自動化過程,用於持續評估所有環境中配置和設置的有效性。

此外:

ü為了防止異常跟蹤和其他有價值的資訊被送回給攻擊者,如果適用的話,定義並執行所有API響應的有效載荷模式,包括錯誤響應。

ü確保 API 只能由指定的 HTTP verbs訪問。應禁用所有其他 HTTP verbs(例如HEAD)。

ü希望從基於瀏覽器的客戶端(如WebApp前端)訪問的API應實施適當的跨源資源共享(CORS)策略。

lAPI8:2019注入

注入缺陷,如SQL、NoSQL、命令注入等,當不受信任的資料作為命令或查詢的一部分被髮送到直譯器時就會發生。攻擊者的惡意資料可以欺騙直譯器執行非預期的命令或未經適當授權訪問資料。

在以下情況下,API 容易受到注入漏洞的影響:

üAPI 未驗證、過濾或清理客戶端提供的資料。

ü客戶端提供的資料直接用於或連接到 SQL/NoSQL/LDAP 查詢、作業系統命令、XML 解析器和對象關係對映 (ORM)/對象文件對映器 (ODM)。

ü來自外部系統(例如,集成系統)的資料未被 API 驗證、過濾或清理。

防禦:

ü防止注入需要將資料與命令和查詢分開:

ü使用單一、值得信賴且積極維護的庫執行資料驗證。

ü驗證、過濾和清理所有客戶提供的資料或來自集成系統的其他資料。

ü應使用目標直譯器的特定語法對特殊字符進行轉義。

ü首選提供參數化接口的安全 API。

ü始終限制返回記錄的數量,以防止在注入時大量洩露。

ü使用足夠的過濾器驗證傳入資料,以僅允許每個輸入參數的有效值。

ü為所有字串參數定義資料類型和嚴格模式。

lAPI9:2019資產管理不當

API 往往比傳統的 Web 應用程序公開更多的端點,因此正確和更新的文件非常重要。適當的主機和已部署的 API 版本清單在緩解諸如已棄用的 API 版本和暴露的調試端點等問題方面也發揮著重要作用。

因為舊的 API 版本通常未打補丁,是一種破壞系統的簡單方法,而過時的文件使查找和/或修復漏洞變得更加困難。攻擊者可能獲得敏感資料,甚至通過連接到同一資料庫的舊的、未打補丁的API版本接管伺服器。

防禦:

ü點所有 API 主機並記錄每個主機的重要方面,重點關注 API 環境(例如,生產、暫存、測試、開發)、誰應該對主機(例如,公共、內部、合作伙伴)進行網路訪問以及API 版本。

ü清點集成服務並記錄重要方面,例如它們在系統中的作用、交換的資料(資料流)及其敏感性。

ü記錄 API 的所有方面,例如身份驗證、錯誤、重定向、速率限制、跨源資源共享 (CORS) 策略和端點,包括它們的參數、請求和響應。

ü採用開放標準自動生成文件。在您的 CI/CD 管道中包含文件構建。

ü向授權使用 API 的人員提供 API 文件。

ü對所有暴露的 API 版本使用 API 安全防火牆等外部保護措施,而不僅僅是當前的生產版本。

ü避免將生產資料用於非生產 API 部署。如果這是不可避免的,這些端點應該得到與生產端點相同的安全處理。

ü當較新版本的 API 包括安全改進時,執行風險分析以決定舊版本所需的緩解措施:例如,是否可以在不破壞API 兼容性的情況下向後移植改進,或者您是否需要移除舊版本快速並強制所有客戶端遷移到最新版本。

lAPI10:2019日誌記錄和監控不足

日誌記錄和監控不足,再加上與事件響應的集成缺失或無效,使得攻擊者能夠進一步攻擊系統,保持永續性,轉向更多的系統,以篡改、提取或破壞資料。大多數違規研究表明,發現違規的時間超過200天,通常是由外部各方而不是內部流程或監測發現的。

攻擊者可以利用缺乏日誌記錄和監控來濫用系統而不被發現。在以下情況下,API 容易受到攻擊:

ü它不生成任何日誌,日誌記錄級別設置不正確,或者日誌訊息沒有包含足夠的詳細資訊。

ü不保證日誌完整性(例如,日誌注入)。

ü日誌不會被持續監控。

üAPI 基礎設施沒有得到持續監控。

防禦:

ü記錄所有失敗的身份驗證嘗試、拒絕訪問和輸入驗證錯誤。

ü日誌應該使用適合日誌管理解決方案使用的格式來編寫,並且應該包含足夠的細節來識別惡意行為者。

ü日誌應作為敏感資料處理,在靜止和傳輸時應保證其完整性。

ü配置監控系統以持續監控基礎設施、網路和 API 功能。

ü使用安全資訊和事件管理 (SIEM) 系統來彙總和管理來自 API 堆疊和主機的所有元件的日誌。

ü配置自定義儀表板和警報,以便更早地檢測和響應可疑活動。

0x02 安全建議

軟體開發人員和安全評估人員可參考實施該文件,以了解或減輕API安全風險。

此外,OWASP API 安全項目團隊計劃在 2022 年構建和發佈新版 OWASP API 安全 Top 10,相關資料徵集將於 2022 年 9 月 – 11 月期間開放。

0x03 參考連結

https://owasp.org/www-project-api-security/

https://github.com/OWASP/API-Security

https://owasp.org/www-project-api-security/announcements/cfd/2022/

0x04 版本資訊

版本

日期

修改內容

V1.0

2022-11-23

首次發佈

相關文章