Re: HTTP Parameter Pollution

[Stefano Di Paola <stefano.dipaola () wisec it>]

Ivan,

let's try doing some minimal statements so that there's no
misunderstanding:

1. Web servers/frameworks/applications can do whatever they want with
multiple occurrences of the same parameter. No standard is actually
defined.
2. It would be better if an RFC or similar states how to treat them.
3. The main problem is _definitely_ the chance to "inject" in the
construction of query string which is further used by the next layer.
4. Sometimes it's the application itself that parses the url and changes
the default behaviour of the server/framework.
5. It has to be considered a behaviour not an issue. 

Having said that, we think there's something you're missing from the
application point of view.

The fact that the web server behavior does not affects HPP, would be
correct only, and only if, there is no other hardcoded parameter.

But think about:

URL #1
http://backend.server/doSomething?action=view&key=$param

and

URL #2
http://backend.server/doSomething?key=$param&action=view


Given that the injection is the issue, and that the attack is:

value%26action=delete%23

which is the safe url and which the vulnerable one?

It depends on how the backend server manages multiple occurrences.

If it gets the first one then URL #1 is safe and URL #2 is vulnerable,
otherwise both are vulnerable since you can override the hardcoded
value in action.

So, we didn't claim that having multiple occurrences of the same
parameter is an issue by itself. Actually, this is legal behavior
according to RFC (1866, 2388). However this behavior should be
considered in order to get the attack working (and protect our
application as well).

Speaking about your last comments in the new post, we definitely agree
that, in the context of WAFs, the problem is much wider in scope (all
parts of an HTTP request are involved). However, we have decided to
analyze all issues related to GET/POST/Cookie parameters since they're
the usual entry point whenever you want to change the application
behavior.

Once again, as reported in the slides #6, we want to empathize that
HPP is surely around since many years but it is definitely
underestimated. In our humble opinion, no current research covers in a
broad way all the implications that we have raised. This is not only a
problem of WAFs but actually it has very strong implications with
several building blocks of our web technologies.

However we'll add some of the links you posted in the paper for
references.

Thanks for giving us the opportunity to better clarify on the subject.

Cheers,
Stefano & Luca

Il giorno mer, 20/05/2009 alle 16.07 +0200, Ivan Ristic ha scritto:
> I don't think the two issues are "married", as you imply. For example,
> let's assume that my application uses a backend subrequest whose query
> string is constructed out of the value of the paramter "param":
>
> http://backend.server/doSomething?key=$param
>
> and that you inject "value&injectedKey=injectedValue" (URL-encoded)
> into "param". The resulting backend request would thus be
>
> http://backend.server/doSomething?key=value&injectedKey=injectedValue
>
> So you have managed to pull off an attack using just query string
> injection. Depending on the backend service, that alone may be enough
> for exploitation.
>
> Thus, I think HPP is the injection part alone.
>
> I think your presentation would benefit from moving the discussion of
> parameter processing inconsistencies into the second half, positioning
> it as an additional technique that is needed to maximise the effect of
> the injection vulnerability.
>
>
> On Wed, May 20, 2009 at 2:13 PM, Stefano Di Paola
> <stefano.dipaola () wisec it> wrote:
> > Hi Ivan,
> >
> > HPP is an input validation vulnerability and, consequentially a
> > possible attack, triggered by injection flaws in the context of
> > generating QueryStrings/POST payloads.
> >
> > If you have only an injection (server or client side) in the context of
> > query string construction, it doesn't mean you can actually override
> > hardcoded parameters' values because of web server behaviour.
> > On the other hand, if you know the web server/application behaviour and
> > you cannot inject any parameter then you are obviously safe.
> >
> > So you need both hypothesis in order to exploit the issue.
> >
> > The main topic is that after identifying the application behaviour in
> > managing multiple occurrences and considering which are the layers data
> > passes through, an attacker could exploit the parameter injection
> > vulnerability. And this is HPP.
> >
> > I hope we answered your question.
> > However within the whitepaper, we are going to explain everything in
> > detail and likely, we will be able to show the essence of this flaw.
> >
> > Cheers,
> > Stefano & Luca
> >
> > Il giorno mer, 20/05/2009 alle 10.06 +0200, Ivan Ristic ha scritto:
> > > Hi Stefano,
> > >
> > > Your presentation discusses two separate issues:
> > >
> > > 1. The differences in how various components handle multiple request
> > > parameters with the same name when an application expects only one
> > > (parameter).
> > > 2. Attacks against query string construction flaws in applications.
> > >
> > > Just from reading the slides I couldn't determine which is the main
> > > topic, and which is the one you named HPP?
> > >
> > >
> > > On Tue, May 19, 2009 at 1:52 PM, Stefano Di Paola
> > > <stefano.dipaola () wisec it> wrote:
> > > > Hi guys,
> > > >
> > > > during OWASP AppSec Poland 2009 we presented a newly discovered input
> > > > validation vulnerability called "HTTP Parameter Pollution" (HPP).
> > > >
> > > > Basically, it can be defined as the feasibility to override or add HTTP
> > > > GET/POST parameters by injecting query string delimiters.
> > > >
> > > > In the last months, we have discovered several real world flaws in which
> > > > HPP can be used to modify the application behaviors, access
> > > > uncontrollable variables and even bypass input validation checkpoints
> > > > and WAFs rules.
> > > >
> > > > Exploiting such HPP vulnerabilities, we have found several problems in
> > > > some Google Search Appliance front-end scripts, Ask.com, Yahoo! Mail
> > > > Classic and many other products.
> > > >
> > > > If you are interested, you are kindly invited to have a look at:
> > > > http://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf
> > > >
> > > > We're going to release additional materials in the next future,
> > > > including a video of the Yahoo! attack vector.
> > > >
> > > > Stay tuned on http://blog.mindedsecurity.com and
> > > > http://blog.nibblesec.org
> > > >
> > > > Cheers,
> > > > Stefano Di Paola and Luca Carettoni
> > > >
> > > > --
> > > > Stefano Di Paola
> > > > Chief Technology Officer, LA/ISO27001
> > > > Minded Security Research Labs Director
> > > >
> > > > Minded Security - Application Security Consulting
> > > >
> > > > Official Site: www.mindedsecurity.com
> > > >
> > > > Personal Blog: www.wisec.it/sectou.php
> > > > ..................
> > --
> > ...oOOo...oOOo....
> > Stefano Di Paola
> > Software & Security Engineer
> >
> > Owasp Italy R&D Director
> >
> > Web: www.wisec.it
> > ..................
-- 
...oOOo...oOOo....
Stefano Di Paola
Software & Security Engineer

Owasp Italy R&D Director

Web: www.wisec.it
..................