[WEB SECURITY] Defeating nonce/token based CSRF protection

Ory Segal SEGALORY at il.ibm.com
Thu Apr 17 14:49:17 EDT 2008


Hi,

CSRF attacks usually takes place when the victim is lured to some 
malicious site, and then presented with HTML that causes an automated 
request to be sent by the browser, for example using SCRIPT, or IMF tags. 
In both cases, the browser will not allow the attacker to see the 
responses, so he/she cannot parse them and extract the nonce as you 
described.

The only possible way to do this, is by using XMLHttpRequest, and that is 
only possible if you are operating in the same domain. A good real world 
example for this was the SAMY worm, which originated from the MySpace 
domain, and attacked its own users in the MySpace domain. 

-Ory Segal





From:
"Jeroen van Dongen" <jeroen at jkwadraat.net>
To:
websecurity at webappsec.org
Date:
17/04/2008 06:59 PM
Subject:
[WEB SECURITY] Defeating nonce/token based CSRF protection



Dear,

I'm currently reading up on CSRF defenses and a highly recommended
approach is to include a session-bound (or data-set bound) token in
forms and / or urls.

At various places it is described as a "robust" and "nearly impossible
to beat" way to defend against CSRF. However, it seems to me that it
is (conceptually) easily beaten. Perhaps I'm wrong (hope so), but
let's have a go ...

The basis of this defensive technique is that the nonce a) cannot be
guessed by the attacker and b) is not automatically send by the
browser upon request (as opposed to cookies etc.).
However, the nonce IS send by the server to the client upon receiving
a valid request. THE problem with CSRF is that the attacker is able to
make VALID requests to the server, impersonating the real user,
because the browser will happily send every required cookie,
authorization header etc. along.

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?


Interesting references in this case:
[1] 
http://www.xml.com/pub/a/2006/06/28/flashxmlhttprequest-proxy-to-the-rescue.html

[2] 
http://www.webappsec.org/lists/websecurity/archive/2006-07/msg00069.html
[3] http://blogs.zdnet.com/security/?p=946

Regards,
Jeroen

----------------------------------------------------------------------------
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]


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20080417/e6aa8854/attachment.html>


More information about the websecurity mailing list