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