API（應用程序編程接口）安全風險在過去兩年中發(fā)生了巨大變化。下面將討論一下當今最重要的 API 安全問題以及如何解決這些問題。
作為一名長期的OWASP成員和應用程序安全從業(yè)人員，我想與大家分享一下我的想法，關于新發(fā)布的OWASP Web App Top 10（應用安全風險Top 10）將會如何影響API security Top 10（API安全風險Top 10）的更新。上一輪API security Top 10發(fā)布于2019年12月。
最近更新了Web App Top 10（應用安全風險Top 10），以反映不斷變化的應用程序和威脅情況。
以目前的形式，API安全風險Top 10與2017年Web應用安全風險Top 10大致有60%的重疊。這在當時是有意義的，因為API的使用才剛剛開始激增，而且對于如何最好地滿足API的安全需求，確實需要指導。
自API安全風險Top 10發(fā)布以來，API的使用和相關的安全問題都發(fā)生了變化。即便如此，從API安全風險Top 10和新的 Web應用安全風險Top 10中可以得出許多相似之處：
在下一輪API安全風險Top 10列表中，我希望術語保持一致，盡管我不期望類似的定位，因為API和Web應用之間存在明顯的差異。我預計新的Web應用程序列表會有一些重疊，但會有一些特定于API的威脅，比如：
讓我們看看對未來列表的預測。
下一輪OWASP API安全風險Top 10預測
API:1 和API:2：識別和認證失敗以及訪問控制中斷
與API身份驗證和授權(quán)錯誤相關的安全事件幾乎與安全錯誤配置一樣常見，這證明了將其放在列表頂部的合理性（并對錯誤配置排名的第5位提出了質(zhì)疑）。組織需要更加關注他們設計和實現(xiàn)API的方式，也許可以使用安全規(guī)范來監(jiān)視缺少的端點身份驗證、授權(quán)和管理功能。
API:3加密失敗
加密失敗一直困擾著Web應用程序。在早期，開發(fā)人員拒絕進行可能需要用戶升級的更改。因此，將強加密作為應用程序（或API）要求是不受歡迎的——但現(xiàn)在不會了。強制升級以改善數(shù)據(jù)保護并可能防止信用違約成為常態(tài)。開發(fā)人員可能會失去一兩個客戶，但不會擔心因為泄露的數(shù)據(jù)交換和糟糕的加密而發(fā)布有關信用卡違規(guī)的消息。同樣，利用API的應用程序現(xiàn)在可以包含證書和強大的加密算法。
API:4缺乏資源和速率限制
此威脅在列表中排名更高，因為API使合法或惡意流量峰值更容易發(fā)生。今年我們看到針對API的惡意流量峰值增加了30倍。如果不應用速率限制，這將是一場災難。組織需要更加努力地對API實施速率限制，因為它不僅有助于抵御惡意攻擊，還有助于控制基礎設施成本超支。
API:5安全配置錯誤
安全配置錯誤的API是我們在客戶群中看到的常見錯誤。根據(jù)我們在新聞中看到的內(nèi)容，這是許多組織的常見錯誤。意外的端點，或那些沒有身份驗證或授權(quán)標志的端點，只是我們看到的幾個錯誤示例。出現(xiàn)這種頻率的原因是，API安全性錯誤配置沒有被大多數(shù)組織檢測到。要想把這條從列表中刪除，組織需要了解和測試他們的 API 功能——不僅僅是滲透測試，而是真正的功能測試。
API:6不安全的設計
隨著“左移”和DevSecOps的廣泛采用，應用程序安全架構(gòu)師的作用迅速發(fā)展。隨著API變得越來越基礎化，了解體系結(jié)構(gòu)、特別是API每個部分的安全性至關重要。當應用程序在內(nèi)部、外部或向第三方/從第三方使用或發(fā)送數(shù)據(jù)時，將訪問或移動該數(shù)據(jù)的所有實例都需要安全設計。這只是一個小例子，當需要體系結(jié)構(gòu)時，還需要考慮登錄、會話管理、授權(quán)和其他方面。
API:7注入
注入在此列表中排名靠后，而在新的AppSec前十名中排名靠前，因為 Web應用程序是通過Web瀏覽器查看的，并且需要JavaScript來呈現(xiàn)部分頁面。這可能會導致跨站腳本攻擊 （XSS），隨后通常會針對后端數(shù)據(jù)庫進行SQL注入。API通常不需要瀏覽器，因此注入是可能的，但可能性較小。API注入通常只發(fā)生在某人對應用程序有深入了解并試圖打破另一種機制時。
API:8資產(chǎn)管理不當
API資產(chǎn)管理從一個良好的清單開始，該清單隨著元素的添加和刪除而更新。大多數(shù)組織都在為他們的應用程序清單而苦惱，很少有人準確了解他們擁有的 API數(shù)量及其所有相關組件。API可見性和資產(chǎn)管理應該是所有 API安全計劃的基石。
API:9日志記錄和監(jiān)控不足
每當問到“發(fā)生了什么？”這一主要安全問題時，只能通過找出可用的日志來得出答案。沒有日志，就很難確定根本原因。日志記錄和監(jiān)視成本低廉，易于實現(xiàn)，并且經(jīng)常需要進行故障排除。我很想看到這一項在下一輪榜單中消失。
API:10數(shù)據(jù)完整性失敗
對于任何圍繞API中的數(shù)據(jù)完整性的事情來說，這最終有點籠統(tǒng)。這可能是第三方庫或其他存在缺陷的依賴項。這可能是持續(xù)集成和交付（CI/CD） 管道未確認源或添加以某種方式易受攻擊的源的問題。這些類型的故障越來越突出，但代碼完整性的概念變得越來越重要。我們有機會扭轉(zhuǎn)這一趨勢。
這個 API Top 10列表，我覺得在不久的將來會在官方OWASP列表修訂中反映出來。其中大部分來自處理被自動化對手攻擊的 API，以及那些希望在組織內(nèi)站穩(wěn)腳跟的 API。
相關鏈接：
OWASP（開放式Web應用程序安全項目- Open WebApplication Security Project）是一個開放社群、非盈利性組織，長期致力于協(xié)助政府或企業(yè)了解并改善網(wǎng)頁應用程式與網(wǎng)頁服務的安全性。近期其發(fā)布的OWASP Web App Top 10（應用程序安全風險Top 10）一文摘譯如下。
2021 年前 10 名發(fā)生了什么變化
有三個新類別，四個類別的命名和范圍發(fā)生了變化，并在 2021 年的前 10 名中進行了一些整合。我們在必要時更改了名稱，以關注根本原因。
A01:2021-失效的訪問控制從第五名上升到 Web 應用程序安全風險最嚴重的類別；提供的數(shù)據(jù)表明，平均3.81%的測試應用程序具有一個或多個通用弱點枚舉 （CWE）。映射到失效的訪問控制的34個CWE在應用程序中出現(xiàn)的次數(shù)比任何其他類別都多。
A02:2021-加密失敗上移一名至第二名，以前稱為A3:2017-暴露敏感數(shù)據(jù)，這并非根本原因。更新后的名稱側(cè)重于與密碼學相關的失敗，因為它之前已經(jīng)隱含了。此類別通常會導致敏感數(shù)據(jù)暴露或系統(tǒng)受損。
A03:2021-注入下滑至第三名。94% 的應用程序針對某種形式的注入進行了測試，最大發(fā)生率為19%，平均發(fā)生率為3.37%?？缯军c腳本編寫現(xiàn)在是此版本中此類別的一部分。
A04:2021-不安全設計是2021年的一個新類別，重點關注與設計缺陷相關的風險。如果我們真的想作為一個行業(yè)“左移”，我們需要更多的威脅建模、安全設計模式和原則以及參考架構(gòu)。不安全的設計不能通過完美的實現(xiàn)來修復，因為根據(jù)定義，從來沒有創(chuàng)建所需的安全控制來防御特定的攻擊。
A05:2021-安全配置錯誤從上一版的第6名上升；90% 的應用程序都針對某種形式的錯誤配置進行了測試，平均發(fā)生率為 4.5%，超過208,000次 CWE 映射到此風險類別。隨著更多轉(zhuǎn)向高度可配置的軟件，看到這一類別上升也就不足為奇了。
A06:2021-易受攻擊和過時的組件之前的標題是使用具有已知漏洞的組件。該類別從2017年的第9位上升，是我們難以測試和評估風險的已知問題。它是唯一沒有任何通用漏洞披露（CVE）映射到包含的CWE的類別。
A07:2021-識別和身份驗證失敗之前是斷開的身份驗證，并且從第二名下滑，現(xiàn)在包括與識別失敗更多相關的CWE。這個類別仍然是前10名的一個組成部分，但標準化框架的可用性增加似乎有所幫助。
A08:2021-軟件和數(shù)據(jù)完整性故障是2021年的一個新類別，專注于在不驗證完整性的情況下做出與軟件更新、關鍵數(shù)據(jù)和 CI/CD 管道相關的假設。來自通用漏洞披露/通用漏洞評分系統(tǒng) （CVE/CVSS） 數(shù)據(jù)的最高加權(quán)影響之一映射到該類別中的10個CWE。A8:2017-不安全的反序列化現(xiàn)在是這個更大類別的一部分。
A09:2021-安全日志記錄和監(jiān)視失敗之前是A10:2017-日志記錄和監(jiān)視不足。此類別已擴展為包括更多類型的故障，難以測試，并且在CVE/CVSS 數(shù)據(jù)中沒有得到很好的表示。但是，此類故障會直接影響可見性、事件警報和取證。
A10:2021-服務器端請求偽造數(shù)據(jù)顯示，發(fā)生率相對較低，測試覆蓋率高于平均水平，并且利用和影響潛力的評級高于平均水平。此類別代表安全社區(qū)成員告訴我們這是很重要的場景，即使目前數(shù)據(jù)中沒有說明這一點。
