知識星球來自：信安之路（微訊號：xazlsec）
本文作者：qiaoy（信安之路特約作者）
作者部落格：https://www.qiaoyue.net
在企業架構中，安全體系同剝洋蔥一般，由外及內是由一層層的安全產品和規範構成，越處於外層承重越大，WAF 屬七層防護的第一道牆，隨著網際網路技術發展，業務對外提供服務的方式逐漸收攏，Web 介面與應用壟斷流量，WAF成了安全戰場中被炮火攻擊最慘烈的前線。
痼疾
雖然 WAF 屬於較成熟的安全產品，但不同公司，不同場景都可能衍生出不同的部署方式，一個關鍵原因就是安全、效率、成本的不可能三角，網際網路公司中，效率代表產品的易用性和響應時間，往往很難有較大犧牲，成本和安全的組合形式決定了安全產品架構的不同，即便在傾向選擇中安全成為首位，WAF 產品本身也有痼疾：HTTP 協議和業務場景的複雜性導致很難有統一的策略規範，加之 WAF 抽離於業務程式碼邏輯以外，這些耦合上的瑕疵很容易成為繞過 WAF 防護的突破口。
再者，不管是基於正則匹配還是機器學習，考量 WAF 的指標永遠是相互矛盾的：誤報率，漏報率。在安全和效率(業務)的博弈中，沒有完美，只有適配，這也就決定了 WAF 的定位。
WAF 繞過
WAF 的痼疾在越來越複雜的系統對接中存在耦合缺漏，不同型別的漏洞，在 WAF 的 Bypass 測試中關註點自然也不同，本文嘗試找尋一些規則對抗以外的捷徑進行 bypass，透過以下幾個維度進行嘗試：
1、架構層面
2、協議/中介軟體層面
3、系統/資料庫/程式語言層面
架構層面
在千奇百怪的 WAF 架構中，始終脫胎換骨於兩種基礎的架構：串聯和旁路。
串聯
串聯 WAF 一般權重較高，對攻擊的請求和會話有優先於業務的一票否決權，是最為常見的 WAF 架構方式，不過串聯接入業務意味著 WAF 系統會捆綁、分擔業務指標，在日益追求高響應的複雜鏈路中強行增加了一個單點故障隱患，那考核運維健壯性的指標(可用性、響應耗時和故障率等)將是懸置 WAF 頭頂的達摩克利斯之劍。
串聯 WAF 根據產品形態又有多種變形，常見的區分方式看裝置部署位置。
傳統的硬體盒子裝置一般放置在閘道器入口後，業務中介軟體之前，串聯部署方式有透明樣式、反向代理樣式等，其前置於中介軟體，意味著 WAF 需預留很大一部分效能來處理 HTTP 拆解和封裝的工作，尤其是當下 HTTPS 已成為普遍場景，裝置處理效能急劇下降，使得此類架構的成本投入極大。
透明連線樣式：
反向代理樣式：
當下雲廠商最常用修改域名 CNAME 做多維安全防護的架構同硬體類部署方式在應用場景視角是一致的，不過雲廠商的裝置和網路資源豐富，人才資源配備到位，又有大廠品牌背書，只要有足夠的使用者均攤成本，這種架構算在成本、效率、安全不可能三角中屬協調最優的解決方案。
CNAME 架構：
對於此類前置串聯架構的 ByPass 測試需找尋 WAF 與中介軟體、後端業務間的耦合性缺漏，比如：
1、在使用了 SSL 套接字的會話中，協商加密演演算法屬請求方可控，WAF 和後端業務在演演算法支援上可能存在差異的一個切入點，遍歷後端業務支援但 WAF 不支援的加密演演算法，便可直接繞過 WAF 了，相關工具見 Github：
https://github.com/LandGrey/abuse-ssl-bypass-waf
SSL Bypass
2、針對 CNAME 方式接入 WAF 的系統，能否繞過的關鍵在於後端的業務配置是否嚴謹，如果後端業務未限制訪問源，很容易透過域名解析歷史和 [ 大規模的掃描 ] 定位到真實的 IP 地址，修改本地 HOST 便可以繞過 WAF 直接對後端系統進行攻擊；
3、WAF 與中介軟體的耦合缺漏在後續的中介軟體層面做詳細講解，此處不做贅述。
還有另一類串聯的部署方式，即 WAF 裝置位置後移，巢狀到中介軟體上，這樣 WAF 的損耗將分攤到業務機器，這樣的捆綁意味著一榮俱榮，一損皆損，又因位置後移到了業務側，策略下發和管理都極其複雜，且中介軟體種類繁多，規模一大，這種架構堪稱災難，而隨著業務架構的逐漸最佳化，一般的網際網路業務架構會前置越來越輕的轉發層，將 WAF 嵌到轉發層，或在轉發層透過 openresty 等方式將請求過一遍旁掛的 WAF 叢集，這屬對業務鏈路侵入最輕的一種方式，很多網際網路公司自建的 WAF 採用該架構。
中介軟體部署：
OpenResty 部署：
對於此類巢狀於中介軟體的 WAF 架構測試需針對 WAF 模組的系統耗能和超時為切入點，當中介軟體或 WAF 模組達到一定的效能損耗指標，一般 WAF 系統會預留類似硬體裝置斷電 bypass 的功能來保障業務可用性的強指標，透過這種途徑即可突破 WAF，比如：
1、針對中介軟體本身的漏洞(例如: CVE-2018-1336 )/配置錯誤來觸發 DOS，當系統能耗達到閾值，自動關閉 WAF 模組；
2、針對 WAF 系統的正則策略進行攻擊，透過 ReDoS：
https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS
使策略檢測超時，單條會話跳過 WAF 叢集響應，直接通聯後端業務。
旁路
旁掛 WAF 一般不在會話鏈路以內，這意味著針對命令執行、Getshell 類的一條陳述句拿許可權的攻擊束手無策，滿足業務效能，犧牲了較多的安全指標，做出這種妥協，一方面是業務/運維強勢，可用性是相關部門較重的 KPI 指標，另一方面可能是 WAF 系統開發和運營人力資源緊張，旁路離線分析提供了一定的緩和空間。
旁路 WAF 可以理解為一套離線分析系統，在各類配置和引數設定上很難同業務機器同步，這導致兩者之間的耦合缺漏會更大，且旁路部署的後置阻斷措施也極具多樣性：IP 維度(4 層封禁、7 封封禁)，session 維度(業務路由基於登陸的 cookies 等)，給繞過也提供了一些方法，常見的繞過方法有：
1、若系統是透過分光等方式旁掛，那針對前置串聯 WAF 的 SSL 證書繞過方法在這裡一樣通用；
2、透過攻擊測試，很容易判斷出旁路 WAF 同阻斷元件的通聯時間，獲取海量且廉價的代理 IP，控制好單 IP 的測試存活時間，較低成本便可繞過；
3、針對異常協議和中介軟體特效的攻擊將在後續章節講述，在旁掛 WAF 上均可實現繞過。
WAF 產品架構多樣，除了串聯和旁路外，基於業務特性還有各種各樣的組合方式，之前所在公司基於業務架構單一的特點(系統、語言、中介軟體、資料庫版本等相關資訊全域性一致)，只需要關註固定版本的系統/應用漏洞情報，便可採用平日旁掛，漏洞爆發開啟串聯開關，漏洞批次修複後恢復旁掛的方式，在安全、效率、成本的博弈中發揮一點能動性。
協議/中介軟體層面
HTTP 協議是一個漸進工程。
1991 初版草案 (HTTP/0.9) 僅有不足一頁半的內容，在經歷 5 年時間和若干版本的更替後，第一個正式版 HTTP/1.0 標準誕生，這時它已經變成一份密密麻麻長達 50 頁的檔案，期望能彌補過往標準裡的諸多缺陷。很快到了 1999 年，HTTP/1.1 的 7 位署名作者顯然指望該協議能涵蓋到方方面面，導致的結果就是一份長達 150 頁的大作。但這些越來越宏偉的檔案裡很大篇幅的內容和我們當下實際使用的 Web 並不特別相關，因為他們對新功能的追逐比修複舊有缺陷更感興趣。—— 《Web 之困》
處於尚未完結的漸進工程中，強制的向下相容，加之各類中介軟體對協議的解讀和實現花樣百出，導致整個協議骨幹健壯清晰，細枝末節處卻錯綜繁雜，越是複雜有異議的地方，越是存在安全隱患。
如《Web 之困》書中所描述，協議版本的升級，大多數精力都投入到了新花樣和動人功能的開發上，缺陷的修補向來是不受人待見的，而協議側的缺陷卻往往是致命的。
DEFCON 24 會議上，regilero 有一篇名為《Hiding Wookiees In Http》的演講，詳細分析了 HTTP 協議中 Keepalives 和 Pipelines 組合使用上的缺漏，可導致會話註入和快取投毒，在 WAF 繞過上也提供了一條路徑。
Keepalives 雖然在 HTTP1.0 版本便可以使用，但並沒有得到官方的確認，是瀏覽器爆炸發展階段的民間戰勝官方的勝利，HTTP1.1 版本後才開始作為預設引數參與到請求中，這條引數也屬於新版本令人心動的嶄新功能，引入的原因也是為瞭解決請求量級鬥升，新建立連線帶來的系統和網路損耗，功能大致如下所示：
HTTP Pipeline:
HTTP KeepAlive:
HTTP 1.0:
功能設計本身的意圖是多請求單連線，但‘多請求’這個場景又有多般演繹，比如下圖這種請求，在 WAF 端的識別上，這屬於一個請求，邏輯也是透過拆解 Key、value 的樣式以 Body 內容讀取第二個請求的內容，當然是屬於異常的 Key-Value 結構，這樣第二個包的內容便很容易繞過 WAF 策略直接進行攻擊了。
Keeplive 繞過:
關於 HTTP 協議特性的安全缺陷，還有一個值得說道的漏洞，2011 年 BlackHat 大會有一篇名為《Checkmate with Denial of Service》的演講，闡述了一系列 DOS 漏洞，其中有部分是關於 HTTP 慢速攻擊的分析，此後漫長的一段時間中，slowloris 都是諸多大型 DDOS 事件中的主角，關於慢速 DOS 的原理其實就是利用了 HTTP 的特性，透過 Keepalives 特性，發起大量請求，修改 Content-Length，Hold 住會話，在超時前定期傳送小包，保持存活狀態，使服務端執行緒數打滿，又不得釋放，服務便處於不可用狀態，這種攻擊在前文所述的針對中介軟體的 DOS 中不失為一種有效的攻擊繞過方式。
除了協議特性以外，異變的 HTTP essay-header 也有可能提供繞過 WAF 的捷徑，2018 年的 AppSec 大會上，有一篇《hacker WAF bypass techniques》的演講，透過以下幾個方式進行 WAF 繞過：
1、字符集編碼；Content-Type 頭中使用 charset 定義字符集的應用場景不只有在 responses 中，request 中同樣可以使用，而變換字元編碼集以後，基於規則引擎的 WAF 則徹底失控。
1、內容型別格式；在特定中介軟體版本下 Key-value 可以透過檔案上傳的型別 multipart/form-data 進行提交，而 WAF 針對此型別側檢測一般是隻針對上傳漏洞，導致常規的 xss、sqli 便可以透過該方式進行 bypass，即使存在各通用型別的漏洞檢測，也可透過 Fuzz 異變上傳型別的格式，達到 WAF 無法識別，後端中介軟體可以解析的目的：
當然以上 Bypass 的路徑並非通用的，很大情況與不同中介軟體對 HTTP 的理解和運用有關，詳細中介軟體系統和版本測試情況可參見表格：
https://drive.google.com/file/d/0B5Tqp73kQStQU1diV1Y0dzd1QU0/view
基於協議/中介軟體的安全缺陷並不全然是功能帶來的，有時帶業務特性的配置也會有缺漏，且這種缺漏是前端 WAF 和後端業務中介軟體功能差異所必然存在的，也是大多數通用 WAF 產品很難和業務適配的死角，突出的例子如：
1、請求包大小限制；很多後端業務存在上傳功能，所以請求資料限制上往往會較大，而前置 WAF 系統，需要有較高的響應時間，請求包較大時往往超過內建的效能和耗時閾值，所以可直接傳送大量無意義的引數，尾端帶攻擊引數便可直接繞過 WAF 系統。
系統/資料庫/程式語言層面
系統、資料庫和程式語言層面，屬於對抗 WAF 策略的正面戰場，這類文章網上佳作不勝列舉，但其達成繞過的功效並不具通用性，比如系統級別的繞過可能圍繞命令執行、LFI 之類的漏洞，資料庫相關的繞過是圍繞 Sqli 類漏洞，且兩者的繞過思路大致相同，即利用系統/資料庫特性或不常用函式繞過 WAF 策略特徵，至於程式語言的繞過方式則相對靈活，這也是動態語言的特性決定的，本文主旨是 WAF 繞過的捷徑，正面對抗策略內容便不多做贅述(正面硬剛 WAF 規則也有成熟工具，詳細內容參見參考檔案中 2016 blackhat 大會上的《Another Brick off The Wall: Deconstructing Web Application Firewalls Using Automata Learning》一文)，每個型別各介紹一類比較有代表性的 Bypass 方法：
1、系統層面，利用 Linux 萬用字元特性繞過 WAF 策略；在 bash 語法中，可以使用與系統檔案相同數量的 “?”, “/” 來匹配該檔案；用未初始化的變數隔離特徵字元；用 ‘ 字元拆解再拼貼，繞過字元匹配。
1、資料庫層面，利用 mysql 註釋和註釋特性繞過 WAF 策略；在 ModSecurity (最常見的開源 WAF 框架)預設策略中，union select 這類 Sqli 註入語法一般是貪婪匹配 union 和 select 之間的字元、數字、下劃線、左括號，很容易透過插入 /* */註釋繞過；當變更規則過濾掉註釋，依然可以透過在註釋中使用 ! 加版本號包裹關鍵詞來繞過檢測，因為只要 mysql 的當前版本等於或大於該版本號，則該註釋中的 sql 陳述句將被 mysql 執行；
1、程式語言層面，利用 PHP 陣列特性繞過 WAF 策略；在 PHP 中每個字串都可以當作陣列，這樣基於字串的正則匹配就很容易被繞過了。
限於文章篇幅，簡單描述了 WAF Bypass 測試的整體框架，相當一部分繞過方法未能展示，由於議題寬泛，時間緊迫，故倉促收尾，算理清框架脈絡，避免後來者按圖索驥的浪費時間。
參考檔案
Abuse-ssl-bypass-waf:
https://github.com/LandGrey/abuse-ssl-bypass-waf
Bypassing Web-Application Firewalls by abusing SSL/TLS:
https://0x09al.github.io/waf/bypass/ssl/2018/07/02/web-application-firewall-bypass.html
WAF Bypass Techniques – Using HTTP Standard and Web Servers’ Behaviour:
https://www.slideshare.net/SoroushDalili/waf-bypass-techniques-using-http-standard-and-web-servers-behaviour
基於 Openresty 的雲 WAF 工作原理:
https://www.yqfy.net/base-on-openresty-waf
Regular expression Denial of Service – ReDoS:
https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS
《Web之困》:
https://book.douban.com/subject/25733421/
DEFCON 24 《Hiding Wookiees In Http》:
https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Regilero-Hiding-Wookiees-In-Http.pdf
Checkmate with Denial of Service:
https://media.blackhat.com/bh-dc-11/Brennan/BlackHat_DC_2011_Brennan_Denial_Service-Slides.pdf
Web Application Firewall (WAF) Evasion Techniques:
https://medium.com/secjuice/waf-evasion-techniques-718026d693d8
Web Application Firewall (WAF) Evasion Techniques #2:
https://medium.com/secjuice/web-application-firewall-waf-evasion-techniques-2-125995f3e7b0
Web Application Firewall (WAF) Evasion Techniques #3:
https://www.secjuice.com/web-application-firewall-waf-evasion/
Another Brick off The Wall: Deconstructing Web Application Firewalls Using Automata Learning:
https://www.blackhat.com/docs/eu-16/materials/eu-16-Argyros-Another-Brick-Off-The-Wall-Deconstructing-Web-Application-Firewalls-Using-Automata-Learning.pdf
●編號803，輸入編號直達本文
●輸入m獲取文章目錄
Linux學習
更多推薦《25個技術類微信公眾號》
涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。
