1.前言

應(yīng)用程序編程接口（API）是當(dāng)今應(yīng)用驅(qū)動世界創(chuàng)新的一個基本元素。從銀行、零售、運輸?shù)轿锫?lián)網(wǎng)、 自動駕駛汽車、智慧城市，API 是現(xiàn)代移動、SaaS 和 web 應(yīng)用程序的重要組成部分，可以在面向客 戶、面向合作伙伴和內(nèi)部的應(yīng)用程序中找到。 從本質(zhì)上講，API 暴露了應(yīng)用程序邏輯和敏感數(shù)據(jù)，如個人身份信息（PII），因此，API 越來越 成為攻擊者的目標(biāo)。如果沒有安全的 API，快速創(chuàng)新是不可能的。 盡管更廣泛的 web 應(yīng)用程序安全風(fēng)險 Top 10 仍然有意義，但由于 API 特殊性質(zhì)，需要一份特 定于 API 的安全風(fēng)險列表。API 安全側(cè)重于策略和解決方案，以了解和減輕與 API 相關(guān)的獨特漏洞和 安全風(fēng)險。

2. API安全 top 10

2.1?API1: 2023 對象級授權(quán)失效

2.1.1 API脆弱點

對象級授權(quán)是一種通常在代碼層面開發(fā)實施的訪問控制機(jī)制，用于驗證用戶只能訪問其具有 權(quán)限的對象。

每個可以接收對象 ID 并對對象執(zhí)行操作的 API 端點，都應(yīng)該實施對象級授權(quán)檢查。這些檢 查應(yīng)驗證已登錄用戶是否具有執(zhí)行請求的操作權(quán)限。這種機(jī)制的失效通常會導(dǎo)致未經(jīng)授權(quán)的信息 泄露、篡改或破壞。僅僅將當(dāng)前會話的用戶 ID（例如，從 JWT 令牌中提?。┡c存在漏洞的 ID 參 數(shù)進(jìn)行比較，只能解決一小部分情況，并不足以解決對象級授權(quán)失效（BOLA）問題。

在 BOLA 的情況下，用戶有意被授予對存在漏洞的 API 端點 / 功能的訪問權(quán)限。違規(guī)行為發(fā) 生在對象級別，通過操縱 ID 來實現(xiàn)。如果攻擊者成功訪問了本應(yīng)無權(quán)訪問的 API 端點 / 功能， 那就是 API5:2023 功能級授權(quán)（BFLA，Broken Function Level Authorization）問題，而不是 BOLA。

2.1.2 攻擊場景示例

2.1.3 預(yù)防措施

· 實施正確的授權(quán)機(jī)制，依賴于用戶策略和層級結(jié)構(gòu)。

· 使用授權(quán)機(jī)制檢查已登錄用戶是否具有執(zhí)行所請求操作的記錄的訪問權(quán)限，以及在每個使用 來自客戶端的輸入訪問數(shù)據(jù)庫記錄的功能中執(zhí)行該檢查。

· 優(yōu)先使用隨機(jī)且不可預(yù)測的值作為記錄 ID 的 GUID。

· 編寫測試以評估授權(quán)機(jī)制的漏洞。不要部署測試失敗的更改。

2.2?API2:2023 用戶身份驗證失效

2.2.1 API脆弱點

認(rèn)證端點和流程是需要保護(hù)的資產(chǎn)。此外，對“忘記密碼 / 重置密碼”的處理方式應(yīng)與認(rèn)證
機(jī)制一致。如果 API 存在以下情況，則可能存在安全漏洞：
??? ? 允許憑證填充攻擊，攻擊者使用有效的用戶名和密碼列表進(jìn)行暴力破解。
??? ? 允許攻擊者對同一用戶賬戶進(jìn)行暴力破解攻擊，而未有驗證碼或賬戶鎖定機(jī)制。
??? ? 允許使用弱密碼。
??? ? 在 URL 中發(fā)送敏感的認(rèn)證信息，如身份令牌和密碼。
??? ? 允許用戶在不要求密碼確認(rèn)的情況下更改電子郵件地址、當(dāng)前密碼或執(zhí)行其他敏感操作。
??? ? 未驗證令牌的真實性。
??? ? 接受未簽名或弱簽名的 JWT 令牌（{"alg":"none"}）。
??? ? 未驗證 JWT 令牌的過期日期。
??? ? 使用明文、非加密或弱哈希的密碼。
??? ? 使用弱加密密鑰。
此外，如果一個微服務(wù)存在以下情況，也可能存在安全漏洞：
??? ? 其他微服務(wù)可以在無需認(rèn)證的情況下訪問它。
??? ? 使用弱或可預(yù)測的令牌進(jìn)行身份驗證。

2.2.2 攻擊場景示例

2.2.3 預(yù)防措施

??? ? 確保你了解了所有可能的 API 認(rèn)證流程（包括移動端、Web 端、實現(xiàn)一鍵認(rèn)證的深度鏈
接等等）。詢問你的工程師是否有遺漏的流程。
??? ? 了解您的認(rèn)證機(jī)制。確保理解其使用方式和原理。OAuth 不是認(rèn)證，API 密鑰也不是認(rèn)證。
??? ? 在身份認(rèn)證、令牌生成和密碼存儲方面，請使用標(biāo)準(zhǔn)的解決方案，不需要浪費精力去自創(chuàng)。
??? ? 將憑證恢復(fù) / 忘記密碼的端點視為登錄端點，采取防止暴力破解、限制請求速率和賬戶
鎖定的措施。
??? ? 要求對敏感操作（例如更改賬戶所有者的電子郵件地址、更改用于雙因素認(rèn)證的手機(jī)號碼）
進(jìn)行二次認(rèn)證。
??? ? 使用 OWASP Authentication Cheatsheet。
??? ? 在條件允許的情況下，實施多因素認(rèn)證。
??? ? 實施反暴力破解機(jī)制，以減輕憑證填充、字典攻擊和暴力破解攻擊對認(rèn)證端點的影響。
這種機(jī)制應(yīng)該比 API 上常規(guī)的速率限制機(jī)制更加嚴(yán)格。
??? ? 實施賬戶鎖定 / 驗證碼機(jī)制，以防止針對特定用戶的暴力破解攻擊。
??? ? 實施弱口令檢查。
??? ? API 密鑰不應(yīng)該用于用戶身份驗證，而應(yīng)僅用于 API 客戶端 API clients 的身份驗證。

2.3?API3:2023 對象屬性級授權(quán)失效

2.3.1 API脆弱點

當(dāng)允許用戶通過 API 接口訪問對象時，驗證用戶是否具有試圖訪問的特定對象屬性的訪問權(quán)
限 ，這點是很重要的。
如果 API 存在以下情況，則可能存在安全漏洞：
??? ? API 接口公開了對象的屬性，這些屬性被認(rèn)為是用戶不應(yīng)讀取的敏感數(shù)據(jù)。
?( 原為 API3:2019 過度數(shù)據(jù)暴露 Excessive Data Exposure)
??? ? API 接口允許用戶更改、添加或刪除用戶本不該訪問的敏感對象屬性的值。
?( 原為 API6:2019 批量分配 Mass Assignment)

2.3.2 攻擊場景示例

2.3.3 預(yù)防措施

??? ? 在使用 API 接口暴露對象時，始終確保用戶具有訪問權(quán)限才可訪問所公開的對象屬性。
??? ? 避免使用通用方法，如 to_json() 和 to_string()。相反，仔細(xì)篩選您想要的返回的特定對
象屬性。
??? ? 盡 量 避 免 使 用 自 動 將 客 戶 端 輸 入 綁 定 到 代 碼 變 量、 內(nèi) 部 對 象 或 對 象 屬 性 的 功 能（“API6:2019 批量分配 Mass Assignment”）。
??? ? 僅允許客戶端更改客戶端有權(quán)限更新的對象屬性。
??? ? 實施基于異常通知 (Schema-based) 方式，作為額外的安全層。作為該機(jī)制的一部分，
定義和執(zhí)行所有 API 方法返回的數(shù)據(jù)。
??? ? 根據(jù)接口的業(yè)務(wù) / 功能需求，將返回的數(shù)據(jù)結(jié)構(gòu)保持最簡化。

2.4?API4:2023 資源消耗不受限制

2.4.1 API脆弱點

滿足 API 請求需要使用諸如網(wǎng)絡(luò)帶寬、CPU、內(nèi)存和存儲等資源。有時，服務(wù)提供商通過
API 集成提供所需的資源，并按請求付費，例如發(fā)送電子郵件 / 短信 / 電話呼叫、生物識別驗證等。
如果 API 缺少或不恰當(dāng)?shù)卦O(shè)置了以下任何一個限制（例如，設(shè)置過低 / 過高），則該 API 存
在漏洞：
??? ? 執(zhí)行超時。
??? ? 最大可分配內(nèi)存。
??? ? 最大文件描述符數(shù)量。
??? ? 最大進(jìn)程數(shù)量。
??? ? 最大上傳文件大小。
??? ? 單個 API 客戶端請求中要執(zhí)行的操作數(shù)量（例如，GraphQL 批處理）。
??? ? 單個請求 - 響應(yīng)中要返回的每頁記錄數(shù)量。
??? ? 第三方服務(wù)提供商的支出限制。

2.4.2 攻擊場景示例

2.4.3 預(yù)防措施

??? ? 使用容器 / 無服務(wù)器代碼（如 Lambda）等解決方案，可以輕松限制內(nèi)存、CPU、重新啟動次數(shù)、文件描述符和進(jìn)程等資源。
??? ? 在所有傳入?yún)?shù)和負(fù)載中定義并強(qiáng)制執(zhí)行數(shù)據(jù)的最大大小，例如字符串的最大長度、數(shù)組中的最大元素數(shù)量以及最大上傳文件大小（無論是本地存儲還是云存儲）。
??? ? 在一定時間范圍內(nèi)限制客戶端與 API 的交互頻率（速率限制）。
??? ? 根據(jù)業(yè)務(wù)需求對速率限制進(jìn)行調(diào)優(yōu)。某些 API 端點可能需要更嚴(yán)格的策略。
??? ? 限制單個 API 客戶端 / 用戶執(zhí)行單個操作的次數(shù)或頻率（例如一次性口令驗證、在無需訪問一次性 URL 的情況下請求密碼恢復(fù)）。
??? ? 對查詢字符串和請求體參數(shù)進(jìn)行適當(dāng)?shù)姆?wù)器端驗證，特別是控制響應(yīng)中返回記錄數(shù)量的參數(shù)。
??? ? 為所有服務(wù)提供商 /API 集成配置消費限制。如果無法設(shè)置消費限制，則應(yīng)配置計費警報。

2.5?API5:2023 功能級授權(quán)失效

2.5.1 API脆弱點

要找出失效的功能級授權(quán)問題的最佳方式需要結(jié)合應(yīng)用程序中用戶層級、不同角色與用戶組的差異，充分分析其授權(quán)機(jī)制，并檢查以下問題：
??? ? 普通用戶能否訪問管理端點？
??? ? 用戶是否可以通過簡單地修改 HTTP 方法（如，將 GET 請求變?yōu)?DELETE 請求）來執(zhí)行他們無權(quán)訪問的敏感操作（例如創(chuàng)建、修改或刪除）？
??? ? 屬于用戶組 X 的用戶是否可以輕易地猜測出端點 URL 和參數(shù)（如 /api/v1/users/export_
all），并訪問本該只提供給用戶組 Y 的功能？不要僅基于 URL 路徑來判斷 API 端點是常規(guī)的還是用于管理的。開發(fā)人員可能會選擇將大部分管理端點設(shè)定在特定的相對路徑下，例如 /api/admins，通過其他常規(guī)端點的相關(guān)路徑，如 /api/users，能夠輕易地發(fā)現(xiàn)這些管理端點。
?

2.5.2 攻擊場景示例

2.5.3 預(yù)防措施

在應(yīng)用程序中應(yīng)集成一個統(tǒng)一的、易于分析的授權(quán)模塊，并在所有的業(yè)務(wù)功能中進(jìn)行調(diào)用。
通常這種保護(hù)機(jī)制是由應(yīng)用程序代碼外的一個或多個組件提供的。
??? ? 應(yīng)強(qiáng)制默認(rèn)拒絕所有訪問，每個功能的訪問需要明確地授權(quán)給具體的用戶角色。
??? ? 結(jié)合應(yīng)用程序的業(yè)務(wù)邏輯和組織層次結(jié)構(gòu)，審查 API 端點以檢測功能級授權(quán)缺陷。
??? ? 確保所有管理控制器都繼承自基于用戶組 / 角色授權(quán)檢查的管理抽象控制器。
??? ? 確保常規(guī)控制器中的管理功能可根據(jù)用戶組和角色實現(xiàn)授權(quán)檢查。

2.6?API6:2023 對敏感業(yè)務(wù)流的無限制訪問

2.6.1 API脆弱點

創(chuàng)建 API 端點時，需要著重了解其所暴露的業(yè)務(wù)流程，某些業(yè)務(wù)流程比其他流程更加敏感，對這些敏感流程的過度訪問可能會對業(yè)務(wù)造成損害。
以下是敏感業(yè)務(wù)流程的常見例子及與其過度訪問相關(guān)的風(fēng)險：
??? ? 產(chǎn)品購買流程 - 攻擊者可以一次性清空市場需求大的商品的庫存，并以更高的價格銷售（黃牛黨）。
??? ? 評論 / 發(fā)帖流程 - 攻擊者可以對系統(tǒng)進(jìn)行“刷屏”、“灌水”。
??? ? 預(yù)訂流程 - 攻擊者可以預(yù)訂所有可用時間段，從而阻止其他用戶使用該系統(tǒng)。
過度訪問的風(fēng)險可能在不同行業(yè)和企業(yè)之間存在差異。例如， 通過腳本創(chuàng)建帖子可能被一個社交網(wǎng)絡(luò)認(rèn)為是“刷屏”、“灌水”，而被另一個社交網(wǎng)絡(luò)鼓勵發(fā)帖。如果 API 端點中暴露一個敏感業(yè)務(wù)流程且未對端點訪問做適當(dāng)?shù)南拗疲敲丛摌I(yè)務(wù)流程易受攻擊。

2.6.2 攻擊場景示例

2.6.3 預(yù)防措施

風(fēng)險緩解措施應(yīng)該從以下兩個方面著手：
??? ? 業(yè)務(wù) - 識別被過度使用可能會對業(yè)務(wù)造成損害的業(yè)務(wù)流程。
??? ? 工程 - 選擇合適的保護(hù)機(jī)制來減輕業(yè)務(wù)風(fēng)險。一些保護(hù)機(jī)制是較簡單易行的，而另一些則較為復(fù)雜。以下是用于降低自動化威脅的方法：
??? ? 設(shè)備指紋識別：拒絕向未預(yù)期的客戶端設(shè)備（例如無頭部字段的瀏覽器）提供服務(wù)，這通常會迫使攻擊者使用更復(fù)雜的方式，從而提高攻擊成本。
??? ? 人類檢測：使用驗證碼或更先進(jìn)的生物特征解決方案（例如擊鍵生物識別）。
??? ? 非人類模式：分析用戶流程以檢測非人類模式（例如，用戶在不到一秒鐘的時間內(nèi)訪問了“添加到購物車”和“完成購買”功能）。
??? ? 可以考慮阻止匿名網(wǎng)絡(luò)出口節(jié)點和知名代理的 IP 地址。確保直接被機(jī)器調(diào)用的 API（例如開發(fā)者和商戶間的 API）安全、受限地訪問。由于它們常常未實現(xiàn)所有必需的保護(hù)機(jī)制，通常會變成攻擊者的易攻擊目標(biāo)。

2.7?API7:2023 服務(wù)器端請求偽造

2.7.1 API脆弱點

當(dāng) API 在未驗證用戶提供的 URL 的情況下獲取遠(yuǎn)程資源時，會出現(xiàn)服務(wù)器端請求偽造 (SSRF)漏洞。它使攻擊者能夠繞過防火墻或 VPN 的保護(hù)強(qiáng)制應(yīng)用程序?qū)e有用心設(shè)計的請求發(fā)送到非預(yù)期的目標(biāo)。應(yīng)用程序開發(fā)中的現(xiàn)代概念使 SSRF 更常見和更危險 :
??? ? 更常見 - 鼓勵開發(fā)人員根據(jù)用戶輸入訪問外部資源：Webhook、從 URL 獲取文件、自定義 SSO 和 URL 預(yù)覽。
??? ? 更危險 – 云提供商、Kubernetes 和 Docker 等現(xiàn)代技術(shù)在可預(yù)測的、眾所周知的路徑上通過 HTTP 暴露管理和控制通道。這些通道很容易成為 SSRF攻擊的目標(biāo)。由于現(xiàn)代應(yīng)用程序的連接特性，限制應(yīng)用程序的出站流量也更具挑戰(zhàn)性。SSRF 風(fēng)險并非總能完全消除。在選擇保護(hù)機(jī)制時，重要的是考慮業(yè)務(wù)的風(fēng)險和需求。

2.7.2 攻擊場景示例

2.7.3 預(yù)防措施

??? ? 隔離網(wǎng)絡(luò)中的資源獲取機(jī)制：通常這些功能旨在獲取遠(yuǎn)程資源而不是內(nèi)部資源。
??? ? 盡可能使用下列允許列表：
? 遠(yuǎn)程來源用戶（例如 Google 云端硬盤、Gravatar 等）下載資源列表
? URL schemes 和端口列表
? 給定功能性可接受的媒體類型列表
? 禁用 HTTP 重定向
??? ? 使用經(jīng)過良好測試和維護(hù)的 URL 解析器來避免 URL 解析不合理引起的問題。
??? ? 驗證和檢查所有客戶提供的輸入數(shù)據(jù)。
??? ? 不要向客戶端發(fā)送原始響應(yīng)。

2.8?API8:2023 安全配置錯誤

2.8.1 API脆弱點

如果出現(xiàn)以下情況，API 可能會受到攻擊：
??? ? API 堆棧的某些部分缺少適當(dāng)?shù)陌踩庸蹋蛘咴品?wù)的權(quán)限配置不當(dāng)。
??? ? 缺少最新的安全補(bǔ)丁，或系統(tǒng)已廢棄。
??? ? 啟用了不必要的功能（例如 HTTP 方法、日志記錄特性）。
??? ? HTTP 服務(wù)調(diào)用鏈中的服務(wù)器處理傳入請求的方式存在差異。
??? ? 傳輸層安全性 (TLS) 缺失。
??? ? 不向客戶端發(fā)送安全或緩存控制指令。
??? ? 跨域資源共享 (CORS) 策略缺失或配置不當(dāng)。
??? ? 錯誤消息中包含堆棧跟蹤信息或其他敏感信息。

2.8.2 攻擊場景示例

2.8.3 預(yù)防措施

在 API 的生命周期中應(yīng)包含：
??? ? 可重復(fù)的強(qiáng)化過程，可快速輕松地部署的適當(dāng)鎖定的環(huán)境。
??? ? 審查和更新整個 API 堆棧的配置，審查應(yīng)包括：編排文件、API 組件和云服務(wù)（例如 S3存儲桶權(quán)限）。
??? ? 建立持續(xù)評估所有環(huán)境中配置和設(shè)置有效性的自動化流程。
此外：
??? ? 確保從客戶端到 API 服務(wù)器以及任何下游 / 上游組件的所有 API 通信都通過加密通道(TLS) 進(jìn)行，無論它是內(nèi)部 API 還是面向公眾的 API。
??? ? 具 體 說 明 每 個 API 允 許 使 用 哪 些 HTTP 方 法： 應(yīng) 禁 用 所 有 其 他 HTTP 方 法（ 例 如HEAD）。
??? ? 基于瀏覽器的客戶端（例如 WebApp 前端）訪問的 API 至少應(yīng)該：
? 實施適當(dāng)?shù)目缬蛸Y源共享 (CORS) 政策。
? 包含適用的安全標(biāo)頭。
? 將傳入的內(nèi)容類型 / 數(shù)據(jù)格式限制為滿足業(yè)務(wù) / 功能要求的內(nèi)容類型 / 數(shù)據(jù)格式。
? 確保 HTTP 服務(wù)調(diào)用鏈的所有服務(wù)器（例如負(fù)載平衡器、反向和正向代理以及后端服務(wù)器）以統(tǒng)一的方式處理傳入請求以避免不同步問題。
? 在適用的情況下，定義和實施所有 API 響應(yīng)有效負(fù)載模式，包括錯誤響應(yīng)，以防止異常跟蹤信息和其他有價值的信息返回給攻擊者。

2.9?API9:2023 庫存管理不當(dāng)

2.9.1 API脆弱點

API 與現(xiàn)代應(yīng)用程序之間的分散和連接給組織帶來了新的挑戰(zhàn)，對于組織來說，不僅要對組織內(nèi)部的 API 和 API 端點有良好的理解和可視化，還需要了解 API 與外部第三方之間，是如何存儲或共享數(shù)據(jù)的。多個版本的 API 共存時， API 提供者需要投入額外的管理資源，同時也擴(kuò)大了攻擊面。
如何規(guī)避上述風(fēng)險，以下問題可以幫助我們判斷 API 是否存在“文檔盲點”（"documentationblindspot"）：
??? ? API 服務(wù)的用途不明確，并且下述問題沒有明確的答案：
? API 服務(wù)運行在哪個環(huán)境中（例如生產(chǎn)環(huán)境、演示環(huán)境、測試環(huán)境、開發(fā)環(huán)境）？
? 誰應(yīng)該具有 API 的網(wǎng)絡(luò)訪問權(quán)限（例如公眾用戶、內(nèi)部用戶、合作伙伴）？
? API 使用的是哪個版本？
??? ? 沒有 API 文檔或 API 文檔不是最新的。
??? ? 沒有為每個 API 版本制定下線計劃。
??? ? API 服務(wù)的庫存清單缺失或過期。
敏感數(shù)據(jù)流的可視化和庫存清單，在事件響應(yīng)計劃中起著重要作用，以防萬一發(fā)生第三方違規(guī)事件。
以下問題可以幫助我們判斷 API 是否存在“數(shù)據(jù)流盲點”（data flow blindspot）：
??? ? 存在 API 與第三方共享敏感數(shù)據(jù)的“敏感數(shù)據(jù)流”描述，但不滿足下述條件：
? 沒有業(yè)務(wù)層面的正當(dāng)理由或流程審批。
? 沒有清單或敏感數(shù)據(jù)流的可視化流程。
? 沒有對共享的敏感數(shù)據(jù)類型做深入的可視化。

2.9.2 攻擊場景示例

2.9.3 預(yù)防措施

??? ? 對所有的 API 服務(wù)進(jìn)行清單管理，記錄每個 API 服務(wù)的關(guān)鍵內(nèi)容，重點關(guān)注 API 運行環(huán)境（生產(chǎn)、演示、測試、開發(fā)）、具有網(wǎng)絡(luò)訪問權(quán)限的人員（公眾用戶、內(nèi)部用戶、合作伙伴）以及 API 版本信息。
??? ? 對集成服務(wù)進(jìn)行清單管理，記錄其中的關(guān)鍵內(nèi)容，比如系統(tǒng)中的角色、數(shù)據(jù)交換情況（數(shù)據(jù)流）以及數(shù)據(jù)的敏感級別等。
??? ? 文檔化所有的 API 信息，例如身份驗證、錯誤處理、重定向、速率限制、跨域資源共享（CORS）策略以及 API 端點信息（比如參數(shù)、請求和響應(yīng)）。
??? ? 采用開放標(biāo)準(zhǔn)自動生成 API 文檔，將文檔構(gòu)建納入 CI/CD 流程中。
??? ? 僅對被授權(quán)使用 API 的人員提供 API 文檔。
??? ? 使用外部保護(hù)措施，例如針對所有暴露的 API 版本使用特定的 API 安全解決方案，而不僅僅是針對當(dāng)前的生產(chǎn)版本。
??? ? 避免在非生產(chǎn)的 API 部署環(huán)境中使用生產(chǎn)數(shù)據(jù)。如果無法避免，這些端點應(yīng)該得到與生產(chǎn)環(huán)境相同的安全防護(hù)。
??? ? 當(dāng)新版本的 API 包含安全改進(jìn)時，也需要對老版本進(jìn)行風(fēng)險分析，以確定老版本所需的緩解措施。例如，是否可以將改進(jìn)的功能回溯到老版本而不影響 API 的兼容性，或者，是否需要快速停用舊版本并強(qiáng)制所有客戶端升級到最新版本。

2.10?API10:2023 API 的不安全使用

2.10.1 API脆弱點

比起用戶輸入的信息，開發(fā)人員往往更信任來自第三方 API 的數(shù)據(jù)，尤其是那些由知名公司提供的 API。正因如此，開發(fā)人員趨向于使用較弱的安全標(biāo)準(zhǔn)，特別是在輸入驗證和凈化方面。
如果 API 存在以下情況，則可能存在漏洞：
??? ? 使用未加密的通道與其他的 API 進(jìn)行交互；
??? ? 從其他的 API 收集的數(shù)據(jù)，在處理之前沒有對數(shù)據(jù)正確驗證和凈化，或者，在將數(shù)據(jù)傳遞給下游組件時沒有進(jìn)行適當(dāng)處理；
??? ? 盲目地跟隨重定向；
??? ? 沒有限制處理第三方服務(wù)響應(yīng)的資源數(shù)量；
??? ? 與第三方服務(wù)進(jìn)行交互時，沒有實施超時機(jī)制。
通過滿足上述安全要求，可以減少 API 的潛在漏洞，提高應(yīng)用程序的安全性。

2.10.2 攻擊場景示例

2.10.3 預(yù)防措施

??? ? 在評估服務(wù)提供商時，評估其 API 的安全狀況。
??? ? 確保所有 API 交互都在安全的通信通道（使用 TLS）。
??? ? 在使用集成 API 接收到的數(shù)據(jù)之前，始終對其進(jìn)行驗證和適當(dāng)?shù)膬艋幚怼?br> ??? ? 不要盲目地跟隨重定向，維護(hù)一個已知的、允許的用于集成 API 的重定向位置清單。

3. 一些滲透經(jīng)驗記錄

后續(xù)補(bǔ)充。

4.最后

API安全是個持續(xù)的過程，要求開發(fā)者、操作和安全團(tuán)隊協(xié)作確保API面臨的風(fēng)險得到恰當(dāng)管理。遵循OWASP API Security Top 10是創(chuàng)建一個更安全API生態(tài)系統(tǒng)的基礎(chǔ)。在構(gòu)建API時，要確?？紤]到這些主要的安全問題，并在API的整個生命周期中持續(xù)關(guān)注安全保障。

參考：

OWASP API Security TOP 10中文項目 2023

OWASP API Security TOP 10中文項目 — OWASP-CHINA

OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10文章來源地址http://www.zghlxwxcb.cn/news/detail-858098.html

到了這里，關(guān)于從OWASP API Security TOP 10談API安全的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！