Python 實(shí)時(shí)聊天室搭建：發(fā)布訂閱頻道API實(shí)戰(zhàn)應(yīng)用
你可能也喜歡這些API文章!
為了提高人們對(duì)最嚴(yán)重的API安全威脅的認(rèn)識(shí)，開放全球應(yīng)用程序安全項(xiàng)目 (OWASP) 調(diào)查并發(fā)布了最嚴(yán)重的 API 安全風(fēng)險(xiǎn)列表。您應(yīng)該查看OWASP 十大 API 安全風(fēng)險(xiǎn)，以掌握最嚴(yán)重的威脅并相應(yīng)地保護(hù)您的 API。
影響 API 的安全問題不止于此，因?yàn)檫@不是一份詳盡的清單。
盡管如此，為了方便起見，這里還是列出了 OWASP 2023 年十大 API 安全風(fēng)險(xiǎn)：
OWASP 2023 年十大 API 安全風(fēng)險(xiǎn)
| 風(fēng)險(xiǎn) | 描述 |
|---|---|
| 1：2023 對(duì)象級(jí)授權(quán)損壞 | API 往往會(huì)暴露處理對(duì)象標(biāo)識(shí)符的端點(diǎn)，從而創(chuàng)建對(duì)象級(jí)訪問控制問題的廣泛攻擊面。每個(gè)使用用戶 ID 訪問數(shù)據(jù)源的函數(shù)都應(yīng)考慮授權(quán)檢查。 |
| 2：2023 身份驗(yàn)證失敗 | 身份驗(yàn)證機(jī)制通常實(shí)施不當(dāng)，導(dǎo)致攻擊者能夠竊取身份驗(yàn)證令牌或利用實(shí)施缺陷暫時(shí)或永久地冒充其他用戶的身份。系統(tǒng)識(shí)別客戶端/用戶的能力一旦受損，整個(gè) API 安全就會(huì)受到損害。 |
| 3:2023 損壞的對(duì)象屬性級(jí)別授權(quán) | 此類別結(jié)合了 API3:2019 過度數(shù)據(jù)泄露和 API6:2019 – 批量分配，重點(diǎn)關(guān)注根本原因：對(duì)象屬性級(jí)別的授權(quán)驗(yàn)證不足或不當(dāng)。這導(dǎo)致信息泄露或被未經(jīng)授權(quán)的各方操縱。 |
| 4:2023 不受限制的資源消耗 | 滿足 API 請(qǐng)求需要網(wǎng)絡(luò)帶寬、CPU、內(nèi)存和存儲(chǔ)等資源。其他資源（如電子郵件/短信/電話或生物識(shí)別驗(yàn)證）由服務(wù)提供商通過 API 集成提供，并按請(qǐng)求付費(fèi)。成功的攻擊可能導(dǎo)致拒絕服務(wù)或運(yùn)營成本增加。 |
| 5:2023 功能級(jí)別授權(quán)損壞 | 具有不同層次、群組和角色的復(fù)雜訪問控制策略以及管理功能和常規(guī)功能之間的不明確劃分往往會(huì)導(dǎo)致授權(quán)漏洞。通過利用這些問題，攻擊者可以訪問其他用戶的資源和/或管理功能。 |
| 6:2023 不受限制地訪問敏感業(yè)務(wù)流 | 易受此風(fēng)險(xiǎn)影響的 API 會(huì)暴露業(yè)務(wù)流程（例如購買門票或發(fā)表評(píng)論），但無法彌補(bǔ)過度自動(dòng)化使用功能可能對(duì)業(yè)務(wù)造成的損害。這不一定是實(shí)施錯(cuò)誤造成的。 |
| 7：2023 服務(wù)器端請(qǐng)求偽造 | 當(dāng) API 在未驗(yàn)證用戶提供的 URI 的情況下獲取遠(yuǎn)程資源時(shí)，可能會(huì)發(fā)生服務(wù)器端請(qǐng)求偽造 (SSRF) 漏洞。即使受到防火墻或 VPN 的保護(hù)，攻擊者也可以強(qiáng)迫應(yīng)用程序?qū)⒕脑O(shè)計(jì)的請(qǐng)求發(fā)送到意外目的地。 |
| 8:2023 安全配置錯(cuò)誤 | API 及其支持系統(tǒng)通常包含復(fù)雜的配置，旨在使 API 更加可定制。軟件和 DevOps 工程師可能會(huì)忽略這些配置，或者不遵循有關(guān)配置的安全最佳實(shí)踐，從而為不同類型的攻擊打開大門。 |
| 9:2023 庫存管理不當(dāng) | API 往往比傳統(tǒng)的 Web 應(yīng)用程序暴露更多的端點(diǎn)，因此正確且更新的文檔非常重要。主機(jī)和已部署 API 版本的正確清單對(duì)于緩解諸如棄用的 API 版本和暴露的調(diào)試端點(diǎn)等問題也很重要。 |
| 10:2023 API 的不安全使用 | 開發(fā)人員往往更信任從第三方 API 收到的數(shù)據(jù)，而不是用戶輸入，因此傾向于采用較弱的安全標(biāo)準(zhǔn)。為了入侵 API，攻擊者會(huì)攻擊集成的第三方服務(wù)，而不是直接入侵目標(biāo) API。 |
本節(jié)重點(diǎn)介紹 API安全的最基本原則，您應(yīng)將其視為為設(shè)計(jì)和實(shí)施 API 建立安全基礎(chǔ)的基石。
授權(quán)和訪問控制決定用戶或系統(tǒng)可以訪問哪些操作或資源：
令牌是實(shí)現(xiàn)授權(quán)的常用方法，在需要身份驗(yàn)證的設(shè)置過程中獲取。它們將攜帶有關(guān)授權(quán)策略的信息，并在授予用戶或系統(tǒng)訪問權(quán)限之前由 API 進(jìn)行驗(yàn)證。
最常見的令牌類型是：
JWT 提供了一種安全傳輸信息的多功能方式，在復(fù)雜的環(huán)境中特別有用。
根據(jù)您的 API 所需的安全措施實(shí)施一種或多種機(jī)制的組合。
通過加密數(shù)據(jù)，防止攻擊者讀取客戶端和 API 之間交換的數(shù)據(jù)（傳輸中的數(shù)據(jù)）和存儲(chǔ)的數(shù)據(jù)（靜態(tài)數(shù)據(jù)）。
選擇強(qiáng)大的加密算法、確保密鑰安全以及使用經(jīng)過驗(yàn)證的加密庫是全面數(shù)據(jù)保護(hù)策略的關(guān)鍵方面。無論是信用卡詳細(xì)信息、用戶憑據(jù)還是敏感的業(yè)務(wù)信息，傳輸和靜態(tài)加密的應(yīng)用都可以確保您的 API 以機(jī)密性和彈性處理關(guān)鍵數(shù)據(jù)，以抵御潛在攻擊。
保護(hù) API 不僅限于授權(quán)、訪問控制和加密。另一個(gè)需要考慮的重要方面是輸入驗(yàn)證，以防止通過將惡意代碼注入應(yīng)用程序來利用漏洞進(jìn)行注入攻擊。
例如，如果未充分驗(yàn)證 API 請(qǐng)求中的輸入（例如查詢參數(shù)），則可能成為注入攻擊的潛在入口點(diǎn)。通過驗(yàn)證輸入數(shù)據(jù)，您可以確保其符合預(yù)期的格式和標(biāo)準(zhǔn)，從而防范注入漏洞（例如 SQL 注入）。
定義并實(shí)施嚴(yán)格的輸入驗(yàn)證策略，并確保您選擇高度安全且完善的庫。
本節(jié)概述了 API 安全的最佳實(shí)踐列表，其中包含一些原則和可操作的策略，可增強(qiáng) API 抵御安全威脅的彈性和可靠性。
前三項(xiàng)最佳實(shí)踐證實(shí)并強(qiáng)調(diào)了我們?cè)谟懻?API 安全基礎(chǔ)時(shí)提到的安全基礎(chǔ)的重要性。但是，您還必須研究其他最佳實(shí)踐并考慮應(yīng)用它們，因?yàn)樗鼈儗⑷嫣岣吣?API 安全性。
根據(jù)預(yù)定義的角色或?qū)傩詫?shí)施精細(xì)控制并限制對(duì) API 資源的訪問。這可確保用戶或系統(tǒng)僅具有必要的權(quán)限。
遵守最小特權(quán)原則，確保僅向用戶或系統(tǒng)授予執(zhí)行特定任務(wù)或功能所需的最低訪問權(quán)限。這樣，您可以顯著降低未經(jīng)授權(quán)的訪問和數(shù)據(jù)泄露的風(fēng)險(xiǎn)。
使用 HTTPS 等加密協(xié)議來保護(hù)傳輸中的數(shù)據(jù)并實(shí)施加密。在與 API 和應(yīng)用程序的所有通信中使用 TLS（傳輸層安全性）。TLS 可確保傳輸過程中數(shù)據(jù)的機(jī)密性（無法讀取）、完整性（無法更改）和身份驗(yàn)證（我們期望的來源）。
對(duì)于靜態(tài)數(shù)據(jù)，請(qǐng)選擇成熟的加密算法和工具來加密磁盤和數(shù)據(jù)庫。還請(qǐng)考慮對(duì)特別敏感的數(shù)據(jù)進(jìn)行標(biāo)記化，這會(huì)將數(shù)據(jù)替換為對(duì)攻擊者毫無意義的標(biāo)記，只有授權(quán)方才能將這些標(biāo)記映射回原始數(shù)據(jù)。
仔細(xì)檢查并過濾請(qǐng)求中提供的數(shù)據(jù)，以防止注入漏洞。實(shí)施徹底的輸入驗(yàn)證，以確保數(shù)據(jù)符合預(yù)期的格式和標(biāo)準(zhǔn)。
實(shí)施機(jī)制來控制 API 請(qǐng)求的頻率和數(shù)量。速率限制（也稱為節(jié)流）有助于降低濫用和拒絕服務(wù)攻擊的風(fēng)險(xiǎn)。這可以通過應(yīng)用程序來實(shí)現(xiàn)，需要花費(fèi)大量的實(shí)施時(shí)間。不過，它可能會(huì)讓您對(duì)特定情況進(jìn)行精細(xì)控制，甚至將速率限制與應(yīng)用程序概念或邏輯聯(lián)系起來。
或者，您可以使用 API 網(wǎng)關(guān)/防火墻，這通常更簡單，并提供更完整的解決方案，以最小的努力保護(hù)整個(gè) API（參見最后的最佳實(shí)踐）。
建立系統(tǒng)化的日志記錄實(shí)踐并實(shí)施監(jiān)控工具，以檢測(cè)和應(yīng)對(duì)異常活動(dòng)或潛在的安全事件。定期檢查日志并針對(duì)可疑行為設(shè)置警報(bào)。確保您的日志始終能夠回答以下問題：誰？何時(shí)？什么？
定期進(jìn)行安全審計(jì)，包括在開發(fā)生命周期內(nèi)進(jìn)行滲透測(cè)試和代碼審查，以識(shí)別和解決潛在漏洞。積極主動(dòng)地應(yīng)對(duì)新出現(xiàn)的威脅和不斷發(fā)展的安全標(biāo)準(zhǔn)。
實(shí)施版本控制，以便在對(duì) API 進(jìn)行更改時(shí)實(shí)現(xiàn)平穩(wěn)過渡。建立明確的生命周期管理實(shí)踐，以淘汰棄用的版本并保持兼容性。
與其他 API 集成會(huì)增加對(duì)第三方提供商的依賴，以及確保系統(tǒng)安全的復(fù)雜性和挑戰(zhàn)。從這個(gè)意義上講，在與第三方 API 集成之前充分評(píng)估其安全風(fēng)險(xiǎn)并規(guī)劃實(shí)施階段所需的緩解措施至關(guān)重要。
僅共享必要信息的原則規(guī)定，API 在執(zhí)行特定交易或交互時(shí)應(yīng)披露最少的信息。這一原則對(duì)于減少敏感數(shù)據(jù)的暴露和限制潛在的攻擊媒介至關(guān)重要。這一原則也稱為最少披露原則。
最后但并非最不重要的一點(diǎn)是，考慮將 API 網(wǎng)關(guān)作為管理和保護(hù) API 生態(tài)系統(tǒng)的中心點(diǎn)，并強(qiáng)化上面描述的一些最佳實(shí)踐。
API 網(wǎng)關(guān)提供多種功能：
API 安全測(cè)試是應(yīng)對(duì)不斷演變的威脅的基礎(chǔ)。如果定期系統(tǒng)地進(jìn)行測(cè)試，您肯定會(huì)提高 API 抵御潛在威脅的穩(wěn)健性。
在API安全方面，可以采用各種測(cè)試方法來發(fā)現(xiàn)漏洞并確保更全面地識(shí)別 API 中的漏洞。
以下是一些需要考慮的測(cè)試類型的列表：
選擇正確的工具和框架會(huì)顯著影響 API 安全測(cè)試的有效性。以下是一些必備工具和框架的列表：
根據(jù)您的安全測(cè)試目標(biāo)、被測(cè)試 API 的性質(zhì)以及測(cè)試團(tuán)隊(duì)的專業(yè)知識(shí)選擇正確的工具和框架。
如果沒有適當(dāng)?shù)?API 安全性，敏感數(shù)據(jù)和功能的網(wǎng)關(guān)將完全被解鎖，任何人都可以輕易進(jìn)入，有時(shí)甚至沒有人注意到，直到為時(shí)已晚。
API 安全不應(yīng)被視為奢侈品，而應(yīng)被視為必需品。由于 API 已成為我們?nèi)找婊ヂ?lián)的數(shù)字環(huán)境中現(xiàn)代應(yīng)用程序和服務(wù)不可或缺的一部分，因此需要采取保護(hù)措施來保護(hù)它們免受數(shù)字世界中眾多威脅和惡意行為者的侵害。
我們希望本指南能為您提供一個(gè)很好的介紹，讓您知道您應(yīng)該擔(dān)心什么，以及如何開始關(guān)注這些網(wǎng)關(guān)的安全性。即使您認(rèn)為自己受到了保護(hù)，那些惡意行為者的技巧和狡猾程度也不容小覷，而且隨著時(shí)間的推移，他們的技術(shù)水平將越來越高。
文章來源：A Comprehensive Intro Guide to API Security
對(duì)比大模型API的內(nèi)容創(chuàng)意新穎性、情感共鳴力、商業(yè)轉(zhuǎn)化潛力
一鍵對(duì)比試用API 限時(shí)免費(fèi)
