開發人員指南:確保強大API安全的最佳實踐

開發人員指南:確保強大API安全的最佳實踐

應用程式介面安全是指實施保護措施來保護應用程式介面及其傳輸的資料,最終防止未經授權的訪問並確保軟體系統和服務的可靠性。它對於保護您的資料和應用程式免遭未經授權的訪問、資料修改或破壞至關重要。本文探討了開發人員如何保護應用程式介面的最佳實踐

隨著現代軟體開發越來越依賴應用程式介面(API),API 已成為網路攻擊的主要目標。在 Palo Alto 於 2023 年進行的一項調查中,92% 的參與研究組織在過去一年中至少遇到過一次與 API 相關的安全事件。在這些企業中,57%的企業遇到過多次與 API 相關的安全事件。讓我們來討論一下風險以及如何避免風險。

OWASP API 安全風險

開放式網路應用程式安全專案(OWASP)是一個致力於提高軟體安全性的非營利性組織。它提供各種資源,包括指南、工具和最佳實踐,以幫助開發人員和組織提高應用程式的安全性。該組織旨在提高人們對應用程式安全問題的認識,並提供切實可行的解決方案來降低風險。

2019 年,該組織在年度報告中增加了安全 API Top 10 榜單。該榜單確定了 API 安全十大風險,為開發人員提供指導,讓他們全面瞭解 API 生態系統中普遍存在的威脅。OWASP 維護十大 API 風險,最新版本於 2023 年釋出

OWASP API 2019 年十大風險列表  OWASP API 2023 年十大風險列表
1. 被破壞的物件級授權  1. 被破壞的物件級授權
2. 被破損的使用者身份驗證  2. 失靈的身份驗證
3. 資料過度暴露  3. 物件屬性級授權失效
4. 缺乏資源和速率限制  4. 不受限制的資源消耗
5. 功能級授權失效  5. 功能級授權失效
6. 大規模分配  6. 不受限制地訪問敏感業務流
7. 安全配置錯誤  7. 伺服器端請求偽造
8. 注入  8. 安全配置錯誤
9. 資產管理不當  9. 庫存管理不當
10. 日誌記錄和監控不足 10. 不安全地使用 API

瞭解每種風險

被破壞的物件級授權

API 使用物件級授權來確保只有授權使用者才能訪問其提供的資料。如果應用程式介面未能在物件級別充分執行訪問控制,允許未經授權的使用者檢視、修改或刪除他們不應該訪問的資料,就會出現物件級授權失效(BOLA)的情況。這種風險表明,應用程式介面沒有正確檢查誰可以對特定物件執行哪些操作,從而可能暴露敏感資料。

舉例說明: Purple-Cart 是一個線上購物平臺,使用者可以檢視和編輯他們的訂單詳細資訊。在這種情況下,如果物件級授權失效,一個使用者就可以操作甚至刪除另一個使用者的訂單資訊。

這種風險的影響可能非常嚴重。它可能導致資料洩露、隱私侵犯和經濟損失。未經授權訪問敏感資料會損害組織的聲譽,並導致法律後果,因此需要謹慎降低風險。

斷點驗證

身份驗證失效是一種漏洞,由於身份驗證過程中的缺陷,它允許未經授權訪問應用程式或 API。當憑證未得到適當保護、會話未得到充分管理或存在薄弱的身份驗證方法時,就會出現這種情況。

舉例說明:如果應用程式介面不要求使用者在更改電子郵件地址時提供當前密碼以確認身份,攻擊者就可能利用這種漏洞接管使用者賬戶。

失效身份驗證的影響可能是有害的,會導致未經授權的賬戶訪問、身份盜用和敏感資料濫用。

破壞物件屬性級授權(BOLA)

在這種情況下,攻擊涉及通過過度資料暴露(向使用者暴露敏感資料或不必要的資料)或批量賦值(同時為物件的多個屬性賦值)來獲得對敏感資訊的未授權訪問。利用此漏洞,無有效訪問許可權的使用者可讀取和/或修改端點的物件值。

舉例說明:網上銀行應用程式的 API 端點允許使用者檢索其賬戶資訊。該端點將使用者的賬號作為引數,並返回一個包含使用者賬戶餘額、交易歷史和其他賬戶詳細資訊的物件。

利用該漏洞可能導致攻擊者訪問潛在的敏感資料,包括個人身份資訊 (PII)。此外,利用此類漏洞的攻擊者可更改物件的屬性,從而提升許可權、篡改資料和繞過安全機制。

不受限制的資源消耗

這是一種旨在耗盡目標系統或應用程式資源的拒絕服務(DoS)攻擊。當攻擊者可以從 API 中消耗過多資源(如 CPU、記憶體或頻寬)時,就會發生不受限制的資源消耗。這可以通過向 API 發出大量請求來實現。

舉例說明:一個社交媒體應用程式有一個 API 端點,允許使用者重置忘記的密碼。該端點將使用者的電子郵件地址作為引數,併傳送帶有重置密碼連結的電子郵件。但是,該端點沒有實施速率限制或其他措施來防止無限制的資源消耗。這意味著攻擊者可以向端點傳送大量請求,重置大量使用者的密碼。

利用應用程式中的這一漏洞會導致效能下降、中斷,甚至造成經濟損失。

功能級授權中斷

當應用程式介面允許未經授權的使用者訪問某些功能或執行他們本不應該訪問的操作時,就會出現功能級授權中斷。這種漏洞通常源於不當的訪問控制措施。

舉例說明: 考慮一個電子商務應用程式,由於功能級授權失效,普通使用者可以修改產品價格。這可能會導致經濟損失、混亂和潛在的系統濫用。

功能級別授權失效可能會造成重大影響,導致經濟損失、使用者不滿和系統功能濫用。

不受限制地訪問敏感業務流

這涉及利用應用程式的業務模型來獲得對敏感業務流的無限制訪問。要利用此漏洞,攻擊者需要了解目標 API 背後的業務邏輯,找到敏感的業務流,並自動對其進行訪問。

舉例說明: 使用者通過保留所有電影首映時段,阻止其他使用者使用電影院應用程式。

不受限制地訪問敏感業務流會讓攻擊者竊取資料、發起 DoS 攻擊和實施欺詐,從而損害公司的財務和聲譽。

伺服器端請求偽造(SSRF)

當攻擊者可以迫使 API 伺服器向其他系統發出未經授權的請求時,就會發生 SSRF。

舉例說明: 社交媒體應用程式的 API 端點允許使用者共享連結。端點將連結的 URL 作為引數,並返回連結的預覽。攻擊者可以傳送惡意 URL,並使用 API 端點在內部網路上啟動埠掃描,以發現開放埠。

利用 SSRF,攻擊者可以訪問未經授權的網路、篡改資料,甚至完全入侵伺服器。

安全配置錯誤

當 API 或其元件配置不安全時,就會發生安全配置錯誤。這可能包括預設設定、許可權過於寬鬆或暴露了本應保密的敏感資訊。

舉例說明: 考慮一個基於雲的 API 服務,其儲存桶可公開訪問,預設情況下包含敏感的客戶資料。安全配置錯誤可能會使任何人都能線上訪問這些儲存桶,從而導致資料洩漏。

安全配置錯誤的影響是巨大的,因為它可能導致資料洩露或未經授權的訪問。

庫存管理不當

如果企業沒有完整準確的 API 清單,或者沒有管理和淘汰舊 API 的流程,就會出現這種情況。如果企業沒有管理舊端點或廢棄端點的流程,攻擊者仍可訪問這些端點。這樣,攻擊者就可以利用這些端點,在未經授權的情況下訪問敏感資料或功能。

當組織沒有管理 API 金鑰的流程時,也會出現庫存管理不當的情況;這些金鑰可能會暴露給公眾。這可能會讓攻擊者竊取這些金鑰,並利用它們對 API 進行未經授權的訪問。

不安全地使用 API

當與外部 API 整合的 API 實施或後端系統沒有驗證和消毒其輸入或驗證端點時,就會發生這種情況。

此外,如果未驗證 API 伺服器的真實性,攻擊者就可以冒充合法的 API 伺服器,向客戶端傳送惡意請求。

舉例說明: 網路應用程式使用 API 驗證使用者身份。網路應用程式沒有驗證傳送到 API 的使用者輸入。攻擊者向網路應用程式提交惡意輸入,然後將其傳遞給 API。API 不會驗證輸入,因此惡意輸入會在 API 伺服器上執行。惡意輸入會讓攻擊者控制 API 伺服器。然後,攻擊者利用 API 伺服器竊取網路應用程式使用者的敏感資料。

該漏洞一旦被利用,可導致資料被盜和遭受各種注入攻擊。

緩解策略

緩解策略對於保護您的應用程式介面免受常見安全風險的影響至關重要。通過採取積極主動的措施,您可以大大降低漏洞被利用的可能性。以下是應對最常見 API 安全風險的實用策略:

防止破壞物件級授權

要防止這一漏洞,必須實施嚴格的訪問控制和身份驗證措施。減少 BOLA:

  • 基於令牌的身份驗證:使用者登入成功後,系統會簽發數字簽名令牌,用於驗證和控制對特定物件的訪問,從而確保系統內安全和授權的互動,有助於減少物件級授權的中斷。
  • 使用者訪問控制列表(ACL):可通過明確定義和規範使用者或使用者組對特定資源的訪問許可權來緩解這一漏洞,確保精確和授權的互動,同時防止未經授權的訪問。
  • 執行測試:定期稽覈和測試授權機制,以發現並糾正漏洞。

可用於測試 BOLA 漏洞的工具有:

防止資料過度暴露

  • 實施適當的資料過濾和訪問控制。
  • 只提供每個使用者的角色或請求所需的資料。
  • 確保不會無意中暴露敏感資料,並定期審查資料訪問策略。

加強身份驗證安全

  • 多因素身份驗證:通過要求使用者提供多種形式的身份驗證(如密碼和時間敏感程式碼),這大大增強了身份驗證的安全性,即使密碼被洩露,也能增加一層額外的保護,防止未經授權的訪問。
  • 限制登入嘗試:通過對登入嘗試實施限制,可以降低未經授權訪問的風險,使攻擊者通過重複和自動登入嘗試猜測或破解密碼的難度增加。
  • 會話管理:這可確保使用者會話得到適當的驗證和授權,通過實施安全的會話管理實踐(如唯一的會話識別符號和會話超時)最大限度地降低未經授權訪問的風險,從而防止會話劫持和未經授權的會話重用。

工具

防範注入攻擊

輸入驗證是防範 SQL 注入和跨站指令碼 (XSS) 等注入攻擊的關鍵。驗證和消毒使用者輸入可防止惡意程式碼或意外字元被執行。正確的輸入驗證可確保使用者提供的資料在可接受的引數範圍內,從而消除篡改查詢或注入惡意指令碼的企圖。

參考資料

防範 SSRF 攻擊

  • 防火牆:防火牆作為內部網路與外部實體之間的保護屏障,對減輕伺服器端請求偽造(SSRF)攻擊至關重要。可以對防火牆進行配置,以檢查和過濾進出流量,幫助防止與 SSRF 相關的惡意請求。
  • 白名單:實施白名單是加強伺服器端請求偽造(SSRF)攻擊防禦的有力策略。使用白名單可定義應用程式可訪問的認可 URL 和 IP 地址。這樣可以減少攻擊面,阻止未經授權的 SSRF 嘗試。

確保正確的安全配置

確保正確的安全配置需要遵循安全伺服器和應用程式配置的最佳實踐。以下是一些確保最佳實踐的方法:

  • 更新和打補丁:更新和打補丁對於降低與已知漏洞相關的安全風險至關重要。定期更新有助於彌補這些安全漏洞,降低未經授權訪問、資料洩露和其他威脅的可能性。
  • 刪除預設賬戶:如果不刪除,預設賬戶可能成為攻擊者的潛在入口。威脅者通常會利用預設憑據(通常為公眾所知)來獲得未經授權的訪問。刪除預設賬戶可消除可預測的進入點,從而降低風險。

參考資料

案例研究

Azure API 管理 SSRF 漏洞

Ocra Security 的研究發現,有可能訪問微軟產品之一(Azure)的內部網路資源,從而可能危及該雲服務的安全性。該漏洞於 2022 年 11 月 12 日報告。

研究人員發現,該漏洞可能允許攻擊者獲取有關 Azure 線纜端點(Azure 服務用於通過 WAAgent 進行通訊的內部靜態 IP 地址)的資訊,如已安裝的擴充套件、證書及其相應的私鑰。

APIM 工程團隊已於 2022 年 11 月 16 日完成部署修復程式,以充分阻止對虛擬機器上本地埠/資源的訪問。

Parler API 攻擊

Parler 是一個社交媒體平臺,其 API 暴露給公眾,允許攻擊者訪問和下載大量使用者資料、帖子和媒體檔案。該事件暴露了 Parler API 安全性的重大缺陷,尤其是在驗證過程(Broken Authentication)和資料訪問控制方面。點選此處瞭解有關此次攻擊的更多資訊。

小結

Azure API 管理中的 SSRF 漏洞和 Parler API 攻擊的案例研究強調了 API 安全的極端重要性。這些事件的主要啟示包括:

  • 需要進行全面的安全評估。
  • API 開發中嚴格的輸入驗證。
  • 監控和識別異常或未授權 API 請求的重要性。

開發人員必須不斷了解潛在漏洞,同時投資於強大的訪問控制、資料過濾和安全配置實踐。API 安全並非一朝一夕之功,需要持續致力於保護應用程式和使用者資料的安全。

評論留言