Re: [WEB SECURITY] Defeating nonce/token based CSRF protection

[Daniel Papasian <daniel@xxxxxxxxxxxx>]

Jeroen van Dongen wrote:
> So if that is the case, whats to stop an attacker from first
> requesting the target form with a GET and then submitting the form
> with any desired values (including the freshly server-supplied and
> thus valid nonce) just like the user would do? Perhaps implemented as
> a flash banner running on the attackers site?

The only thing that can stop this are the sandboxes that various client 
side technologies (javascript, flash) have to prevent cross-domain requests.

Obviously if the attack is coming from within your domain (perhaps, say, 
due to an XSS flaw being exploited) then those don't help you, and it's 
trivial to defeat the nonce.

I believe flash relies on a cross domain policy file, but if the user is 
running malicious flash on a domain with a too permissive policy (or 
running malicious flash from a malicious domain, or from your own 
domain) then sure, I think it's game over.

I have yet to see a transparent CSRF protection that XSS on the same 
domain wouldn't let you overcome.  If you seriously want to mitigate the 
risk of CSRF, you'll prompt the user for authentication information (if 
you want to transfer all of your money to this offshore bank account, 
please check here and provide your SSN and pasword) so that credentials 
and the desired action will come across in the same request.

Hope this helps,

Daniel Papasian

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

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

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