[WEB SECURITY] Defeating nonce/token based CSRF protection

Eric Rachner eric at rachner.us
Thu Apr 17 14:08:59 EDT 2008


Jeroen,

What stops an attacker from first obtaining the nonce is the fact that,
although the attacker can cause the application to send a nonce to the
victim's browser, there is no way for the attacker to subsequently learn the
nonce.  Think of CSRF as a "write-only" attack: the attacker can cause the
victim's browser to send arbitrary requests, but he cannot observe the
results.

Confused people sometimes assert that the nonce could be read via an XSS
bug, but then we're talking about XSS, which is a problem unto itself.

Confused people also sometimes assert that the nonce could be read via
malicious third-party content embedded in the page, but then, again, we're
talking about malicious third-party content embedded in the page, which is
another problem unto itself.

And confused people sometimes assert that the nonce could be read via the
latest obscure misbehavior on the part of the browser, but then, yet again,
we are talking about an entire world of other problems unto themselves.

- Eric

-----Original Message-----
From: Jeroen van Dongen [mailto:jeroen at jkwadraat.net] 
Sent: Thursday, April 17, 2008 6:56 AM
To: websecurity at webappsec.org
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]



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



More information about the websecurity mailing list