美國聯邦網絡安全審查委員會最近的一份報告指出，當前Log4j漏洞對產業界的影響并未結束，這一漏洞或許在未來十年甚至更長的時間內持續引發安全風險，誰也不知道下一個Log4j或Spring4Shell漏洞何時會出現。唯一能夠確認的是，在接下來的每一次0Day安全事件中，組織內部的應用程序和編程接口 （API） 都將受到全面破壞。

　　隨著互聯網技術的發展，API作為連接服務與傳輸數據的核心通道，在企業的發展過程中愈發重要的角色。但事實上，API可能具有與傳統 Web 應用程序幾乎相同的所有漏洞，包括 SQL 注入、服務器端請求偽造、不安全的反序列化等等，其背后隱藏著不可忽視的安全風險。

　　API安全當前主要面臨以下四個方面的嚴峻挑戰：

　　01 真正的攻擊很難識別。每個 API 都有其獨特的漏洞，只能通過特定的攻擊來利用。比如，對一個 API 完全無害的 HTTP 請求或許對另一個 API 可能是毀滅性的；

　　02 現代 API 使用的格式十分復雜，如 JSON、XML、序列化對象和自定義二進制格式等。這些請求使用 HTTP 之外的各種協議，包括 WebSocket，它由瀏覽器、富客戶端、移動應用程序和許多其他來源中的 JavaScript 生成。

　　03 傳統的防御根本無效。Web 應用程序防火墻 （WAF） 通過在 HTTP 流量到達 API 服務器之前對其進行分析，從而完全獨立于 API 運行。盡管大多數大型組織都有 WAF，但許多組織缺乏進行必要調整以保持其運行所需的團隊和專業知識，只能將其置于“日志模式”。

　　04 軟件正在快速發展，容器、基礎設施即服務 （IaaS）、平臺即服務 （PaaS）、虛擬和彈性環境出現爆炸式增長。新的信息技術應用允許快速部署 API，但它們也進一步擴大了代碼暴露面。

　　因此，為了應對API安全帶來的挑戰，避免給業務造成無法承受的損失，組織必須積極對已知和未知的漏洞進行探測和防御，阻止攻擊者每一次對利用漏洞發起攻擊的意圖。

　　RASP技術如何補充

　　傳統安全方案在API方面的不足

　　隨著API安全理念的興起，網絡安全企業都逐漸豐富了在API領域的防護能力，但業內一些傳統的入侵檢測方案和傳統的應用防火墻（WAF）在進出API接口分析流量和數據方面的表現仍然不佳。

　　相較而言，運行時應用程序自我保護 （RASP）技術正在API安全防護中承擔越來越多的工作。RASP 提供了兩個關鍵功能：

　　首先，它可以準確了解攻擊組織的人在組織的 API 上使用的攻擊向量，以及組織的哪些 API 是攻擊者正在嘗試突破的目標。其次，RASP 可以在漏洞利用的環節阻止攻擊者，這一能力在當前大多數主要類別的漏洞，包括零日漏洞和自定義代碼漏洞方面都能夠發揮作用。

　　RASP的工作方式與WAF的不同之處在于，RASP 使用工具將輕量級探針添加到組織的 API 代碼和平臺中，這些探針可以直接測量 API 的安全相關行為并檢測惡意事件。與部署在邊界的安全防御設備不同，它可以準確跟蹤攻擊并防止漏洞被利用，從而讓用戶確定攻擊是否實現。

　　得益于此，RASP能夠立即檢測、阻止和緩解攻擊，通過分析攻擊行為和上下文來實時保護攻擊，可以無需調整或重新配置即可抵御廣泛的零日攻擊。通過使用應用程序或 API 持續監控自己的行為，RASP 能夠保護 API 免受數據盜竊、惡意輸入和行為的影響，同時也無需人工干預。并能夠為 AppSec、SecOps 和開發團隊提供準確、詳細的信息，包括有效負載、完整的 HTTP 請求、確切的代碼行、執行的查詢、訪問的文件等等。

　　作為一種更深入的安全工具，RASP自動將可見性和保護直接編織到 API 中，這極大限度地減少了0Day漏洞帶來的不眠之夜，為開發和安全運營人員提供了喘息的空間。

　　事實上，早在 Log4Shell 和 Spring4Shell 漏洞爆發的時候，就已經證明了RASP技術的有效性，它從根本上防止了攻擊者通過表達式語言注入和不安全的反序列化等各種方式對漏洞進行惡意的利用。對于用戶而言，無需更新漏洞補丁這件事情的價值已經無需多言，再沒有什么安全技術能夠像RASP這樣讓他們感到安心。

更多信息可以來這里獲取==>>電子技術應用-AET<<