Wednesday, May 27, 2009

HTTP Parameter Pollution


Submitted by Ryan Barnett 05/27/2009

How does your web application respond if it receives multiple parameters all with the same name?  

If you don't know the answer to this question, you might want to find out quickly.  While not a completely new attack category, webapp security researchers Stefano di Paola and Luca Carettoni certainly opened many people's eyes to the dangers of HTTP Parameter Pollution at the recent OWASP AppSec Europe conference.  This was the main premise of the talk and it is actually pretty straight forward - an attacker may submit additional parameters to a web application and if these parameters have the same name as an existing parameter, the web application may react in one of the following ways -
  • It may only take the data from the first parameter
  • It may take the data from the last parameter
  • It may take the data from all parameters and concatenate them together
The ramifications of these processing differences is that attackers may be able to distribute attack payloads across multiple parameters to evade signature-based filters.  For example, the following SQL Injection attack should be caught by most negative security filters -

/index.aspx?page=select 1,2,3 from table where id=1

If, however, the attacker passes 2 parameters each called "page" with a portion of the attack payload in each, then the back-end web application may consolidate the payloads together into one on the back-end for processing -

/index.aspx?page=select 1&page=2,3 from table where id=1

If a negative security filter is applying a regex that looks for say a SELECT followed by a FROM to each individual parameter value then it would miss this attack.  It is for this reason that some implementations will actually apply the signature check to the entire QUERY_STRING and REQUEST_BODY data strings in order to catch these types of attacks.  While this may help, the unfortunate side effect is that this will most likely increase the false positive rate of other signatures.

The best approach to this issue is to use automated learning/profiling of the web application to identify if multiple occurrences of parameters is normal or not.  Most web application firewalls, for instance, gather basic meta-data characteristics of parameters such as the normal size of the payloads or the expected character sets used (digits only vs. alphanumeric, etc...).  The top tier WAFs, however, also track if there are multiple occurrences.  If an attacker then adds in duplicate parameter names, the WAF would be able to flag this anomaly and take appropriate action.

2 comments:

David said...

The examples they gave were interesting and the disparity of interpretation among the different languages certainly gives something to consider.

However, of the times they talked about using HPP to bypass htmlentities-style protection, they never mentioned the real reason the attack worked. If user-data is URL-encoded prior to being included in a link, wouldn't that mitigate a large number of the attacks?

David said...

Sorry, they do address URL-encoding at the very end (slide 43 out of 45). Still seems a bit late after all of the talk of HPP to reduce to much of it to URL injection.