Understanding HashDos and postParameterLimit
By Pete Freitag
I received a question today about the postParameterLimit that was added to ColdFusion 8,9 by security hotfix APSB12-06 and exists in ColdFusion 10 by default. In ColdFusion 10 and up this setting is configurable in the ColdFusion Administrator under: Maximum number of POST request parameters.
The question I was asked about this was:
I was wondering your opinion on the maximum level of this setting in relation to security.
I've also seen a lot of people unclear why they are getting a 500 Server Error (coldfusion.filter.FormScope$PostParametersLimitExceededException: POST parameters exceeds the maximum limit specified in the server.
) when posting a lot of form variables, so let's dig in to this issue.
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.
So how to you fix HashDOS
ColdFusion added the postParameterLimit
setting to neo-runtime.xml
(or if you are on CF10+ you can just edit the ColdFusion Administrator Setting: Maximum number of POST request parameters) to mitigate the effects of the HashDos vulnerability, which existed in many web application servers. Adobe set their default limit to 100, while Microsoft set their default limit to 1000 for ASP.NET.
Getting back to the original question how high can you set this value? -- the answer is that you want to set this as low as your application allows. The actual number of what you can handle depends on what your hardware can handle, and what an acceptable wait time is for the end user.
Update: as of ColdFusion 11 and greater you can set the Post Parameter Limit in the ColdFusion Administrator. There is no need to edit the neo-runtime.xml
file directly anymore.
Understanding HashDos and postParameterLimit was first published on August 01, 2012.
If you like reading about coldfusion, hashdos, security, postparameterlimit, or dos then you might also like:
- HashDOS and ColdFusion
- ColdFusion Summit 2024 Slides: 20 ways to secure CF
- Latest ColdFusion Security Updates - October 2024
- Fixinator fixes unscoped variables
The FuseGuard Web Application Firewall for ColdFusion & CFML is a high performance, customizable engine that blocks various attacks against your ColdFusion applications.