WebApp Sec mailing list archives
Re: [WEB SECURITY] HTTP Parameter Pollution
From: Stefano Di Paola <stefano.dipaola () wisec it>
Date: Wed, 20 May 2009 12:11:25 +0200
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 ..................
Current thread:
- HTTP Parameter Pollution Stefano Di Paola (May 19)
- Re: [WEB SECURITY] HTTP Parameter Pollution bugtraq (May 19)
- Re: [WEB SECURITY] HTTP Parameter Pollution Stefano Di Paola (May 22)
- Message not available
- Message not available
- Re: HTTP Parameter Pollution Stefano Di Paola (May 19)
- Message not available
- Re: [WEB SECURITY] HTTP Parameter Pollution bugtraq (May 19)
- Message not available
- Re: [WEB SECURITY] Re: HTTP Parameter Pollution Stefano Di Paola (May 19)
- Message not available
- Re: [WEB SECURITY] HTTP Parameter Pollution Stefano Di Paola (May 20)
- Re: HTTP Parameter Pollution Ivan Ristic (May 22)
- Re: HTTP Parameter Pollution Stefano Di Paola (May 22)
- Re: HTTP Parameter Pollution Ivan Ristic (May 22)
- Re: HTTP Parameter Pollution Stefano Di Paola (May 22)
- Re: HTTP Parameter Pollution Ivan Ristic (May 22)
- Re: HTTP Parameter Pollution Stefano Di Paola (May 22)
- Re: HTTP Parameter Pollution Stefano Di Paola (May 22)
- Re: [WEB SECURITY] Re: HTTP Parameter Pollution Ivan Ristic (May 22)