2011/12/29 Christopher Schultz <ch...@christopherschultz.net>: > Mark, > > On 12/28/11 5:28 PM, Mark Thomas wrote: >> Tomcat has implemented a work-around for this issue by providing a new >> option (maxParameterCount) to limit the number of parameters processed >> for a single request. This default limit is 10000: high enough to be >> unlikely to affect any application; low enough to mitigate the effects >> of the DoS. > > While both POST-size-limiting and parameter-count-limiting are both > reasonable mitigating procedures, would the use of a randomized-hash be > something worth doing? > > There are other solutions of course, but Tomcat could subclass > commons-collections' HashedMap and alter the behavior of the hashIndex > method to add a salt to the hashcode of any parameter name that will be > inserted into the hash map. >
Some random salting might be doable, but 1) I would like to see a working implementation of it. 2) Fixing JRE errors in Tomcat is not a good way. The applications themselves are usually processing the parameters further and might be vulnerable. IIRC, the hash function in HashMap had some improvements to increase its randomness. Some time ago it was possible to enable it with -XX:+AggressiveOpts, but I cannot confirm that. It looks like in the current code it is enabled by default - see HashMap#has(int). Without this additional hash function similar strings had good chance to fall into the same hashtable entry. I think Oracle could apply some random seed to that function. For those concerned I would propose to 1. Further lower the parameters count limit to e.g. to 1000, 100 or 20. 2. Configure FailedRequestFilter so that it rejects requests the hit the limit. (So that the limit does not cause any data loss in the web application). Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
