黑客针对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解码后是这样的：