[prev in list] [next in list] [prev in thread] [next in thread] 

List:       websecurity
Subject:    Re: [WEB SECURITY] HTTP Parameter Pollution
From:       Stefano Di Paola <stefano.dipaola () wisec ! it>
Date:       2009-05-20 10:11:25
Message-ID: 1242814285.9429.245.camel () localhost
[Download RAW message or body]

Hi Robert,

Inline

Il giorno mar, 19/05/2009 alle 13.27 -0400, bugtraq@cgisecurity.net ha
scritto:
> A few comments/questions,
> 
> Slide 24: I had a related post on attacking permalinks that touches on this 
> @ http://www.cgisecurity.com/2006/11/attacking-perma.html

Yes, the technique of injecting stuff into permalinks is widely known. 
The point here is that it's used for attacks like Xss, XYZ injections or similar.
We used that technique to get advantage of HPP also when dealing with
URL Rewriting.
We didn't mean to define the URLRewriting injection as a new attack
class - infact there's no such phrases which states that - but the use
of HPP in those contexts. However we will add it to the paper as
reference. Thanks for letting us know.

> Slide 28: page.php would only be 'affected' if it failed to properly authorize
>  the user before performing an edit function and 
> really this is a failure to have CSRF protection. This isn't any different than
>  just directly sending the parameter to page.php. 
> This is technically a subclass/use of content spoofing. 

Of course yes, and thanks for asking. 
As stated on slide 29 
"Client Side HPP
...
* It's more about 
 ** Anti-CSRF 
 ** Functional UI Redressing
..."

HPP has to be considered when you have anti CSRF tokens hardcoded in
links or forms or whatever.
Client side HPP _is_, obviously, content spoofing since it acts inside
urls/query string in the html page.
Probably we should have used "Content Spoofing" instead of "Functional
UI Redressing".
BTW, the word "pollution" suggests exactly this aspect.
We could think about it as the Poor man's CSRF in the same way CSRF is
called poor man's Xss :)

The fact is that it could be used to bypass anti CSRF tokens when no Xss
are found.  

> Slide 33: It appears you've found JS that utilizes this parameter, and if you 
> specified it you could specify your own
> image but not necessarly get XSS. This could be classified as content spoofing. 

You're right, that was a wrong screenshot. It's just an example, since it's
 harmless, but it works also if you inject %26... on 'ip' parameter:
http://host/....?ip=523ca699%
26imagesrc=http://anotherhost/images/image.jpg
(Consider it as if the imagesrc was correctly checked). 
Moreover, it.ask.com is full of client side HPP entry points, I used
that specific example just to give an idea about javascript playing the
game too.

> Slide 37: The bug here is a failure to validate CSRF tokens before 
> executing the commands. In the url I don't see
> a CSRF token, if I am misunderstanding please clarify.

Regarding the Yahoo! mail attack, the url you see on Slide 37 is the
"view Inbox" url, so no anti CSRF on that.
There was actually a CSRF token, and no way to do it from external evil site
for every other server side state change functionality.
We'll publish the video in a few days with more details.


> Keep up the good work. 

Thanks man :)

> Regards,
> - Robert 
> http://www.cgisecurity.com/
> http://www.webappsec.org/
> 
> 
> > 
> > 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
> > ..................
> > 
> > 
> > 
> > ----------------------------------------------------------------------------
> > Join us on IRC: irc.freenode.net #webappsec
> > 
> > Have a question? Search The Web Security Mailing List Archives: 
> > http://www.webappsec.org/lists/websecurity/archive/
> > 
> > Subscribe via RSS: 
> > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> > 
> > Join WASC on LinkedIn
> > http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> > 
> 
> 
-- 
...oOOo...oOOo....
Stefano Di Paola
Software & Security Engineer

Owasp Italy R&D Director

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



----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA

[prev in list] [next in list] [prev in thread] [next in thread]