OWASP API 安全項目旨在解決越來越多的組織將潛在敏感 API 作為其軟件產(chǎn)品的一部分進(jìn)行部署的問題，這些 API 通常用于內(nèi)部任務(wù)和與第三方的接口。不幸的是，許多 API 沒有經(jīng)過嚴(yán)格的安全測試。OWASP API 安全項目通過強調(diào)不安全 API 中的潛在風(fēng)險，并說明如何減輕這些風(fēng)險，為軟件開發(fā)人員和安全評估人員提供價值。為了實現(xiàn)這一目標(biāo)，OWASP AP I安全項目創(chuàng)建了一份 10 大 API 安全風(fēng)險文名單。
(資料圖片)
API 傾向于暴露處理對象標(biāo)識符的端點，從而創(chuàng)造出對象級訪問控制問題的廣泛攻擊面。因此在使用用戶 ID 訪問數(shù)據(jù)源的每個函數(shù)中，應(yīng)當(dāng)考慮執(zhí)行對象級授權(quán)檢查。
API 2：無效的身份認(rèn)證身份驗證機制通常實施不正確，允許攻擊者破壞身份驗證令牌或利用實現(xiàn)缺陷暫時或永久假定其他用戶的身份，損害系統(tǒng)識別客戶端/用戶的能力，會損害整體 API 安全性。
API 3：失效的對象屬性級授權(quán)此類別結(jié)合了 API 3:2019-過度的數(shù)據(jù)泄露和 API 6:2019-批量分配，關(guān)注的根本原因是對象屬性級缺乏授權(quán)驗證或驗證不當(dāng)，從而導(dǎo)致信息泄露或越權(quán)訪操縱。
API 4：不受限制的資源消耗滿足 API 請求需要網(wǎng)絡(luò)帶寬、CPU、內(nèi)存和存儲等資源。其它資源如郵件/SMS/電話通話或生物特征驗證由服務(wù)提供商通過 API 集成提供并按照請求進(jìn)行支付，如果攻擊成功可導(dǎo)致拒絕服務(wù)后果或運營成本上升。
API 5：無效的功能級授權(quán)具有不同層次結(jié)構(gòu)、組和角色的復(fù)雜訪問控制策略，以及管理功能和常規(guī)功能之間的不明確分離，往往會導(dǎo)致授權(quán)缺陷。通過利用這些問題，攻擊者可以訪問其他用戶的資源和/或管理功能。
API 6：對敏感業(yè)務(wù)流程的無限制訪問易受到此風(fēng)險影響的 API 會暴露業(yè)務(wù)流（例如買票或發(fā)布評論），而不會彌補如果以自動化方式過度使用，該功能如何對業(yè)務(wù)造成損害，這一風(fēng)險不一定源自實現(xiàn)問題。
API 7：服務(wù)器端請求偽造當(dāng) API 在沒有驗證用戶所提供 URI 的情況下提取遠(yuǎn)程資源時，可能就會引發(fā)服務(wù)器端請求偽造 (SSRF) 缺陷，這可以可使攻擊者誘騙應(yīng)用程序?qū)?gòu)造的請求發(fā)送給未預(yù)期目的地，甚至即使受到了防火墻或 VPN 的保護也是如此。
API 8：安全配置錯誤API 和支持它們的系統(tǒng)通常包含復(fù)雜的配置，旨在使 API 更具可定制性。軟件和 DevOps 工程師可能會錯過這些配置或者在配置時不遵循安全最佳實踐，從而為不同類型的攻擊打開了大門。
API 9：清單管理不當(dāng)與傳統(tǒng)的 Web 應(yīng)用程序相比，API 往往會公開更多的端點，因此正確和更新的文檔非常重要。主機和已部署 API 版本的適當(dāng)清單對于緩解已棄用的 API 版本和公開的調(diào)試終結(jié)點等問題也很重要。
API 10：不安全的 API 消耗開發(fā)人員偏向于信任從第三方 API 接收的數(shù)據(jù)而不是用戶輸入的數(shù)據(jù)，因此傾向于采用較弱的安全標(biāo)準(zhǔn)。為了破壞 API，攻擊者會攻擊集成的第三方服務(wù)，而不是試圖直接破壞目標(biāo) API。
文章來源：https://owasp.org/API-Security/editions/2023/en/0x11-t10/
標(biāo)簽：
