黑客針對HTTP請求繞過IDS的八種方式
IDS作為企業安全防護系統被眾多的企業所采用，但是安裝IDS系統的企業也不能徹底的安心，隨著黑客技術的發展，許多黑客也可以通過各種方式繞過IDS的檢測，從而對企業進行攻擊，本篇文章主要就介紹黑客在攻擊時通過針對HTTP請求繞過IDS監視。
針對HTTP請求以繞過IDS監視
㈠URL編碼問題,將URL進行編碼，可以避開一些采用規則匹配的NIDS。
二進制編碼中HTTP協議允許在URL中使用任意ASCII字符，把二進制字符表示成形如"%xx" 的十六進制碼，有的IDS并不會去解碼。 如"cgi-bin"可以表示成"%63%67%69%2d%62%69%6e"，有些IDS的規則匹配不出，但web服務器可以正確處理。不過現在大多數IDS已經是在匹配規則之前解碼，目前這個手段已經不適用了，一般的IDS都可以檢測到的！# %u編碼，是用來代表Unicode/wide特征字符，但微軟IIS web服務器支持這種非標準的web請求編碼方式由于%u編碼不是標準的編碼，IDS系統不能解碼%u，所以可以繞過IDS的檢測。例如:
我們使用下列的編碼方式就可以繞過一些NIDS對".ida"的攻擊的檢測。
GET /abc.id%u0061 HTTP/1.0
不過，snort1.8可以檢測到這種編碼后的攻擊，但有一些公司的IDS沒注意到這個問題。解決辦法主要就是在規則匹配前對URL內容的%u編碼進行解碼后匹配。 #unicode編碼，主要針對IIS，將URL中的一些特定的字符或字符串（主要是針對一些IDS匹配的規則內容）用unicode編碼表示，例如：
我們使用下列的編碼方式就可以繞過一些NIDS對".ida"的攻擊的檢測。
GET /abc.id%c1%01 HTTP/1.0
snort1.8目前好象不能檢測到這種編碼后的攻擊。采用通配符如"*string*"匹配的很多IDS應該都存在此類問題。解決辦法就是在規則匹配前對URL內容的unicode編碼進行解碼后匹配。
㈡網絡中斜線問題即"/"和"\"。# "/" 問題：
如果在HTTP的提交的請求中把'/' 轉換成 '//'，如"/cgi-bin/test.cgi"轉換成"//cgi-bin//test.cgi"，雖然兩個字符串不匹配，但對許多web服務器的解釋是一樣的。如果把雙斜線換成三斜線或更多效果也是一樣的。目前有些IDS無法檢測到這種類型的請求。 # "\"問題：Microsoft用'\'來分隔目錄，Unix用'/'來分隔，而HTTP RFC規定用'/'， Microsoft的web服務器如IIS 會主動把'/' 轉換成 '\'。
例如發送"/cgi-bin\test.cgi"之類的命令，IIS可以正確識別，但這樣IDS就不會匹配"/cgi-bin/test.cgi"了，此法可以逃避一些IDS。
㈢增加目錄問題：
插入一些無用的特殊字符，使其與IDS的檢測內容不匹配。 如'..'意思是父目錄，'.'意思是子目錄，window下的"c:\tmp\.\.\.\.\"的意思就是"c:\tmp\"；相應的unix下的"/tmp/././././"和"/tmp/"等價。對"/cgi-bin/phf"可以任意變化成"/./cgi-bin/././phf等形式。
例如：
GET /cgi-bin/blahblah/../test.cgi HTTP/1.0實際和"/cgi-bin/test.cgi"一樣
目前一般IDS都能識別。 很多智能的IDS會把請求還原成正常的形式。
㈣不規則方式問題:
#用tab替換空格（對IIS不適用）：智能的IDS一般在客戶端的數據中取出URL請求，截去
變量，然后按照HTTP的語法格式檢查請求。在HTTP RFC 中，http v1.0的請求格式如下：Method URI HTTP/ Version CRLF CRLFHTTP是按照空格來把請求分成三部分的。但是，Apache 1.3.6和其以后的版本（早些時候的版本可能也是）允許用tab去請求：Method URI HTTP/ Version CRLF CRLF這會使那些根據RFC協議格式處理這個請求的程序失敗。但有的IDS為了減少誤報會在匹配時用上空格。如"/phf"會很容易在字符串中匹配，但"/phf（空格）"會減少很多誤報， 這時對用tab的請求就沒法匹配了。
# NULL方式：構造如下的請求： GET%00 /cgi-bin/test.cgi HTTP/1.0， 由于在C語言中很多字符串處理函數用NULL作為字符串的結尾，如果IDS是利用c函數處理字符串的話，IDS就不可匹配NULL后面的字符串了。這種方式適合IIS，Apache不能處理%00。
㈤命令問題：
許多IDS系統檢測時缺省認為客戶提交的請求是用GET提交的，如GET /cgi-bin/test.cgi。但是相同的請求用HEAD命令也能實現，如用HEAD發送：HEAD /cgi-bin/test.cgi，則有些依靠get方法匹配的IDS系統就不會檢測到這個掃描。
㈥會話組合問題：
把請求分開放在不同的包文中發出 D D注意不是分片，則IDS可能就不會匹配出攻擊了。例如，請求"GET / HTTP/1.0"可以放在不同的包文中("GE", "T ", "/", " H", "T", "TP", "/1", ".0")，但不能逃過一些采用協議分析和會話重組技術的IDS。
㈦長URL（Long URLs）問題：
一些原始的IDS為了提高效率往往只檢查前xx個字節，通常情況這樣很正確，因為請求是在數據的最前面的，但是如果構造一個很長的請求：
GET /rfprfprfprfp/../cgi-bin/test.cgi HTTP/1.0，
超過了IDS檢測的長度，這樣就會使IDS檢測不到后面的CGI。通常可以在請求中包涵1-2K個隨機字符，但是有一些IDS會根據某些協議請求的長度來判斷是否是緩沖區溢出，這時IDS就會對此類掃描誤報為緩沖區溢出！
㈧虛假的請求結束問題：
對有些智能的IDS來說，為了提高效率上和減少占有系統資源，對客戶端發過來的數據,一般只會處理請求部分。
例如發送如下請求：
GET /%20HTTP/1.0%0d%0aHeader:%20/../../cgi-bin/test.cgi HTTP/1.0\r\n\r\n
解碼后是這樣的：
GET / HTTP/1.0\r\nHeader: /../../cgi-bin/test.cgi HTTP/1.0\r\n\r\n
這是一個正確的請求，但對某些智能的IDS只會截取GET的命令行，發現"HTTP/1.0\r\n"后就結束，然后對截取得部分進行操作，所以智能的IDS就不能正確報告基于此cgi的攻擊。
㈨大小寫敏感問題：
DOS/Windows與unix不同，它對大小寫不敏感。例如：對IIS來說使用大小寫是一樣的，對有的老式IDS來說，可能造成不匹配。
針對HTTP請求進行欺騙的工具主要是Whisker，它采用了上面的一些技術進行WWW掃描，目前的IDS能發現絕大部分的欺騙方式，但對于采用URL編碼（尤其是unicode編碼）和不規則方式（如TAB替換空格）的掃描，有相當一部分IDS可能檢測不到！
【編輯推薦】
