許多Web應用防火墻（WAF）很容易被攻擊者繞過。閱讀本文后，你就可以知道如何判斷自己的WAF是否易受攻擊以及如何修復它了。
基于云的Web應用防火墻（WAF）提供了一系列出色的保護，然而許多黑客聲稱，他們連最復雜的WAF都能輕松繞過，能對受保護的資產執行攻擊查詢，而不受到懲罰。
應用程序交付和安全平臺NetScaler的威脅研究團隊發現，許多基于云的WAF確實很容易被繞過。如果你打算購買WAF服務，就需要運行測試以確保WAF能夠起到應有的功效，以保護你的應用程序和API。
建議你對自己的環境進行一番簡單的測試，以檢查WAF服務是否提供最佳保護。
在本文末尾概述了幾個經常被忽視的簡單步驟，以幫助你確定是否有人已經繞過了WAF，并危及Web應用程序和API的安全性。
首先不妨看看攻擊者繞過WAF防御的最常見方法。
最常見的WAF攻擊
基于云的WAF和本地的WAF是作為一項服務提供的安全解決方案，旨在幫助保護Web應用程序和API免受開放Web應用程序安全項目（OWASP）記載的各種攻擊。最常見的WAF攻擊包括如下：
- 注入
說到通過像Web應用程序這樣的入口竊取大量數據，SQL注入是一種切實可行的方法。注入攻擊最早記錄于25年前，至今仍被廣泛使用。
數據庫查詢的開始，常常被設計成檢索所有信息，然后是過濾器僅顯示一條信息。比如說，一個常用的查詢首先檢索所有客戶信息，然后過濾特定的客戶ID，數據庫對照表中的每一行執行此命令，并返回該語句為真的表行上所請求的信息，通常這是單單一行。攻擊者操縱用于填充此類查詢以插入數據庫命令的表單字段，導致對表中的每一行計算結果為true的語句，從而在響應中返回整個表的內容。在理想情況下，開發人員總是會保護表單安全，因此注入攻擊不可能得逞。然而，開發人員有時可能容易出錯，因此并非所有表單字段都一直受到保護。
最新的OWASP十大列表如今在注入類別中包含了跨站腳本攻擊。在跨站腳本攻擊中，攻擊者將腳本插入到你的網站或Web URL中，以便毫無戒備的受害者在瀏覽器中執行這些腳本，從而允許攻擊者將cookie、會話信息或其他敏感數據傳輸到他們自己的Web服務器。
- 失效的訪問控制
失效的訪問控制允許攻擊者在應用程序或API開發人員的預期行為之外進行操作。該漏洞可能導致未經授權的信息泄露、所有數據被篡改或破壞，以及能夠越權執行業務功能。
OWASP最近將失效的訪問控制嚴重性提升到了Web應用程序十大漏洞的第一位。新發現的重要性在于，這個漏洞類別特別適用于API——與已經存在了很長時間的Web應用程序相比，API是一條比較新的攻擊途徑，攻擊者發現API并試圖從中泄露信息。由于API不是為人工輸入而設計的，因此用于Web應用程序的相同類型的驗證輸入和檢查可能不是開發人員最關心的，有時API是在安全團隊和運維團隊不知情的情況下發布的。
- 易受攻擊和過時的組件
每當在常用組件中發現新的漏洞，就會導致大量機器人生成的流量掃描互聯網，尋找可能被破壞的系統。如果你搭建了一臺Web服務器，允許別人通過互聯網來訪問，很快就會看到向新搭建的Web服務器上，并不存在的特定類型的應用程序發出請求的日志條目，這種活動只是黑客在互聯網上廣撒網，尋找易受攻擊的服務器。
WAF的主要功能是檢查HTTP請求的內容——包括攻擊載荷所在的請求體和請求頭，并決定是應該允許請求還是阻止請求。一些WAF還會檢查響應，以評估是否存在未經授權的數據或敏感信息泄露，它們還將記錄響應結構（比如Web表單或cookie），從而有效地確保后續請求不被篡改。
WAF的三種類型
Web應用程序和API防火墻通常有三種模式：消極模式、積極模式和混合模式：
- 消極安全模式
使用簡單的簽名，并預加載已知攻擊，如果存在匹配，將阻止請求。你可以把這當成“拒絕列表”。換句話說，默認操作是“允許”，除非找到匹配項。
- 積極安全模式
積極安全模式預加載已知“良好”行為的模式。它將請求與該列表進行比較，只有在找到匹配項時才允許請求通過，其他的一切統統被阻止，這將被視為“允許列表”。在這種情況下，默認操作是“阻止”，除非找到匹配項。積極安全模式被認為比消極安全模式安全得多——它可以阻止零日攻擊。
- 混合安全模式
使用簽名作為第一遍機制，然后處理請求以查看它是否與允許列表匹配。你可能會問：“既然攻擊不在允許列表中，為什么使用允許列表？”原因是所需的處理更少，因為消極安全模式使用簽名來阻止請求，而不是像積極安全模式那樣處理一切。更多的處理意味著更龐大的WAF設備或更高的基于云的托管成本。
所有三種WAF安全模式都有一個共同點：它們檢查入站請求并查找威脅。請求端檢查的有效性取決于WAF在尋找什么以及它們檢查請求負載的細粒度。
攻擊者如何利用WAF限制和IT部門缺少摸底調查大做文章？
攻擊者意識到，對于大多數組織來說，尋找流量中的攻擊需要龐大的計算開銷，而商業檢查解決方案旨在盡可能高效地匹配實際用例。他們知道實際的HTTP（s）GET或POST請求通常只有幾百字節，對于一些大的cookie而言可能是1-2千字節。
攻擊者知道，許多WAF解決方案在尋找攻擊流量時，只會掃描一小部分有限的字節。如果WAF沒有找到匹配項，或者根據NetScaler的測試，如果請求大于8kb，許多WAF將不會掃描請求，它們會認為這是異常，僅僅轉發而已。
需要著重強調的是：許多WAF只是簡單地轉發請求，不阻塞，也不記錄。
WAF“黑客活動”解釋
為了繞過WAF，攻擊者利用SQL注入或跨站腳本，用垃圾內容填充請求，使其超過8kb的大小，然后點擊發送，填充請求就像在登錄表單中添加一個巨大的請求頭或cookie或其他POST正文文本一樣簡單。請求不被掃描，而是被傳遞到執行負載的后端服務器。
一些WAF經配置后可以應對填充攻擊，但默認情況下這種保護并沒有開啟。至于為什么會這樣，我只能得出這樣的結論：開啟這種保護需要額外的處理，這也就增加了WAF用戶的成本。供應商不希望其WAF被認為比競爭對手更昂貴，因此任由額外的保護被禁用。
請注意，如果不更改默認設置，你的Web應用程序和API將完全暴露。
一些解決方案采用的單遍式WAF架構其表現比傳統的代理策略好得多，這就是為什么可以在不增加成本的情況下直接防范填充攻擊。
這些WAF漏洞是新漏洞嗎？
填充攻擊并不新穎，WAF供應商很清楚這個問題，但整個WAF行業還沒有滿足默認開啟最有效保護的要求。
一些分析師已經向相關的供應商提出了安全方面的缺口，供應商的回應是“這是一個已知的限制，如果客戶想要這種保護，應該運用這條特定規則。”但是解決方法常常隱藏在WAF配置指南的具體細節中，管理員和部署操作員可能（也確實）忽略了它。
如今，用戶希望系統開啟后“完全可用”，IT部門使用的每個解決方案都能簡化任務，并減少管理開銷，因此需要從一開始就保護WAF。當然，如果合法的請求需要更龐大，那么它將被阻止。這時候可能會出現例外，當管理員這么做時要意識到風險。但是任由整個站點暴露在外是絕對不允許的。
攻擊者知道許多WAF在默認情況下沒有啟用保護，這就是為什么他們借助填充攻擊利用這個漏洞。NetScaler測試的幾個WAF不容易受到這種攻擊方法的影響，但很多WAF都容易受到影響，一些WAF的請求限制稍微大一些（128 kb），但是一旦請求體被填充，就同樣很容易繞過。一些解決方案傾向這種“fail open”方法，以避免額外處理帶來的額外成本，防止意外的誤報，并允許更簡化（不過不太安全）的設置。
然而，“fail open”方法違反了安全供應商理應提供的網絡安全“強默認”原則。在選擇WAF時，你需要確保默認情況下已受到保護，可以防范填充攻擊。
保護WAF的3個簡單步驟
你的WAF解決方案可能沒有正確配置，從而使Web應用程序和API完全暴露在攻擊者面前，他們可以通過SQL注入和跨站腳本輕松部署填充攻擊。
當你急匆匆地檢查WAF配置時，必須要做以下三件事：
- 用填充請求測試你的Web應用程序（包括內外的Web應用程序）。
- 檢查Web應用程序日志，查找意料之外的龐大請求：比如說，查看登錄POST表單，它通常只包含用戶名和密碼，大小從大約20字節到300字節不等。如果你看到POST請求的大小大于8kb，那么這可能是填充攻擊嘗試。
- 評估是否可以更改配置以應對填充攻擊，如果可以，確保比較前后的成本，以便獲得加大保護所需的確切成本。
如果遵循這篇簡單的指南文章，你就可以正確地配置WAF，以提高Web應用程序和API的安全性。
