Rammifications of maximum number of post request parameters

Question

My team is undergoing a migration from Coldfusion 8 on Windows Server 2003 and IIS 6 to Coldfusion 10 on Windows Server 2008R2 and IIS 7.5.

In our standard build for the CF10 servers, we've implemented a default value of 100 for the maximum number of POST request parameters. However, my customers are requesting limits raised to upwards of 3000 due to errors in server.log showing:

"Error","ajp-bio-8018-exec-2","06/17/14","10:40:46",,"POST parameters exceeds the maximum limit 100 specified in the server. You can modify the setting in Administrator Server Settings."

I want to increase the limit to appease the customer, but not too high as to effect the stability of the environment of the application and others hosted on the server. What are the ramifications for increasing this setting to 5000 or higher? Isn't there an IIS drawback and limitation as well?

Thank you.

Answer 1

Consider that there was previously no limit. The reason for it now is to address a serious security issue that is relevant to all web programming languages, not just ColdFusion.

It's possible that they have some large forms, which require a higher setting. Rather than picking some arbitrary value, ask them to look into their code base and determine the actual highest number of posted parameters they need, then give a little for padding.

I had to do this at my company and as part of our coding standards, we've implemented a limit to the size of a form. If a new task shows up and needs more than the limit, then it gets redesigned to need less than the limit.

This article explains the HashDos attack, which is the reason for this setting.

Step back and learn about the HashDos Vulnerability

First we need to understand the vulnerability that this setting is meant to protect, called HashDos. To do that we need to take another step back and learn about how hashing algorithms work. When you store something in a struct in ColdFusion, eg form["pete"], it will create a hash of the key in this case "pete", it hashes the value to an integer, let's suppose that "pete".hashCode() == 8

All hash algorithms have the possibility of creating a collision, where two different strings result in the same hash code. So let's say that "peter".hashCode() == 8 as well. You don't want form["peter"] to return the result of form["pete"] so the hash table creates a bucket for each integer code. If the bucket contains multiple items then each item in the bucket is compared (this is slow).

Because this collision comparison is so slow, this is where the opportunity for the Denial of Service comes into play. If you can construct a request which results in thousands of hash collision lookups the request can take seconds to several minutes to process. For example with around 50,000 collisions my quad core mac pro with 15 gb of ram took close to 30 minutes to process the request (whose total size was less than 2mb).

HashDos does not only pertain to form post variables

Any time you store a lot of keys in a struct you have the potential for a HashDOS. The URL scope would potentially be vulnerable too but the web server will typically limit the size of the query string. Another place this might come up is if you accept Xml or JSON strings from external sources, which are then parsed into a struct. So keep this in mind whenever you accept external input that might yield struct keys.