[WEB SECURITY] Defeating nonce/token based CSRF protection

["Jeroen van Dongen" <jeroen@xxxxxxxxxxxxx>]

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]