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的全部，其中紅箭頭所指的方向，就是防止我們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）