轉載位址：http://drops.wooyun.org/tips/3804
0x00 背景知識
- 一說到WAF，在我們安全工作者，或者作為普通的白帽子來說，就很頭疼，因為好多時候，我們發到服務端的惡意流量都被擋掉了，于是就産生了各種繞“WAF”的話題，繞來繞去，也就無非那麼多種，而且大多都是基于URLDecode的方式。
- 雖然我的文章也會講繞過，雖然也是那麼幾種，但是我會從防禦的方面展示WAF規則的強大。
- 筆者再次強調，如果你隻是想學習WAF的繞過，我建議還是不要跟我的文章了，我的目的還是主要幫助好多人去搭起整個架構，進而在談繞過。
0x01 從Modsecurity子產品談起
- 問過圈内的好多朋友“知道WAF嗎？”，他們會明确告訴我，“知道”。但是當我給他們說起，Modsecurity這個Apache的子產品的時候，他們就開始搖頭。其實WAF的事實标準就是開源的Modsecurity。并且Modsecurity已經被開發成了Apache的一個子產品，而且這個子產品在反向代理的工作狀态下，實際上是可以保護任何Web程式的。
- 其實，Modsecurity的威力就在于它的規則語言上，這種語言是配置指令和應用到HTTP請求和響應的一種簡單程式設計語言的組合，其實按理說這種語言應當被稱作Lua。一般情況下，Modsecurity的最終結果都是具體到一個動作的執行，比如允許請求通過，或者将日志記錄到Modsecurity_audit.log或者httpd的log檔案中。
- 以下就是我本地的Modsecurity子產品，具體如下圖所示
Modsecurity原理分析--從防禦方面談WAF的繞過（一） - 從上圖就可以得知，這些規則庫（隻是截取了一部分）幾乎構成了Modsecurity的全部，其中紅箭頭所指的方向，就是防止我們SQL注入的一些規則，其中的規則多達100多條，我們先大體看下他的規則，從宏觀上有個大體的認識，為後期的SQL注入繞過儲備必要的知識。
- 從上圖中我們也可以輕易看到，我們進行SQL注入攻擊時常用的payload，不好意思這些都在規則庫考慮之内。下面先說下Modsecurity的規則庫吧。
0x02 Modsecurity 處理事件的5個階段
- 請求頭階段（Request-Headers） 請求頭階段，又稱作“Phase 1”階段。處于在這個階段的Modsecurity規則，會在Apache完成請求頭後，立即被執行。到這個時候還沒有讀取到請求體，意即并不是所有的請求的參數都可以被使用。
- 請求體階段（Request-Body） 請求體階段，又稱作“Phase 2”階段。這個階段屬于輸入分析階段，大部分的應用規則也不會部署于這個階段。這個階段可以接收到來自于正常請求的一些參數。在請求體階段，Modsecurity支援三種編碼方式，具體編碼方式如下：
(1)Application/x-www-form-urldecode
(2) Multipart/form-data
(3) Text/xml
- 響應頭階段（Response_Headers） 相應頭階段，又稱作“Phases3”階段。這個階段發生在響應頭被發送到用戶端之前。在這個階段，一些響應的狀态碼（如404）在請求的早起就被Apache伺服器管理着，我們無法觸發其預期的結果。
- 響應體階段（Request_Body） 響應頭階段，又稱作“Phase4”階段。這個階段可以運作規則截斷響應體。
- 記錄階段（Logging） 記錄階段，又稱作“Phase5”階段，寫在這個階段的規則隻能影響日志記錄器如何執行，這個階段可以檢測Apache記錄的錯誤資訊，在這個階段不能夠拒絕或者阻斷連接配接。因為在這個階段來阻斷使用者的請求已經太晚了。
- 為了更加直覺的展示Apache加載上Modsecurity子產品後，運作階段，我做了一個流程圖：
0x03 Modsecurity的Rule規則詳解
一、為了更好的了解Modsecurity的工作機制，我們來分析下SecRule的規則，具體規則如下： SecRule variable operator [Actions] 1 variable變量：用來描述哪個變量應當被檢查； 2 operator變量：用來描述如何檢查。Operator實際上正規表達式，但是Modsecurity自身會提供很多的Operator，利用的時候直接使用”@operator”即可。 3 Actions：第三部分為可選的部分。描述當操作進行成功的比對一個變量變量時，下一步該如何去處理。
二、為了更直覺的表現SecRule的規則，給出一個具體的事例如下這條規則取自Modsecurity_crs_41_sql_injection_attacks.conf中：
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!REQUEST_COOKIES:/_pk_ref/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "(?i:(?i:\d[\"'`´’‘]\s+[\"'`´’‘]\s+\d)|(?:^admin\s*?[\"'`´’‘]|(\/\*)+[\"'`´’‘]+\s?(?:--|#|\/\*|{)?)|(?:[\"'`´’‘]\s*?\b(x?or|div|like|between|and)\b\s*?[+<>=(),-]\s*?[\d\"'`´’‘])|(?:[\"'`´’‘]\s*?[^\w\s]?=\s*?[\"'`´’‘])|(?:[\"'`´’‘]\W*?[+=]+\W*?[\"'`´’‘])|(?:[\"'`´’‘]\s*?[!=|][\d\s!=+-]+.*?[\"'`´’‘(].*?$)|(?:[\"'`´’‘]\s*?[!=|][\d\s!=]+.*?\d+$)|(?:[\"'`´’‘]\s*?like\W+[\w\"'`´’‘(])|(?:\sis\s*?0\W)|(?:where\s[\s\w\.,-]+\s=)|(?:[\"'`´’‘][<>~]+[\"'`´’‘]))" "phase:2,capture,t:none,t:urlDecodeUni,block,msg:'Detects basic SQL authentication bypass attempts 1/3',id:'981244',tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.id}-%{rule.msg}',setvar:tx.sql_injection_score=+1,setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:'tx.%{tx.msg}-OWASP_CRS/WEB_ATTACK/SQLI-%{matched_var_name}=%{tx.0}'"
2.1 該規則請求的參數包括所有的Cookie資訊（Request_Cookies以及!Request_Cookies）以及cookie的名稱（Request_name）,Post參數（Args）以及Post參數的名稱（Args_names）,當然還有其中的XML檔案（XMLL：/*）
2.2 其中最多的還是那一堆的正規表達式，正規表達式我就不給大家分析了。算了還是貼個圖吧：
2.3 使用到請求體階段“Phase2”階段
2.4 根據正規表達式來比對每個對象，并且已經為正規表達式開啟了捕獲的狀态（capture）
2.5 比對之前先讓請求資料經曆多種變換（t:none來表示）。經過的主要變換有urlDecode Unicode。前者的主要作用是清除之前設定的所有轉換的函數和規則。後者主要是進行URL的編碼。
2.6 如果比對成功後，将會阻塞這個請求（block）。并且抛出提示資訊（msg）。一次表明這是一個SQL注入的攻擊，并且将這條注入攻擊添加到規則當中。同時區分攻擊類型的唯一性的标簽（tag）也将添加到日志當中。
2.7 該規則同時還被配置設定了一個唯一性的ID（ID：981244）