Apache Tomcat哈希碰撞拒绝服务漏洞解决方法 or More than the maximum number of request parameter

Apache Tomcat哈希碰撞拒绝服务漏洞解决办法 or More than the maximum number of request parameters (GE

Apache Tomcat哈希碰撞拒绝服务漏洞解决办法 or More than the maximum number of request parameters (GET plus POST)

问题现象:从一个jsp页面A跳转(post请求)到另一个jsp页面B时间,由于数据量过大,B页面显示的记录数比A页面记录数少了很多,开始认为是代码的问题,仔细反编译服务器的文件,没有问题,原来调试方向错误,换角度考虑之后,想到tomcat在前段时间发布的漏洞,而这个问题就是以下这个漏洞引起的,在这里给大家分享一下


出现这个问题时间,控制台一般会有以下警告,这个时间你就更加确定的继续看下文了

警告: More than the maximum number of request parameters (GET plus POST) for a single request ([10,000]) were detected. Any parameters beyond this limit have been ignored. To change this limit, set the maxParameterCount attribute on the Connector


发布漏洞官方原文地址:http://mail-archives.apache.org/mod_mbox/www-announce/201112.mbox/%3C4EFB9800.5010106@apache.org%3E 

漏洞原理: 
在多数web容器的设计中,request都是依靠相应语言的hashtable/hashmap实现,当不同的key存入时如果hash值相等则以链表方式连接。拉链法是解决Hash冲突问题的方法之一,把所有hash值相同的元素链接在同一个单链表中,然后放入到hashtable/hashmap的桶中。这也是jdk中hashmap/hashtable的实现方式。外部拉链法的缺点是:它需要稍微多一些的空间来实现,因为添加任何元素都需要添加指向节点的指针,并且每次探查也要花费稍微多一点的时间,因为它需要间接引用逐一查找匹配,而不是直接访问元素。当大量相同hash值的元素保存时,就会导致链表巨长无比,这时get出对应元素时要在链表里比对key是否相同直到找到对应的元素。所以此漏洞利用碰撞相同的hash值使得hashtable/hashmap退化为一个长链表,容器从request重新get时,map的计算过程会将时间复杂度巨增,原来一个简单的过程将变成一个很费cpu的过程。

影响到的版本: 
Apache Tomcat 5.x
Apache Tomcat 6.x
Apache Tomcat 7.x

解决办法: 
tomcat 临时办法: 
maxPostSize的默认大小为2097152,当maxPostSize=0时,不限制;maxPostSize=20971520时,为20M,改为一个小于10k的值,所有版本可用 ,会影响用户。(在server.xml的Connector中进行配置)
tomcat 持久办法: 

升级Apache Tomcat到5.5.35, 6.0.35或7.0.23及以上版本。
这里些版本中,增加了maxParameterCount参数(在server.xml的Connector中进行配置,不配置时默认为10000),maxParameterCount默认值10000。 


被扫描出了“Apache Tomcat Web表单哈希冲突拒绝服务漏洞”,需要全面设计线上服务器。升级线上服务器需要注意的地方:

1.备份Tomcat服务器。
2.注意查看server.xml、context.xml。将其中设置的内容更新到新版服务器中。

3.查看Tomcat容器的lib将用户添加的jar拷贝到新的服务器中

4.查看bin目录下的catalina.sh,看看是否跟新版服务器有所不同,尤其是用户可能添加JAVA_OPTS="$JAVA_OPTS -server -Xms1024m -Xmx2048m -XX:PermSize=256M -XX:MaxNewSize=512m -XX:MaxPermSize=256m" 来设置服务器的可用内存大小等。