很多智能的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 /%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的攻击。

　　* 长URL（Long URLs）：一些原始的IDS为了提高效率往往只检查前xx个字节，通常情况这样很正确，因为请求是在数据的最前面的，但是如果构造一个很长的请求： GET /rfprfprfprfp/../cgi-bin/test.cgi HTTP/1.0，超过了IDS检测的长度，这样就会使IDS检测不到后面的CGI。通常可以在请求中包涵1-2K个随机字符，但是有一些IDS会根据某些协议请求的长度来判断是否是缓冲区溢出，这时IDS就会对此类扫描误报为缓冲区溢出！

　　* 会话组合：把请求分开放在不同的包文中发出――注意不是分片，则IDS可能就不会匹配出攻击了。例如，请求"GET / HTTP/1.0"可以放在不同的包文中("GE", "T ", "/", " H", "T", "TP", "/1", ".0")，但不能逃过一些采用协议分析和会话重组技术的IDS。

　　* 大小写敏感：DOS/Windows与unix不同，它对大小写不敏感。例如：对IIS来说使用大小写是一样的，对有的老式IDS来说，可能造成不匹配。

　　针对HTTP请求进行欺骗的工具主要是Whisker，它采用了上面的一些技术进行WWW扫描，目前的IDS能发现绝大部分的欺骗方式，但对于采用URL编码（尤其是unicode编码）和不规则方式（如TAB替换空格）的扫描，有相当一部分IDS可能检测不到！

上一页  [1] [2] [3] [4] 下一页