Web 應用程式安全性的漏洞
不同的安全性如何導致入侵
公司 A 和公司 B 的案例
這是公司 A 和公司 B 的案例，他們採用的 Web 應用程式和 API 安全方法看似不同，卻有一個同樣細微但至關重要的瑕疵。這一瑕疵導致二者發生了資料外洩（以及所有關聯的負面結果）。
公司 A 具有最安全的 API 保護。他們會封鎖所有的結構描述違規，限制過多要求的速率，並使用最新的威脅情報將已知的惡意 IP 位址列入封鎖清單。如果將基於密碼的 API 驗證取代為相互 TLS，可能會更安全，但他們從未有過外洩。
但其 API 安全性、威脅情報摘要和 WAF 都來自不同的廠商。並且由於廠商更新，通知 API 安全性的威脅情報不再與保護帳戶登入頁面的 WAF 相容。因此，攻擊者能夠在此頁面上使用新的 SQL 資料隱碼攻擊，並取得合法使用者的使用者名稱和密碼。然後攻擊者會將經過結構描述驗證的要求傳送至其 API，並取得大量的敏感性資料。
與此同時，公司 B 的 Web 應用程式得到充分保護，能夠抵禦 DDoS 攻擊。公司 B 也會向希望與公司 B 的應用程式整合的付費使用者公開 API。
攻擊者會在暗網上購買合法付費使用者的 API 金鑰。有了此金鑰，攻擊者就可以針對公司 B 的 API 伺服器發起低速緩慢的 DDoS 攻擊。攻擊者會啟用一個機器人，以不規則的間隔傳送要求。機器人傳送的每個 API 要求都會被 API 伺服器認為是合法的，因為它帶有可容許的 API 金鑰。遺憾的是，公司 B 的後端團隊忘了透過 DDoS 緩解提供者代理 API 伺服器，即使所有其他伺服器都已受到保護。
隨著要求層層堆積，API 伺服器變得不堪重負，最後根本無法為公司 B 的其他使用者提供服務。很多使用者因為失望而取消了付費帳戶。
公司 A 和 B 有什麼共同的問題？
不同的解決方案會導致疏忽和漏洞
在這些範例中，兩間公司的 Web 應用程式和 API 安全性方法是多個廠商的解決方案的拼湊組合。這些解決方案沒有整合，也很容易出現手動錯誤。
為了理解這是個問題的原因，請想想 Web 應用程式和 API 安全架構的一般元件：
WAF：封鎖針對 Web 應用程式和 Web 資產的攻擊
傀儡程式管理：負責挑戰或封鎖可能的惡意機器人
DDoS 緩解：在面臨任何種類的 DDoS 攻擊（無論是巨流量攻擊還是低速緩慢的攻擊）時確保 Web 資產在線
API 保護：包括 API 的限速、結構描述驗證、驗證等
公司 A 和公司 B 採用了所有這些保護。但由於其 Web 應用程式安全解決方案不同（即便是一流的），存在攻擊者可以利用的瑕疵。
對於公司 A 而言，他們的 WAF 和 API 保護都是分層而非整合的，不得不面臨並封鎖攻擊。一間公司可以阻止的攻擊，可能會攻擊另一間公司。公司 B 的 DDoS 保護並未保護其 API 基礎架構，其傀儡程式管理無法偵測源於機器人的 API 要求，並且其驗證較弱，很容易遭到入侵。
這些只是潛在漏洞的幾個範例。Web 應用程式安全性的其他常見漏洞包括：
有限的威脅情報：威脅情報並非最新、未傳送至正確的位置，或者格式不相容。這是公司 A 的情況。
來自太多來源的太多威脅情報：導致誤判、備援和其他低效的情況。
機器人誤判：這會讓使用者感到沮喪，拖慢服務效率並導致執行不嚴。
警示倦怠：一般企業使用來自多個廠商的 45 種網路安全工具，所有工具都會產生警示。太多不同的產品可能會導致人類員工為了完成工作而忽略威脅。
驗證不足：公司 A 和公司 B 都很容易遭受某種形式的認證盜竊。
不可擴展的威脅防禦：硬體網路安全設備會在大型攻擊期間或各種攻擊中造成流量瓶頸，並變得不堪重負。
隨著網路攻擊越來越複雜，這些漏洞變得更加危險。據 McKinsey 研究，目前的攻擊者「包括高度複雜的組織，他們利用人工智慧和機器學習的整合工具和功能。」現代攻擊者通常比目標移動速度更快，並更快地改進策略。
API 的新增風險
API 越來越重要：對於現代組織的 Web 應用程式基礎架構。如今，在由 Cloudflare 處理的所有動態流量中，58% 基於 API，並且該佔比還在繼續增長。實際上，很多組織都自稱是 API 優先。此外，Cloudflare 封鎖的惡意 API 流量百分比要高於 Web 流量，證明攻擊者牢牢瞄準了 API。
由於 API 經常深度內嵌至 Web 應用程式中，因此，必須高度重視其安全性。然而用心良苦的內部團隊通常會快速部署 API——並且通常不會諮詢安全性。結果是：很多 Web 應用程式漏洞都會追溯至較差的 API 安全性。
例如，當攻擊者發現支援即時包裹追蹤的 API 缺少基本授權時，一個 API 相關的漏洞就會攻擊 USPS。登入的使用者可以透使用萬用字元來搜尋參數（這會顯示資料集的所有記錄），查詢任何其他使用者的帳戶資訊。這會讓 6000 萬 USPS 帳戶持有人的資料面臨風險。
整合式解決方案
如果公司 A 和公司 B 將所有 Web 應用程式和 API 安全服務組合到 一個整合式平台，而不是使用拼湊的網路安全產品會怎樣？那些不同的服務都可以相互整合嗎？而有關公司基礎架構狀態的資料會出現在單一位置，這樣就可以快速評估攻擊及其安全狀態了嗎？
公司 A 本可以確保所有 Web 應用程式和 API 安全性架構元件都有最新的威脅情報，並在攻擊開始之前進行阻止——因為攻擊都在一個平台上。公司 B 本可以更輕鬆地將其 DDoS 保護延伸至所有伺服器。
使用一個平台意味著管理更容易，漏洞更少。
這種整合式 Web 應用程式安全性方法需要高度可擴展的基礎架構，以便能夠代理所有類型的流量。在過去的幾十年裡，組織會在需要抵禦新攻擊時或在需要擴大規模時購買設備。但基於雲端的服務可以更輕鬆地擴展，並應能夠代理任何類型的基礎架構。雖然整合式平台並不能保證抵禦所有攻擊，但它肯定會對我們的假定公司有幫助。
不僅僅是個思想實驗：WAAP 變得日益重要
這不僅僅是個假設的思想實驗。Gartner 會將這些整合的服務定義為「Web 應用程式及 API 保護」或 WAAP。2022 年，Gartner 預測，「到 2024 年，在實際執行環境中針對 Web 應用程式實施多雲端策略的組織中，有 70% 會青睞透過 WAAP 設備的雲端 Web 應用程式及 API 保護 (WAAP) 平台服務以及 IaaS 原生 WAAP。」
WAAP 不僅僅是另一個縮略字：整合 WAF、傀儡程式管理、DDoS 保護、API 安全性 和其他服務對於現代組織而言越來越重要。網際網路的全球特性不斷將 Web 應用程式及 API 暴露於來自多個位置以及各種規模和複雜度的攻擊。難怪在 2022 年，IBM 報告稱，有 83% 的受訪公司發生過資料外洩，全球外洩平均損失 435 萬美元，美國平均損失 944 萬美元。
另一種考量：異構基礎架構
如果公司 A 和公司 B 現在從頭構建應用程式和 API，他們可能會將其整個託管在雲端，可能只需一個託管提供者即可輕鬆部署。但實際上，大多數組織都部署了混合基礎架構，其中包括傳統的內部部署資料庫伺服器、以雲端為基礎的協力廠商 API 以及在多個雲端託管的應用程式服務。這些部署具有多種優勢，但也存在各自的安全性挑戰。
例如，指定雲端提供者產品中的原生安全性可能不會延伸至整個基礎架構。首先，探索並對應其所有基礎架構，然後進行防禦，這可能也是一項挑戰。最後，其網路安全產品可能與技術堆疊中的其他解決方案不相容。
因此，除了整合關鍵 Web 應用程式安全功能以外，WAAP 還需要與基礎架構無關，這意味著它必須能夠領先於任何類型的基礎架構或雲端部署。
與基礎架構無關的整合式 Web 安全性
Cloudflare 採用雲端原生且與基礎架構無關，十多年來一直提供 Web 應用程式 安全性，並在單一管理平台內作為一個整合式平台提供所有功能。Cloudflare 還具有觀察大部分網際網路流量的優勢，每秒服務超過 46 百萬個 HTTP 要求，每天平均封鎖 112 十億個網路威脅。這為 Cloudflare 提供了洞察 zero-day 威脅和新攻擊的獨特優勢。
Cloudflare 就影響當今技術決策者的最新趨勢和主題發表了一系列文章，本文為其一。
深入探討這個主題。
Gartner 在 2022 年 Gartner® Web 應用程式及 API 保護 (WAAP) Magic Quadrant™ 中將 Cloudflare 評為「領導者」。
Get the report!
重點
閱讀本文後，您將能夠瞭解：
不同的網路安全解決方案如何造成安全性漏洞
這些漏洞表現方式的範例
Gartner 為何建議整合與基礎架構無關的 Web 應用程式安全性平台