《Akamai：鉆過安全漏洞-應用程序和API攻擊呈上升趨勢（2024）（31頁）.pdf》由會員分享，可在線閱讀，更多相關《Akamai：鉆過安全漏洞-應用程序和API攻擊呈上升趨勢（2024）（31頁）.pdf（31頁珍藏版）》請在三個皮匠報告上搜索。

1、鉆過安全漏洞：第 9 卷，第 2 期 SOTI1互聯網現狀第 9 卷，第 2 期應用程序和 API 攻擊呈上升趨勢鉆過安全漏洞：第 9 卷，第 2 期 SOTI1目錄漏洞頻現的一年Web 應用程序和 API 流量分析 數字化時代的應用程序和 API 攻擊風險：對不同行業的攻擊有何不同留意（安全）缺口：API 攻擊研究引發對風險的關注結語和更多建議：填堵邊緣缺口方法致謝名單2414202829301鉆過安全漏洞：第 9 卷，第 2 期 SOTI鉆過安全漏洞：第 9 卷，第 2 期 SOTI2漏洞頻現的一年 Log4Shell 和 Spring4Shell 等重大漏洞的出現印證了 Web 應用程序

2、和 API 所帶來的嚴重風險，也體現出這些威脅面的重要影響。為了加強整體運營，企業依然在積極采用更多 Web 應用程序。平均而言，每家企業使用的應用程序數量已經達到了 1061 個，充分體現出這一攻擊面在不斷擴大?，F有安全漏洞依然讓攻擊者有機可乘，層出不窮的新興零日漏洞更是雪上加霜，促使企業比以往更需要加強應用程序安全性，以保護機密數據和安全邊界。2022 年，應用程序和 API 攻擊數量創下新高。2021 年末，Log4Shell 爆出后不久，企業就發現自己四面楚歌，還有其他多個重大漏洞威脅著他們的安全，其中包括：Atlassian Confluence漏洞(CVE-2022-26134)、

3、ProxyNotShell 漏洞(CVE-202241040)和 Spring4Shell/SpringShell(CVE-2022-22965)等。API 漏洞利用攻擊的數量不斷增加，即將發布的新版開放式 Web 應用程序安全項目(OWASP)API 十大安全漏洞已將 API 漏洞納入其中，這表示 API 安全風險已經引起了業界的極大關注。隨著攻擊頻率的激增，攻擊的復雜性也在提高，攻擊者在不斷“進化”，努力尋找更多新方法來利用這一不斷擴大的攻擊面。例如，攻擊者團體使用 Web shell（例如 China Chopper）發動高度有針對性的攻擊，比如 Hafnium團體就曾對美國的國防和教育

4、機構發起過此類攻擊。此外，服務器端模板注入(SSTI)和服務器端代碼注入有可能導致遠程代碼執行(RCE)和數據滲漏，給業務帶來嚴重威脅。近期的一個例子是在VMwareWorkspaceONEAccessandIdentityManager中發現的 RCE 漏洞(CVE-2022-22954)。在 API 威脅環境中，受損的對象級別授權是企業的主要顧慮，其原因是多方面的，包括這類漏洞的檢測難度大、影響大（攻擊可能造成攻擊者獲得敏感數據的訪問權限）?？紤]到多種非傳統攻擊媒介的使用量增加，企業有必要升級應用程序和 API 領域的防御機制。在本期互聯網現狀/安全性(SOTI)報告中，我們將繼續研究我們

5、在 Web 應用程序和 API 領域發現的各類攻擊，探索它們對于企業的影響，以及各種漏洞在 API 環境中的定位。我們的目標是闡明 Web 應用程序和 API 攻擊造成的危險，并提供一些針對性建議，幫助您保護網絡，成功抵御此類攻擊。鉆過安全漏洞：第 9 卷，第 2 期 SOTI3 服務器端請求偽造(SSRF)攻擊是一種新近出現的攻擊媒介，給企業帶來了重大威脅。2022 年，Akamai觀察到，針對我們客戶 Web 應用程序和 API 的 SSRF 攻擊嘗試達到平均每天 1,400 萬次，這些攻擊可能會導致攻擊者入侵企業內部資源。開源軟件中的漏洞（如 Log4Shell）以及允許遠程代碼執行(R

6、CE)的 SSTI 技術日漸盛行。我們預計在未來幾年中，這些攻擊還會不斷增長，建議企業采取相應的防護措施。2022 年，隨著物聯網(IoT)通信的蓬勃發展，以及從制造業設備中收集到的數據愈發驚人，這使得針對制造業發起的攻擊數量中位數增加了 76%。針對此行業內運營技術(OT)實施的網絡攻擊頻頻得手，帶來了供應鏈問題等現實影響。在醫療領域，醫療物聯網(IoMT)的采用擴大了該垂直行業的攻擊面，給攻擊者創造了通過漏洞發起攻擊的機會。2022 年，這個行業的攻擊數量中位數增加了 82%。API 研究得出的見解包括：擬議的新版 OWASP API 十大安全漏洞強調了 Web 應用程序與 API 之間的

7、攻擊媒介差異。以 API 業務邏輯為導向的 API 攻擊非常復雜，很難在個別請求層面上檢測和抵御。需要提前建立相關認知，例如具體業務邏輯，以及每位用戶可訪問的資源。主要研究見解3鉆過安全漏洞：第 9 卷，第 2 期 SOTI鉆過安全漏洞：第 9 卷，第 2 期 SOTI4Web 應用程序和 API 流量分析Web 應用程序憑借易訪問性、效率和可擴展性成為企業的一股中堅力量，幫助企業獲得了更多收入。從網絡犯罪分子的角度來看，他們總是“跟著錢走”，尋找一切機會去實現自己的最終目標。Akamai始終在監控和觀察這些攻擊的大規模增長和頻率（圖 1），在之前發布的威脅報告中，我們已經分享了相關信息。4D

8、aily Web Application AttacksJanuaryDecember 2021 vs.JanuaryDecember 2022Fig.1:Year over year,web application attacks show an upward trend with several spikes in between,possibly indicating sporadic campaigns1 億1.5 億5000 萬02022 年2021 年4 月3 月1 月2 月5 月6 月7 月8 月9 月10 月11 月12 月攻擊數量1 月圖 1：Web 應用程序攻擊數量呈現年同

9、比上升趨勢，中間有數個高峰，可能表明零散的攻擊活動每日 Web 應用程序攻擊數量 2021 年 1 月至 12 月與 2022 年 1 月至 12 月的對比鉆過安全漏洞：第 9 卷，第 2 期 SOTI鉆過安全漏洞：第 9 卷，第 2 期 SOTI5攻擊者不斷優化攻擊方法，相應地，Web 應用程序和 API 防御也必須不斷加強檢測能力，從而緩解攻擊者不斷“進化”的攻擊手段帶來的風險。2022 年，Akamai發布了全新的 AkamaiApp&APIProtector 產品，加強了攻擊檢測能力。攻擊數量的激增也讓我們確定了更多攻擊流量，其增幅約為 250%。但這并不是Akamai第一次看到 We

10、b 應用程序和 API 攻擊的這種急劇增加。早在 Log4Shell 和 Spring4Shell 等重大漏洞興起，并給全球各行各業（如科技公司等）造成大規模數據泄漏之前，Web 應用程序和 API 攻擊就已經在急劇擴增。此外，這些漏洞加劇了企業面臨的風險，進一步強調了確保應用程序安全的重要性。圖 1 還展示了每日攻擊流量的高峰和低谷。不過我們偶爾也會看到一些明顯的高峰（圖 2），這可能表明針對一家大型企業或多家Akamai客戶發起的大規模攻擊活動。2022 年 4 月，我們在一天的時間內看到了 1.35 億次攻擊；同年 7 月，我們在一天內觀察到 1.36 億次攻擊。在我們遭遇的攻擊中，還有

11、 1.61 億次攻擊于 2022 年 10 月 8 日開始，于 2022 年 10 月 9 日達到高峰。這些攻擊有可能是大爆炸式攻擊活動，其中針對企業的攻擊活動量可達到正常情況的 30 倍以上。Fig.2:We observed three significant spikes in 2022(April 2,July 28,and October 9),which could indicate big-bang cam-paigns against one or several companiesDaily Web Application AttacksJanuary 1,2022 Dece

12、mber 31,20221 億1.5 億5000 萬07 天平均值每日攻擊數量2022 年 4 月2022 年 3 月2022 年 1 月2022 年 2 月2022 年 5 月2022 年 6 月2022 年 7 月2022 年 8 月2022 年 9 月2022 年 10 月2022 年 11 月2022 年 12 月2023 年 1 月攻擊數量2022 年 4 月 2 日134,971,2632022 年 7 月 28 日 135,762,3822022 年 10 月 9 日 160,785,750圖 2：2022 年，我們觀察到三次明顯的高峰（4 月 2 日、7 月 28 日和 10

13、月 9 日），這可能是針對一家或幾家公司的大爆炸式攻擊活動每日 Web 應用程序攻擊數量 2022 年 1 月 1 日2022 年 12 月 31 日鉆過安全漏洞：第 9 卷，第 2 期 SOTI6有兩個重要因素促成了這種增長。首先，越來越多的企業依靠應用程序和 API 來改進客戶體驗、助推業務發展，這使得應用程序開發生命周期需要縮短在生產環境中創建和部署此類應用程序的周期，因而可能導致代碼不夠安全。在 EnterpriseStrategyGroup(ESG)調查中，有 48%的受訪企業表示，由于時間限制，他們將存在漏洞的應用程序發布到了生產環境，將網絡置于風險之中。其次，漏洞數量在增加，每

14、10 個漏洞中就有 1 個是在面向互聯網的應用程序中發現的“高風險”或“重大”類別的漏洞。此外，2018 年至 2020 年期間，Log4Shell 等開源漏洞的數量增加了一倍。我們的金融服務業相關報告兵臨城下：針對金融服務領域的攻擊分析強調，在新漏洞披露后的 24 小時內，我們開始看到有關這些漏洞的利用嘗試。由于這兩大因素，API 和應用程序被攻擊者利用的時機已經成熟。對于 Web 應用程序和 API 攻擊量增長，推動作用最明顯的攻擊媒介是 LFI，攻擊者主要將其用于偵察或掃描存在漏洞的目標。在某些情況下，實施 LFI 漏洞利用攻擊可能暴露關于任何應用程序的信息，造成目錄遍歷攻擊，攻擊者可借

15、此獲得日志文件數據，從而侵入網絡 中更深入的部分。（在下一部分中，我們將更深入地分析這一媒介及其他普遍存在的攻擊 媒介。）考慮到這些攻擊的速度和規模，企業不但要完成內部分段和補丁安裝，還有必要具備在邊緣攔截這些攻擊的能力。由于應用程序為數眾多，您還需要良好的資源清冊。了解攻擊面及其具有哪些對應的安全控制措施至關重要。如今有許多公司都在整理“軟件材料清單”，目的就是準確分析任何零日漏洞的潛在影響。接下來，您還需要 Web 應用程序和 API 防護(WAAP)這樣的工具，理想的工具應該能隨著新攻擊變體的出現實時更新對新威脅的應對 措施。最后，您需要制定相應流程來驗證確實有效的防御措施，包括滲透測試

16、和日志分析 在內。在有新攻擊媒介初露端倪時，只要有可能影響到企業，您就應該仔細加以考察。通過了解這些新攻擊媒介，您就可以為未來的攻擊面做好充分準備。鉆過安全漏洞：第 9 卷，第 2 期 SOTI72023 年需要留意的攻擊媒介通過研究，我們探索了攻擊者在攻擊的位置、生成這些攻擊的方式，以及他們選擇執行的具體攻擊。在有新攻擊媒介初露端倪時，只要有可能影響到企業，您就應該仔細加以考察。了解新攻擊媒介可以幫您做好準備，應對未來可能出現的攻擊面，這也是企業保護自身網絡的方法。如圖 3 所示，LFI 攻擊目前在大幅增加，年同比增幅達到 193%。也就是說，相較于 2021 年，攻擊數量激增 2 倍之多，

17、先前排名靠前的跨站點腳本攻擊(XSS)和 SQL 注入(SQLi)這兩種攻擊媒介均已落于 LFI 攻擊之后。LFI 攻擊可能會給企業造成不利影響攻擊者利用 LFI 在目標網絡中獲得立足點，或是通過 RCE 向 Web 服務器注入惡意代碼，從而破壞其安全機制。在最糟糕的情況下，LFI 攻擊可能將敏感信息暴露給攻擊者。注意：LFI 攻擊數量的增加意味著攻擊者已經成功利用它發起過攻擊，所以您應該優先開展測試，判斷自己的系統中是否存在漏洞。在攻擊者利用文件訪問權限驗證或處理的漏洞發起攻擊時，就會發生 LFI 攻擊。我們發現，基于 PHP 的網站普遍存在 LFI 漏洞，80%的網站在服務器端使用這種編程

18、語言。我們連年看到大量攻擊，這并不令人意外。相關數據泄露報告稱，3 億用戶帳戶外泄的事件可追溯到 LFI 攻擊上。Fig.3:LFI remains the top attack vector as attackers look for ways to infiltrate their intended targets Top Web Attack VectorsJanuaryDecember 2021 vs.JanuaryDecember 20222021 年2022 年50 億0100 億150 億200 億LFIXSSSQLiPHPi惡意文件上傳RFICMDiOGNLi2021 年與 2

19、022 年的攻擊數量總數對比圖 3：在攻擊者尋找入侵預定目標的方法時，LFI 依然是首選攻擊媒介 主要 Web 攻擊媒介 2021 年 1 月至 12 月與 2022 年 1 月至 12 月的對比鉆過安全漏洞：第 9 卷，第 2 期 SOTI8無獨有偶，XSS 讓攻擊者可以在攻擊目標的網絡中獲得立足點，而非獲得數據庫訪問權限。就在幾年前，SQLi 還是 Web 應用程序和 API 攻擊中的主導性攻擊媒介，在 2021 年的 OWASP 名單中，它是三大 Web 應用程序攻擊之一。SQLi 攻擊一旦得手，攻擊者往往能獲得公司的機密信息訪問權限，比如客戶數據。企業需要警惕這些流行的攻擊媒介可能造成

20、的后果，以及攻擊者對于這些媒介的利用方式。仔細審視新攻擊媒介及其對企業的潛在影響至關重要。Akamai堅信企業應當使用諸如ZeroTrust分段之類的框架，以盡可能降低可成功獲得訪問權限的 LFI 攻擊的影響，并將網絡擊殺鏈與 MITREATT&CK相結合，分析和衡量企業安全計劃的成熟度。新興攻擊媒介體現出向 RCE 演進的形勢隨著漏洞利用攻擊的頻率持續增加，攻擊者在不斷“演進”攻擊手段、技術和過程(TTP)，以提高其影響力。在本部分中，我們將審視過去一年中遇到的一些不同以往、新近興起并且高度危險的攻擊技術。了解這些逐漸盛行的攻擊對于準備未來安全防護措施意義非凡。我們希望幫助企業了解網絡犯罪分

21、子如何濫用以下這些攻擊媒介，以便制定相應的抵御策略，為下一個達到 Log4Shell 級別或下一個主導性的攻擊媒介做好準備。服務器端請求偽造(SSRF)服務器端模板注入(SSTI)服務器端代碼注入8鉆過安全漏洞：第 9 卷，第 2 期 SOTI鉆過安全漏洞：第 9 卷，第 2 期 SOTI9Hafnium 濫用 SSRF，對成千上萬的企業發起了攻擊2021 年 3 月，CVE-2021-26855（CVSS 評分：9.1）披露，SSRF 獲得高度關注，安全研究人員 Orange Tsai 稱之為“ProxyLogon”。在Microsoft發布安全補丁解決MicrosoftExchange服務

22、器中這一關鍵 SSRF 漏洞之前，網絡犯罪團伙 Hafnium利用此漏洞發起了攻擊，受影響的企業數量估計達到 6 萬家。該攻擊者團伙利用此漏洞對 Web 服務器運行命令，從而破壞其安全機制。由于 SSRF 的影響引起高度關注，此媒介后續被添加到 9 月發布的“2021 年 OWASP 十大安全漏洞”中，位列第十。攻擊者通常利用 SSRF 漏洞來獲取敏感信息或執行命令。如需進一步了解 SSRF 工作原理，請參閱這篇文章。對于MicrosoftExchange中的 SSRF 漏洞，近期的例子有：ProxyNotShell結合了 CVE-2022-41040（CVSS 評分：8.8）和 CVE-20

23、21-41082（CVSS 評分：8.8）OWASSRFCVE-2022-41080（CVSS 評分：8.8）在過去兩年間，Akamai觀察到攻擊嘗試和獲得授權的漏洞掃描流量（其目的是尋找MicrosoftExchange以外的軟件中的 SSRF 漏洞）都在穩步增長。GitHub上的SSRFmap 等開源工具助長了此類掃描活動。我們還觀察到，探測我們App&APIProtector客戶的 Web 應用程序和 API 的 SSRF 嘗試平均每天達到 1,400 萬次，表明了這種攻擊媒介的普遍程度在不斷提升。這種增長以及 SSRF 利用給企業帶來的潛在影響值得 關注。SOTI9鉆過安全漏洞：第 9

24、 卷，第 2 期 SOTI10SSTI：攻擊者青睞的零日攻擊技術Log4Shell 漏洞、AtlassianConfluence漏洞(CVE-2022-26134)和 Spring4Shell 漏洞(CVE-2022-22965)是近年來影響重大的三個漏洞，它們都影響到了各行各業和整個互聯網上的成千上萬家企業，而且它們都屬于 SSTI。在系統通過不安全的方式將用戶輸入嵌入模板時，就會出現 SSTI 漏洞，并導致服務器上的 RCE。Akamai研究人員觀察到，攻擊者使用這些技術執行各種系統級命令和帶外互動，從而探測并檢查是否有可能實施數據滲漏。在一些個例中，攻擊者利用這些漏洞實施了 RCE。但有

25、些攻擊者喜歡在各種高級持續威脅(APT)攻擊活動中使用多個 Web shell，例如簡單的反彈 shell、China Chopper 和Behinder。（我們將在后續有關 Web shell 的部分中進一步探討這個話題。）這些惡意文件一旦上傳，攻擊者會擇機利用簡單的 GET 請求予以調用（圖 4），如果惡意文件存放在可以運行cron作業的特定文件夾中，則可以在某個特定的實例中執行。圖 5 展示了攻擊負載在 POST 請求中的表現形式。SSTI 威脅看起來或許有些像簡單的 RCE 漏洞，但確實需要密切留意。在互聯網上存在公開可用的漏洞利用、攻擊負載非常簡單，這些特點提高了攻擊者利用這種漏洞的

26、可行性。我們估計，由于 SSTI 的潛在影響和損害，未來它仍將構成重大威脅。建議企業制定包含 Web 應用程序防火墻的安全策略，以防范此類漏洞利用。有必要指出，Log4Shell 和 Spring4Shell 都是在開源工具中發現的漏洞。開源技術的初衷是讓人人都能輕松獲得源代碼，通過合作打造出色的工具、框架和軟件，但它也可能成為漏洞利用的渠道。攻擊者都在密切關注潛在安全漏洞，探索在攻擊中加以利用或將其用作入圖 4：GET 請求及負載(Spring4Shell)圖 5：POST 請求及負載(Spring4Shell)鉆過安全漏洞：第 9 卷，第 2 期 SOTI11侵攻擊目標的敲門磚的可能性。因

27、此，防御者或漏洞研究人員需要和時間賽跑，趕在攻擊者實際將漏洞用于攻擊之前開發出修補程序，創建概念驗證漏洞。由于目前還沒有更安全的流程，防御者需要認識到開源軟件的這個方面，并采取修補以外的策略來防范零日漏洞。同樣，正因如此，目前企業有開發“軟件材料清單”、收緊第三方代碼審核的趨勢。服務器端代碼注入導致 RCE服務器端代碼注入又稱為“服務器端包含攻擊”，攻擊者會利用 Web 應用程序或服務器，在 HTML 頁面中注入并遠程執行代碼或腳本。這使得攻擊者可以執行 shell 命令，并獲得敏感信息（如用戶名和密碼）的訪問權限。攻擊者經常利用用戶輸入字段強行使用此類攻擊。攻擊要想得手，前提條件是 Web

28、服務器未經適當驗證就允許服務器端代碼注入。而這會導致攻擊者訪問和操縱文件系統，還有可能讓攻擊者通過 Web 服務器進程所有者將其登記為已獲準。根據Akamai研究人員的觀察，NodeJS中的服務器端代碼注入激增，并且NodeJS的使用量近期一直呈上升趨勢。攻擊者可能會濫用這些漏洞，在存在漏洞的服務器上運行遠程代碼，這可能會導致反彈 shell 和任意文件讀取等問題（圖 6）。圖 6：允許攻擊者讀取/etc/passwd 文件的漏洞利用攻擊代碼示例，該文件中包含 NodeJS 服務器上用戶的敏感信息鉆過安全漏洞：第 9 卷，第 2 期 SOTI12攻擊者在 APT 攻擊活動中利用 Web she

29、llWeb shell 允許攻擊者通過簡單而有效的方式與 Web 服務器進行交互。與普通 shell 相比，使用 Web shell 的通信依賴于 Web 端口，因此隱蔽性更強，這讓它成為對攻擊者頗具吸引力的攻擊手段。它們允許攻擊者創建 Web 服務器后門，從而實現遠程控制，危險程度極高。此外，它們還可以讓攻擊者橫向移動以訪問內部網絡。較為盛行的 Web shell 有：China Chopper Web shell 和BehinderWebshell。China Chopper 由兩部分組成。第一部分是客戶端，這是一個可執行文件，用來與受到攻擊的 Web 服務器內的實際 Web shell

30、通信。第二部分是 Web shell，它可能采用 PHP 文件的形式。它具有圖形用戶界面和許多命令和控制功能，如密碼暴力破解攻擊、文件管理和代碼混淆。有消息稱，此 Web shell 曾用于發起定向攻擊。Behinder 具有類似的功能，而且額外增加了加密通信。由于這樣的補充，再加上它屬于內存 Web shell，這種 shell 更難發現。優秀的 WAAP/WAF 應該能夠檢測和抵御像 China Chopper 和Behinder這樣的 Web shell。此外，它應該具有自動更新、在生產環境中測試和自動攔截的功能。安全控制措施還應提供分析，生成工件以便向領導層和審計師匯報 工作。HTTP

31、 請求盜取 攻擊者可通過多種方式利用請求盜取攻擊，包括訪問敏感數據、污染緩存的內容，甚至是執行大規模 XSS。由于安全研究人員 JamesKettle 的杰出工作，近年來 HTTP 請求盜?。℉RS，也稱為 HTTP 不同步攻擊）再次成為安全研究熱點。他在 2019 年黑帽會議上做了一次關于 HTTP 不同步攻擊的演講，公布了不同 HTTP 標準實現的漏洞，特別是代理服務器和內容交付網絡(CDN)內的漏洞。這些實現對于代理服務器解析 Web 請求結構的方式有所不同，造成了新的請求盜取漏洞。如需進一步了解 HRS 的工作原理，請閱讀 CAPEC 的這篇文章。鉆過安全漏洞：第 9 卷，第 2 期

32、SOTI13RFC 指明，在處理請求時，Transfer-Encoding標頭必須先于 Content-Length 標頭。代理服務器實現的語義差異導致 HTTP 不同步攻擊場景中出現這種攻擊。了解有多少 CDN 處理轉發到客戶網站的流量非常重要；能為解析順序的重要性提供背景。CDN 服務器還必須維護來自前端客戶端的請求/響應數據與所返回數據之間的映射關系。在 HRS/不同步攻擊中，由于系統返回了額外的響應內容，并且沒能將這些響應內容正確映射到前端客戶端的請求，這種映射會被破壞（圖 7）。為了在平臺層面上防范這種攻擊，Akamai更新了 Global Host(Ghost)平臺，以符合 RFC

33、 2616 規范的合規標準，確保Transfer-Encoding標頭優先。此外，WAAP/WAF 應遵守 RFC 7230 中與標頭解析有關的規定，并應檢測其是否符合如下條件：標頭沒有以“rn”結尾 標頭不包含冒號“:”標頭無名稱使用符合行業標準的工具始終是最佳實踐。后端前端圖 7：不同步攻擊的原理（來源：Portswigger）13鉆過安全漏洞：第 9 卷，第 2 期 SOTI鉆過安全漏洞：第 9 卷，第 2 期 SOTI14數字化時代的應用程序和 API 攻擊風險：對不同行業的攻擊有何不同 COVID-19 疫情促使各行各業加緊實施數字化轉型，以此來適應要求業務連續性的時代。在 2020

34、 年之前，已有幾個行業實現了數字化，但一直到 COVID-19 疫情爆發期間，所有行業（不論規模大?。┎挪患s而同地開始實施數字化。這些企業匆忙實施在線服務和流程，可能未考慮到數字策略的正確實施，因此出現了安全漏洞。這進一步擴大了企業的風險暴露面。一份報告顯示，82%的 IT 高管指出，其企業在引入新技術時遭遇過一次或兩次數據泄露。在本部分中，我們將研究關鍵行業和趨勢，以及網絡犯罪分子有可能如何將 Web 應用程序和 API 攻擊用作入侵企業的途徑。大多數行業遭受攻擊的頻率都出現增長，而商業、高科技和金融服務行業則首當其沖（圖 8）。Fig.8:The top verticals impacte

35、d by web application and API attacks are commerce,high tech-nology,and financial servicesTop Web Attack VerticalsJanuaryDecember 2021 vs.JanuaryDecember 202210%0%20%30%40%高科技商業金融服務制造其他數字媒體視頻媒體公共部門游戲社交媒體商業服務制藥/醫療博彩非營利組織/教育機構其他2021 年與 2022 年的攻擊數量總數對比2021 年2022 年圖 8：商業、高科技和金融服務是受 Web 應用程序和 API 攻擊影響最為嚴重

36、的垂直行業Web 攻擊數量排名靠前的垂直行業 2021 年 1 月至 12 月與 2022 年 1 月至 12 月的對比鉆過安全漏洞：第 9 卷，第 2 期 SOTI15對于中位數數據集的研究固然存在自己的偏差，但提供了不同的視角（圖 9）。它為我們勾勒出一幅不同的景象，讓我們得以了解個別行業在攻擊方面所經歷的情況。例如，我們看到，2022 年針對制造業的攻擊數量超過了高科技和金融服務業，這與我們之前在新一期的 SOTI 報告攻擊快車道：深入了解惡意 DNS 流量及全球勒索軟件報告中的發現相呼應。Fig.9:Median attacks demonstrate a different depi

37、ctionon the range of attack frequency in verticalsTop Web Attack Verticals MedianJanuary 1,2022 December 31,2022 10 萬020 萬30 萬高科技商業金融服務制造其他數字媒體視頻媒體公共部門游戲社交媒體商業服務制藥/醫療博彩非營利組織/教育機構攻擊數量2021 年2022 年圖 9：攻擊數量中位數從不同的視角展示了各垂直行業中的攻擊頻率范圍 Web 攻擊數量排名靠前的垂直行業中位數 2022 年 1 月 1 日至 2022 年 12 月 31 日15鉆過安全漏洞：第 9 卷，第 2

38、期 SOTI鉆過安全漏洞：第 9 卷，第 2 期 SOTI16商業：LFI 在旅游和酒店業中的起起落落Akamai的旅游和酒店業子垂直行業數據表明，這些客戶面向 Web 資產的應用程序和 API 遭遇過大量攻擊。Akamai的數據反映了 2022 年 1 月 LFI 攻擊量的激增(107%)，是前一個月商業領域中更廣泛趨勢的延續，促使此類攻擊遠超之前的主要攻擊媒介 SQLi（圖 10）。在 2022 年全年，LFI 攻擊活動水平持續居高不下。將 2022 年第三季度與 2021 年第三季度相比，LFI 攻擊活動數量的增幅超過 300%。LFI 成為更多攻擊者的首選攻擊媒介，這種整體趨勢或許體現

39、出攻擊者不再希望僅依靠 SQLi 實施數據滲漏攻擊（在針對商業領域的 WAF 攻擊中，此類攻擊一度占到大約 79%的比例），而是改為使用 LFI 來濫用 Web 應用程序中的漏洞，暴露 Web 服務器上的敏感文件，這可能引發目錄遍歷攻擊。LFI 也可用于攻擊鏈，促成 XSS 或 RCE。如前所述，攻擊者也許在借著因新冠疫情引發部署新應用程序和技術的急迫性，來搜索可利用的 LFI 漏洞和其他安全缺口。另一個促成因素或許是容器化環境的迅速擴增，這些環境可能在運行較舊的映像，更容易受到采用較舊方法的攻擊，例如緩沖區溢出，從而增加 LFI 掃描請求。Fig.10:A view of top attac

40、k vectors in the commerce industry from 2019 to the present shows the the rise and fall of LFI,XSS,and SQLi Top 3 Daily Web Application Attack Vectors CommerceJanuary 1,2019 January 1,20235 億7.5 億10 億2.5 億0SQLiXSSLFI2020 年 1 月2019 年 1 月2021 年 1 月2022 年 1 月2023 年 1 月攻擊數量圖 10：從 2019 年到 2023 年初，針對商業領域的

41、主要攻擊媒介的視圖，表明了 LFI、XSS 和 SQLi 攻擊的起落情況單日 Web 應用程序攻擊數量排名前三的攻擊媒介商業 2019 年 1 月 1 日至 2023 年 1 月 1 日鉆過安全漏洞：第 9 卷，第 2 期 SOTI1717金融服務業越來越多的金融機構實現數字化，積極采納改變游戲規則的舉措來擴大業務范疇，如開放銀行服務、銀行業務即服務和不斷增長的嵌入式金融市場，API 已成為對于金融機構有著重大意義的強大工具。JuniperResearch表示，近年來，嵌入式金融解決方案在全球范圍內得到了重視，到 2027 年可以穩穩產生高達 1830 億美元的收入。一項針對中小型企業的全球調

42、查表明，近 50%的中小型企業表示對嵌入式金融產品感興趣，并已很少使用傳統銀行服務。嵌入式金融服務提供商可以獲得高達 250 億美元的收入。這個發展方向確實為銀行和其他金融機構帶來了增長機會，但同時也帶來了風險。在我們 2022 年的最后一期 SOTI兵臨城下：針對金融服務業的攻擊分析中，我們發現針對金融服務的 Web 應用程序和 API 攻擊數量激增 3.5 倍，表明了攻擊者對該行業及其客戶的興趣持續增長。隨著金融服務的攻擊面不斷擴大，我們建議安全領域從業者了解其風險暴露情況，并據此制定抵御策略。我們還建議縮小攻擊面、加強環境感知，以降低應用程序和 API 攻擊造成的風險。關于金融服務機構的

43、更多安全建議，請閱讀Akamai博客文章：近期研究給金融服務業帶來的 7 個重要啟示。17SOTI17鉆過安全漏洞：第 9 卷，第 2 期 SOTI18制造業 盡管制造商要應對的 API 請求數量和規模通常比不上直接面向消費者的垂直行業（例如零售業），但攻擊事件的影響可能會非常嚴重。2022 年的攻擊數量中位數急劇上升令各大企業如鯁在喉。過去，工業控制系統是獨立式硬件和軟件系統，除了設備的個別部件或工廠本身之外，彼此間幾乎沒有聯系。如今，不論是物聯網連接數量，還是從生產設施的各類設備中收集的數據量都呈現激增之勢，訪問來自這些設備的數據的請求也不斷增加。這些數據的用途包括供應商管理、庫存管理、生

44、產流程優化、銷售和訂單管理等。隨著這些連接的出現，針對這些 OT 的漏洞發起網絡威脅的 風險也在增加。利用 OT 數據的應用場景不斷擴增，參與其訪問、處理、分析和使用的非 OT 系統的數量隨之增加。這形成了一種趨勢，制造商正在整合其應對 IT/OT 綜合威脅的策略和響應措施，以適應兩個世界逐漸交融的現狀。尤為值得關注的是利用勒索軟件的攻擊者，以及希望掌握相應能力，通過影響公共事業、管線、煉油廠、水廠、交通運輸網和其他關鍵民用基礎設施等基本服務的交付來擾亂社會的境外民族國家的威脅。如果說圖 9 中針對制造商的 Web 攻擊數量中位數激增帶給我們什么啟迪，那就是這個行業需要立即著手加強防御 措施。

45、SOTI18鉆過安全漏洞：第 9 卷，第 2 期 SOTI19醫療/制藥業IoMT 的興起是醫療行業的重要進步之一，它將醫療相關應用程序和設備連接起來，讓醫生與患者能通過網絡實時獲取信息。目前的一間病房中平均大約有 15 至 20 臺聯網醫療設備，包括智能病床、胰島素泵和呼吸機。IoMT 技術確實給患者、醫療服務提供商和醫生帶來了新的機會和高效、無縫的體驗，但同時也擴大了這個領域的攻擊面。使用第三方應用程序和供應商會造成的安全漏洞，而攻擊者可能利用這些第三方的漏洞發動攻擊。許多醫療服務提供商都在使用大量傳統系統、高度聯合的系統，現在還在整合 IoMT 數據，因此，強大的分段技術和數據流監測變得

46、非常重要?；颊甙踩陵P重要，不容有失。醫療機構一旦被入侵，可能會引發無數惡果，比如機密的患者信息和醫療記錄丟失、運營和聲譽蒙受重大損害等等。美國有數項醫療法規，包括擬議的2022 年醫療服務網絡安全法，其中規定了醫療服務提供商在網絡安全方面需要優先考慮的準則，并就如何保護醫療設備和電子病歷提供了一些策略建議。領導層會向 CISO 提出的一個關鍵問題是：“我們公司的網絡安全風險比其他公司如何？”關于行業趨勢的這個部分提供了一些與此相關的必要數據，可以幫您有理有據地探討貴公司與其他行業和同行相比較的排名。SOTI19鉆過安全漏洞：第 9 卷，第 2 期 SOTI20留意（安全）缺口：API 攻擊研

47、究引發對風險的關注OWASP 將 API 攻擊納入候選名單（其十大攻擊排名的草案），這是行業朝著專門關注 API 的方向邁出的重要一步，突破了以往側重于應用程序的思路，強調了 API 威脅的獨特性質（圖 11）。提到 API 的性質，有必要指出一個基本要點：其保護頗具難度，針對 API 發起的攻擊可能相當復雜。為了充分實施保護，您需要了解 API 的內部業務邏輯，因為每一家客戶的 API 內部業務邏輯都可能有所不同，安全解決方案可能需要更高水準的計算產品。OWASP 強調了 API 安全中的幾個關鍵思路，包括：不應信任第三方和內部服務；云環境、容器和Kubernetes應納入 API 安全領域

48、（就概括的層面而言），而且對于 URL 傳遞(SSRF)的高風險有所影響。本部分將探討列入前五位的幾種 API 攻擊（對象、屬性、身份驗證和授權）。我們先來看一下 API 授權的復雜性質，以及識別和測試錯誤的 API 邏輯造成的漏洞時的難度。Fig.11:The proposed new Top 10 includes more API-specific attacks and emphasizes authorization issues(four of the top five attacks)201920231234567891012345678910受損的對象級別授權受損的用戶身份驗證

49、數據泄露過多缺乏資源和速率限制受損的功能級別授權批量分配安全配置錯誤注入不當的資產管理日志記錄和監控不足受損的對象級別授權受損的身份驗證受損的對象屬性級別授權不受限制的資源消耗受損的功能級別授權服務器端請求偽造安全配置錯誤缺乏對自動威脅的防范資源清冊管理不當API 的使用不安全圖 11：新擬議的“十大安全漏洞”中包含更多與 API 相關的攻擊，并著重強調了授權問題（在前五大攻擊中占據四席）2019 2023鉆過安全漏洞：第 9 卷，第 2 期 SOTI21受損的對象級別授權 在 OWASP API 十大安全漏洞中，受損的對象級別授權(BOLA)是排名第一位的 API 漏洞。容易遭受 BOLA

50、攻擊的 API 讓攻擊者能操縱 API 請求內發送的對象 ID，從而在未經授權的情況下獲得敏感數據的訪問權限。例如，某個不具備特權的用戶通過這種方式訪問、更新或刪除了另一位用戶的數據，這就可以視為 BOLA 攻擊（圖 12）。BOLA 被視為高風險攻擊。一旦攻擊者成功利用了這種攻擊手段，就能訪問其他用戶的信息，例如其存儲的個人身份信息。不同于加密破解或自動化/程序化攻擊（如分布式拒絕服務和撞庫）等技術性更強的攻擊不同，BOLA 攻擊與應用程序邏輯的缺陷有關。在攻擊中利用 BOLA 相對比較簡單，但要檢測它十分艱難。BOLA 請求與合法流量非常相似，很難從惡意請求中區分出這類請求。要檢測 BOL

51、A 攻擊，防御者需要預先了解應用程序的業務邏輯和每個用戶可訪問的資源。檢測邏輯必須區分資源和用戶之間的一對一連接和一對多連接。事后 BOLA 攻擊很難發現，因為其攻擊量極低，不會表現出明顯的行為異常跡象，比如注入或拒絕 服務。GET/account/BOLA 攻擊GET/account/GET/account/AliceAlice 的帳戶EveEve 的帳戶圖 12：正常請求對比 BOLA 攻擊鉆過安全漏洞：第 9 卷，第 2 期 SOTI22重點檢測 JSON Web 令牌中受損的身份驗證例如，API 身份驗證可驗證用戶的身份，或確認帳戶訪問者是不是獲得授權的用戶。但如果 API 身份驗證中

52、存在漏洞，會發生什么情況？攻擊者可以濫用它來劫持用戶的帳戶信息，將其數據置于風險之中。本部分將介紹受損的身份驗證，這是 OWASP API 攻擊名單中排名第二位的攻擊。API 中的一種標準身份識別方法是JSONWeb令牌(JWT)。我們會深入探索Akamai的流量，并介紹一些常見應用場景和幾個已知漏洞，幫您更好地了解其潛在風險。Akamai 流量調查 JWT通常帶有簽名，但這并不表示它們經過加密；簽名只是用來驗證內容未經篡改或修改。已知用于為JWT簽名的算法有 HS256（使用 SHA256 的 HMAC）和 RS256（使用 SHA256 的 RSA）等。我們的數據流量表明，大多數(55%)

53、的 API 請求采用 HS256 算法來為其相關 JWT進行簽名和驗證，RS256 的使用比例緊隨其后（26%；圖 13）。HS256 是一種對稱算法，使用一個密鑰來驗證和生成簽名。RS256 的非對稱算法要求使用私鑰和公鑰。Fig.13:Most of Akamais customers use HS256 JWT authentication,followed by RS256JWT AlgorithmsRS25626.1%HS25654.8%HS5125.2%ES5120.8%ES2565.2%RS5127.9%圖 13：大多數 Akamai 客戶使用 HS256 JWT 身份驗證，其次

54、是 RS256JWT 算法鉆過安全漏洞：第 9 卷，第 2 期 SOTI23對稱算法的使用率要高于非對稱算法，這有些令人意外，原因或許出于我們的客戶對系統復雜性和計算方面的考量（圖 14）。請注意，如果密鑰足夠長，那么使用適當的安全對稱密鑰是可以接受的做法（JWT已通過 TLS 加密）。這也能減少了客戶方面的復雜性，因為用戶僅需一個密鑰。Fig.14:60%of API requests use a symmetric,rather than an asymmetric,algorithm Algorithms Symmetric vs.Asymmetric不對稱40.0%對稱60.0%圖 1

55、4：60%的 API 請求使用對稱算法，而不是非對稱算法 算法對稱與非對稱的對比23鉆過安全漏洞：第 9 卷，第 2 期 SOTI鉆過安全漏洞：第 9 卷，第 2 期 SOTI24我們的數據表明，使用JWT對稱加密的行業主要分為兩類：一類是傳統上在網絡安全領域投資不多的行業，如制造業和公共機構；另一類是生成海量數據的行業，如視頻媒體、博彩和其他數字媒體，因為其處理成本更低（圖 15）。金融服務業可能有更加嚴格的安全規定，因此使用非對稱加密的做法更為普遍。請注意，對于這兩種類型的JWT加密，JWT本身均通過非對稱 TLS 加密會話傳輸。Fig.15:Symmetric and asymmetri

56、c usage per industrySymmetric and Asymmetric by Vertical對稱不對稱高科技商業金融服務制造其他數字媒體視頻媒體公共部門游戲社交媒體商業服務制藥/醫療博彩非營利組織/教育機構圖 15：各行業的對稱算法與非對稱算法的使用情況按垂直行業劃分的對稱算法與非對稱算法使用情況24鉆過安全漏洞：第 9 卷，第 2 期 SOTI鉆過安全漏洞：第 9 卷，第 2 期 SOTI25JSON Web 令牌與 JSON Web 加密的比較JSONWeb加密(JWE)是JWT的加密版本，使用并不廣泛。大多數公司都選擇節省計算能力，并使用JWT（圖 16）。JWE的一

57、個應用場景是公司希望避免仿冒攻擊發起者成功讀取JWT。風險類型 為了填補安全缺口，避免可能被攻擊者用作入侵點的安全漏洞，一個重要步驟就是在應用程序生命周期的早期階段確定編碼錯誤。但有一項調查顯示，僅有 14%的開發人員在編碼過程中會優先考慮應用程序安全。這種做法并不合理，在任何應用程序生命周期中，安全都應該作為一個需要積極關注的關鍵領域。在本部分中，我們將探討幾種可能被引入您的安全邊界的 API 攻擊。信任或者不驗證用戶的簽名算法此類攻擊會設法讓系統信任用戶的簽名算法，從而在不執行驗證的情況下使用JWT和數據令牌。這類似于將前門大敞四開，認定只有合法居民才會進入，甚至更糟糕，盲目信任陌生人會把

58、門鎖好并交還鑰匙。雖然這種攻擊很容易實施，但它可能產生不利后果，如訪問特權提升。在某些情況下，如果通過JWT標頭改變算法，還有可能導致帳戶接管。Fig.16.The usage of JWE vs.JWT seen in the traffic on Akamai edgeJWT vs JWEJWE10.5%JWT89.5%圖 16：在 Akamai 邊緣流量中觀察到的 JWE 與 JWT 的使用情況對比鉆過安全漏洞：第 9 卷，第 2 期 SOTI26身份驗證流風險在某些情況下，開發人員會為不同的 API 使用相同的私鑰。但攻擊者可以濫用這一點，利用用戶 ID 和來自另一個應用程序的合法JW

59、T接管帳戶（圖 17）。安全的算法眾所周知，非對稱算法的安全性高于對稱算法，因為前者使用兩個密鑰，增加了對算法實施攻擊的復雜性。最初，使用高熵長密鑰的對稱算法足夠安全，但假以時日，它也會變得不再安全。云計算讓攻擊者能夠通過幾年前還無法想象的速度破解使用弱私鑰的簽名 令牌。避免在有效負載中存儲敏感數據開發人員可能會無意中在JWT中存儲信息，如內部開發數據、增量式 ID 或服務器字段。編碼但未加密的JWT可能會導致潛在敏感數據泄露給攻擊者。攻擊者可以利用自身獲得的 API 相關信息，對存在漏洞的 API 發起更復雜的攻擊。注入攻擊JWT中的密鑰ID(kid)參數用于告訴服務器端應用程序，在驗證過程

60、中使用的是哪個密鑰為JWT簽名。但這個kid參數也有可能成為潛在注入攻擊的根本原因，因為它用于查詢服務器端數據庫。根據Akamai的觀察，像 SQL 和操作系統注入這樣的攻擊會在服務器端 運行。注冊這兩個應用程序使用應用程序 1 JWT 并接管帳戶攻擊者應用程序 1授權：JWT_X（用戶 ID=1234）應用程序 2授權：JWT_Y（用戶 ID=4321）應用程序 2 授權：JWT_X（用戶 ID=1234）圖 17：攻擊者有可能使用其他應用程序的合法令牌來實現帳戶接管鉆過安全漏洞：第 9 卷，第 2 期 SOTI27保護企業免受 API 風險的侵擾編碼中的一個簡單錯誤可能成為攻擊者在企業網絡

61、中發起攻擊的立足點。應用程序與 API 中的缺口會形成漏洞，并讓攻擊者有機會找到方法來突破外圍防御，在您的網絡內傳播并獲取機密信息。同時，Web 應用程序和 API 仍然是企業必須設法防御的關鍵攻擊面，而要想降低風險，及時修補安全漏洞就變得至關重要。像 App&APIProtector 這樣的 Web 應用程序和 API 解決方案可以阻止請求或流量到達其目標應用程序，從而阻止攻擊。務必將安全措施落實到位，例如及時更新 Web 應用程序防火墻規則。了解應用程序和 API 攻擊的工作原理，包括 LFI、SQLi 和 XSS 以外漸成氣候的攻擊媒介，這樣防御者就能掌握必要的知識，保護其企業免受 Lo

62、g4Shell 這樣的攻擊侵擾。對于 API 特定風險，您可以參考以下一些建議：在使用令牌前使用預定義的算法驗證令牌 為每個身份驗證環境（以及不同的應用程序）分別使用不同的私鑰 使用非對稱算法（如果從計算資源角度來看是合理的），使用高熵長私鑰 如果用到了kid參數，為其生成一個唯一標識符 避免在有效負載中透露敏感數據；此類數據應該保存在數據庫中 記錄并監控JWT違規行為，以便日后檢查為了抵御 BOLA 攻擊帶來的風險，下面來介紹一些相關的最佳實踐：對使用客戶輸入的 API 執行授權檢查，以確定當前用戶是否有權訪問請求的資源 使用通用唯一標識符(UUID)作為資源 ID，而不是連續數字 ID 編

63、寫并運行測試以評估您的 API 端點是否存在 BOLA 漏洞在各個行業，Web 應用程序和 API 攻擊的數量都在急劇增加，這表明隨著企業進一步采納“左移”的做法，開發更多的應用程序，每一家企業都不能免于這些攻擊的影響只是或早或晚的問題。鉆過安全漏洞：第 9 卷，第 2 期 SOTI28結語和更多建議：填堵邊緣缺口 不要等到危機降臨才來思考如何抵御不同類型的新漏洞或零日漏洞，無論是對協議、產品還是固件中存在的漏洞，企業都應未雨綢繆。盡管這些抵御措施需要的策略都略有不同，但是建立流程大有助益。我們建議企業盡快采用 Web 應用程序和 API 保護/Web 應用程序防火墻(WAAP/WAF)、內部

64、分段/安全圍欄和修補的做法，在邊緣處抵御攻擊媒介。下一個重大漏洞隨時可能出現，您需要立即構建或驗證自己的應對策略。本報告審視了流行的攻擊媒介，如本地文件包含(LFI)，以及新興的攻擊技術，如服務器端請求偽造(SSRF)、服務器端模板注入(SSTI)和服務器端代碼注入。您應該檢查自己的日志，觀察這些技術的趨勢，看看與本報告的分析是否相符。您也可以通過滲透測試和紅隊驗證我們的檢測和抵御控制措施的有效性。盤點行業趨勢（數字化時代的應用程序和 API 攻擊風險：對不同行業的攻擊有何不同部分中探討了相關內容），為貴公司合理排定檢測和抵御控制措施的優先次序。行業趨勢總能給我們展現耐人尋味的見解。網絡犯罪分

65、子根據入侵的費力程度、數據的價值或支付贖金的可能性來評估哪些目標能給他們帶來最佳的投資回報，所以攻擊趨勢經常會發生變遷。但密切留意“鄰居”遇到的情況非常重要，因為或早或晚，同樣的情況會發生在您的身上。不如把握機會，從他們的事情中汲取經驗。醫療業是值得關注的一個行業，醫療物聯網(IoMT)帶來的復雜性可以作為很好的案例，供我們探索管理新型數據源的方法。鉆過安全漏洞：第 9 卷，第 2 期 SOTI29朝著 DevOps 和 API 的轉型促使 OWASP 單獨評估了 API 風險，并將其與人們更為熟知的 OWASP Web 漏洞進行比較；根據 API 攻擊的活動情況以及這些比較的結果，OWASP

66、 將其列入新版十大名單。在考慮如何確定優先級時，不妨先參照 OWASP 更新后的建議。JSONWeb令牌(JWT)可以重點檢測“受損的身份驗證”，這是一個絕佳的案例，可以展現您在多大程度上仍然需要進行安全代碼開發，并且開發最佳實踐和技術控制，以確保您的應用程序與風險偏好相匹配。在與客戶交流時，客戶不斷告訴我們安全控制措施整合的價值，自動化對于適應攻擊速度的必要性，以及監測能力對決策和性能評估的重要意義。我們希望這份報告中的數據能夠帶來深入見解，幫助您更新自己的程序并開發最佳實踐。如需了解更多見解，敬請訪問我們的安全研究中心，隨時了解我們的最新研究資訊。方法Web 應用程序攻擊數量此數據表示通過

67、我們的 Web 應用程序防火墻觀察到的流量的應用層警報數量。在針對受保護的網站或應用程序的請求中檢測到惡意負載時，系統就會觸發警報。警報并不表示攻擊已經成功。雖然這些產品允許的定制程度極高，但我們在收集此處提供的數據時，所采用的方式并未考慮受保護資產的定制配置。這些數據提取自我們的一個內部工具，該工具用于分析在 AkamaiIntelligentEdgePlatform上檢測到的安全事件。這是一個由 340,000 臺服務器構成的龐大網絡，覆蓋全球 134 個國家/地區的 1,300 個網絡中的 4,000 個地點。我們的安全團隊使用這些數據（每月達到 PB 級）來研究攻擊，標記惡意行為并將其

68、他情報饋送到Akamai解決方案中。2022 年 5 月的一次重大攻擊體量過大，因此部分可視化圖表中未包含其數據。出于所有分析的目的，我們仍在數據集中保留了這次攻擊的數據。鉆過安全漏洞：第 9 卷，第 2 期 SOTI30Akamai 支持并保護網絡生活。全球各大優秀公司紛紛選擇 Akamai 來打造并提供安全的數字化體驗，為數十億人每天的生活、工作和娛樂提供助力。Akamai Connected Cloud 是一種大規模分布式邊緣和云平臺，可使應用程序和體驗更靠近用戶，幫助用戶遠離威脅。如需詳細了解 Akamai 的云計算、安全和內容交付解決方案，請訪問 和 年 4 月。|30致謝名單編輯與

69、創作EliadKimhyLanceRhodesBadetteTribbey審稿和主題撰稿NoamAtiasSusanMcReynoldsRyanBarnettNitzanNamer CherylChiodiNeerajPradeepPaulDonnellyIdoSolomonTomEmmonsCarleyThornellDennisGerman SteveWinterfeldAlexMarks-BluthMaximZavodchik數據分析RobertLesterChelseaTuttle營銷與發布GeorginaMoralesHampeShivangiSahu更多互聯網現狀/安全性互聯網現狀/安全性報告由Akamai精心呈獻，獲得了各界的廣泛贊譽，您可以回顧往期報告，并關注即將發布的新報告。 訪問此報告中的數據查看本報告中引用的圖片和圖表的高畫質版本。這些圖片可供免費使用和引用，但必須注明轉載來源，并保留Akamai徽標。 Web 應用程序和 API 攻擊推出的解決方案，請訪問我們的“應用程序和 API 安全”頁面。掃碼關注獲取最新CDN前沿資訊