Thoughts on HTTP Parameter Pollution

Luca Carettoni and Stefan di Paola presented at OWASP Appsec Poland, speaking about HTTP Parameter Pollution. The short version is this- by mangling the inputs for a HTTP request, you can cause all kinds of strange behaviors. On a high level, this isn't too different from SQLi, XSS, and plenty of other attacks. What sets HPP apart is that the quirks you can generate aren't all data sanitization issues- they are often logic bugs, which are much harder to test for, easier to introduce into an application, and more fun to exploit.

The presentation involved a few very different attacks, which makes it a bit difficult to summarize, but essentially, it involves overwriting HTTP parameters. A few examples:

PHP applications (and others) primarily get their user inputs from COOKIE, GET, and POST. If the application reads input from the generic REQUEST parameter, the data could conceivably come from any of these, and developers don't always have a clear understanding of how that decision is made. By abusing the order in which inputs are handled, an attacker can generate unexpected behavior in the application- expecting data to come from POST but instead reading it from GET, for example.

This really isn't new- the register_globals mess in PHP stems from a very similar issue. While register_globals is dying a well-deserved death, similar attacks can still be made against the $_REQUEST parameter, which many developers (usually the same ones that used register_globals) rely on. Java, perl, and ASP have all seen the same issues, and are at varying levels of fixed-ness.

The more interesting and sneaky attack: If you pass a query string with multiple copies of the same parameter (e.g. index.php?foo=bar&foo=baz), the application may handle it in unexpected ways. PHP will use the last occurence of that parameter, JSP will use the first occurence, mod_perl converts it to an array, and ASP concatenates the parameters into a comma-separated string. Custom-buit parsers on embedded hardware can be even more surprising.

Now, if the developer is doing his job right- being paranoid about where his inputs come from, validating, and escaping, this should not be a major problem. However, no developer is perfect, and this being a fairly unknown behavior, it is quite likely to pop up. Quirks are edge cases, and edge cases are where you find security holes.

I recommend you go over the slides, and the whitepaper when it comes out (which should soon). Some very interesting, very cool real-world attacks are outlined there (I especially like the ASP SQL reconstruction), but I won't go into them here. In summary, you can leverage these parameter processing quirks against both the server and the client, in a lot of interesting ways:

• Bypassing input validation


• Bypassing WAFs


• Manipulating application flow


• Manipulating mod_rewrites


• Forcing/spoofing cookies


• Manipulating client-side applications


• Manipulating and polluting page content

As a pentester, I absolutely love these kinds of attacks- they exploit seemingly-benign quirks in the application. They rely on the attacker knowing more about how the application works than the person who wrote it. Besides that, they're wicked fun to play with. I see HPP as yet-another useful tool in my arsenal. Like CSRF and XSS, it is (and will continue to be) extremely common in poorly built applications. Well-designed apps will have minimal attack surface, defense in depth will further limit their exposure, and what holes do exist will be quickly remediated.

HTTP Parameter Pollution isn't an entirely new attack, but it is a much more in-depth revisiting of older flow-control and input parsing issues, specifically at the border between the application and its back-end engine. I expect to see a surge of HPP-related vulnerability reports in the future. From the defender's perspective, though, it is the same story: Know your inputs, know where data flows through the app, validate before you use it, and escape it on the way out.