寫在前面的話


對于安全社區來說，Web應用防火墻（WAF）似乎一直以來都是一個大家默認都要使用的東西，而且幾乎也沒有人會反對使用Web應用防火墻。在這篇文章中，我們將給大家提供一個新的視角去看待WAF，并會對Web應用防火墻的使用效率問題與替代性技術進行深入探討。



Web應用程序防火墻誕生于互聯網的早期時間，特別是在2002年ModSecurity項目誕生后得到了普及和廣泛應用。WAF的工作原理本質上是攔截每個HTTP請求（有時也攔截響應）并使用成百上千個正則表達式評估URI、Header和Body，有的時候還會借助機器學習來進行分析和評估。如果請求中的數據包含類似SQL或Shell之類的代碼，服務器可能會阻止我們的請求。


在網絡安全領域的起步階段，WAF似乎是一個好主意。當時的HTTP請求提及很小，而且請求也不頻繁，并且大多包含的都是普通的表單數據。但現在，WAF似乎是一個已經“過時”的東西了，我們似乎還有更好的技術，甚至是目前最先進的WAF都可以使用其他技術來代替。


Web應用防火墻的性能問題


由于WAF會使用數百個正則表達式來對每一個請求執行安全檢測，那么有人可能會問了：“這樣效率不會很低嗎？”沒錯，確實非常低。


除了對每個請求進行處理會減慢速度之外，我們還需要大量額外的RAM來緩沖請求。由于在WAF完成分析之前，緩沖區中的任何字節都無法刷新到后端服務器，因此我們可能會需要好幾個GB的RAM來存儲請求Body。默認情況下，像Nginx這樣的服務器會緩沖請求，但是足夠大的并發請求（例如推送容器映像）可能會使緩沖Web服務器耗盡RAM。當使用WAF時，每臺服務器都會成為緩沖Web服務器，但這與許多類型的應用程序并不兼容。


毫無疑問，現在的計算機設備速度非常快，而且硬件價格也不貴，但我們不應該在WAF上這樣去花費CPU和RAM，除非它們真的可以成為真正有效的安全工具，但事實并非如此...


WAF很容易被繞過


自WAF誕生之日起，WAF廠商就跟威脅行為者陷入了一場持久的“軍備戰”，但似乎一直以來威脅行為者的水平會更高一些。WAF聲稱要阻止各種類型的攻擊以及復雜的語法，比如說SQL、Shell和其他各種編程語言，其中可能還包括各種注釋、字符轉義、編碼問題和其他各種特殊情況。這也就意味著，從安全攻防角度來說，威脅行為者總是擁有顯著的優勢，如果他們足夠聰明，技術足夠硬，他們總能找到方法來繞過WAF所設定的安全規則。


比如說，你可能會覺得Log4shell很好捕捉到，只檢查“${jndi”就可以了，對吧？但不幸的是，Log4J支持嵌套“查詢”，包括將字母轉換為大寫/小寫的查找，例如“${lower:J}”。


這也就意味著，威脅行為者可以圍繞每一個字符插入任意數量的嵌套查詢，并執行攻擊，比如說“${${lower:J}ndi:...”。當然了，這只是繞過WAF規則的其中一個例子罷了，類似的情況還有很多很多。


上面這個例子只是一個非常簡單的語法，你可以想象一下像SQL和PHP這樣復雜的語言還會產生多少種繞過策略，尤其是在威脅行為者具備過硬的編碼技術時，這種情況將更加復雜。


另一種繞過WAF的方法就是將惡意字符Payload填充到請求的Body中，然后讓它大小超過8KB。正如本文之前在性能部分提到的那樣，請求Body必須緩沖到RAM中進行分析，因此WAF必須設置一個截止點，以避免在單個請求上花費無限的CPU和RAM。對于某些 WAF（例如AWS的WAF），該截止點約為8KB。因此，如果我們直接在Log4Shell攻擊字符串前放置8192個良性的字符，那么就可以實現WAF繞過了。


WAF甚至可以被當作攻擊向量


2019年，CapitalOne就曾遭遇過一次非常嚴重的數據泄露，而當時的這一次網絡安全事件據說就是由于WAF的錯誤配置所造成的。研究人員透露稱，威脅行為者當時成功地欺騙WAF并向EC2元數據服務發送了惡意請求，而該服務則允許威脅行為者直接從S3讀取敏感的文件和憑證數據。

雖然這只是網絡安全事件中的冰山一角，但這也說明了一個事實，即WAF實際上具有很大的攻擊面。


大多數的WAF都是龐大而復雜的代碼庫，通常是閉源的，并且是用內存不安全的語言編寫的。由于它們是昂貴的“企業”產品，企業會在其中塞滿各種用戶實際上并不需要的功能，以使它們的市場競爭力更強。但正是因為這些額外的功能，使得WAF反而變成了一個“危險”的安全工具，比如說SolarWinds。


但是目前互聯網上有很多組織都在使用類似的商業安全軟件，這些軟件一旦部署并上線，每天都會解析和處理大量不受信任的輸入，并會授權其訪問所有后端服務器、日志記錄基礎設施、SIEM、警報系統，甚至JIRA的權限。毫無疑問，這已經成為了一件非常可怕的事情。


WAF誤報率較高


在過去的二十年里，開源的WAF規則集得到了大規模擴展，而且也支持檢測更新類型的網絡威脅和攻擊。顯然，所有的這些WAF都在做同樣的事情。這也就意味著， 越來越多的字符串可能會觸發WAF的規則，并阻止我們的請求。如果你想發表一篇討論Log4shell的文章或發表相關的評論，你可能會因為發表的內容中包含了“${jndi”之類的字符串而被WAF屏蔽。因此，隨著新的規則不斷增加，WAF的誤報率自然會持續上升，并且根據研究人員維護ModSecurity的大量規則列表所得到的經驗，這種誤報率現在已經相當高了。



目前，社會出現了很多所謂的“下一代WAF”，它們聲稱可以通過查看和分析多個請求或使用IP信譽系統來解決這個問題，但實際上根本就無法解決。

除此之外，使用WAF還有一個最基本的問題，即安全防御者必須對WAF和安全工具進行完美的配置，才可能安全地避免誤報出現。但是，威脅行為者只要找到其中一個漏洞或缺陷，你的安全防御就失去了意義。


WAF的替代方案


由于WAF消耗的資源多、運行效率低下、安全性不高且噪音大，那我們如何去說服安全管理層不要使用WAF呢？從技術層面上，我們將這種平替技術稱之為“補償控制”，之所以我們將其視作WAF的一種更強大的替代方案，原因如下：


1、隔離性：隔離涉及確保一個組件中的漏洞不會影響系統的其余部分，并且有許多技術可以提供隔離性。比如說，瀏覽器可以通過在特殊的沙盒進程中執行所有代碼來實現這一點，這些進程無法全權訪問 Cookie、保存的密碼、其他選項卡等。想象一下，如果每段 JavaScript 都需要由數百個正則表達式進行分析，那么整個網絡體驗將會有多差。除此之外，微服務在設計時就考慮到了隔離性，但我們也可以使用各種庫和編程語言從整體層面上實現隔離性。
2、不變性：我們可以通過刪除一些假定條件來消除整個類型的攻擊，比如說部署readOnlyRootFilesystem、需要重新啟動的包管理器或不可變數據備份等。
3、靜態分析功能：針對SQL注入其實有一個“靈丹妙藥”，即使用“預先準備好的語句”。但問題是，很多開發人員可能會忘記使用它們。CI 管道中的靜態分析檢查幾乎可以確保代碼庫中SQL注入漏洞為零，此時不需要任何SQL注入WAF規則。
4、基于功能的安全性：并非每個API節點都需要對整個數據庫和文件系統具有不受限制的讀/寫訪問權限，但這正是我們現在構建API的常用方式。通過代碼編程能力，我們可以準確地讓“GET /api/v1/books”只需要擁有對“books”表的讀取權限。或者“POST /api/v1/imageupload”只需要對特定文件夾擁有寫權限，同時不需要生成進程。


總結


我們也承認這些想法有些空泛，我們需要讓這些控制措施去適應我們特定的應用程序，但這些設計安全的策略正是安全行業需要走向的方向。不幸的是，安全行業很難從基于設計的技術中獲利。


參考資料


https://github.com/0xInfection/Awesome-WAF#evasion-techniques
https://logging.apache.org/log4j/2.x/manual/lookups.html
https://blog.cloudflare.com/exploitation-of-cve-2021-44228-before-public-disclosure-and-evolution-of-waf-evasion-patterns/
https://habr.com/en/companies/dsec/articles/454592/
https://docs.aws.amazon.com/waf/latest/developerguide/waf-oversize-request-components.html
https://www.macchaffee.com/blog/2023/solarwinds-hack-lessons-learned/
https://docs.fastly.com/en/ngwaf/jira
https://docs.fastly.com/en/ngwaf/about-next-gen-waf
https://docs.fastly.com/en/ngwaf/about-the-architecture#about-the-collection-and-analysis-system
https://www.ctrl.blog/entry/cloudflare-ip-blockade.html
https://github.com/dckc/awesome-ocap#libraries-and-frameworks
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
https://thenewstack.io/3-immutable-operating-systems-bottlerocket-flatcar-and-talos-linux/
https://www.rsync.net/resources/faq.html#9a


參考鏈接


https://www.macchaffee.com/blog/2023/wafs/





Web應用防火墻 網絡安全
撤稿糾錯
本作品采用《CC 協議》，轉載必須注明作者和本文鏈接