[WEB SECURITY] Defeating nonce/token based CSRF protection

bugtraq at cgisecurity.net bugtraq at cgisecurity.net
Thu Apr 17 14:06:54 EDT 2008


I've written a FAQ on CSRF that you may find helpful
http://www.cgisecurity.com/articles/csrf-faq.shtml

- Robert
http://www.cgisecurity.com/
http://www.webappsec.org/


> Jeroen,
> 
> You use a different CSRF token for each user.  So the attacker has no way to
> get yours.  You can see a simple implementation in the OWASP CSRFGuard
> project (http://www.owasp.org/index.php/CSRFGuard).  Or some methods you can
> use in your application in the OWASP ESAPI (
> http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/org/owasp/esapi/HTTPUtilities.java)
> 
> --Jeff
> On Thu, Apr 17, 2008 at 9:56 AM, Jeroen van Dongen <jeroen at jkwadraat.net>
> wrote:
> 
> > 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]
> >
> >
> 
> 
> -- 
> 
> --pl
> 
> ------=_Part_18564_11189025.1208455082264
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> <div>Jeroen,</div>
> <div> </div>
> <div>You use a different CSRF token for each user.  So the attacker has no way to get yours.  You can see a simple implementation in the OWASP CSRFGuard project (<a href="http://www.owasp.org/index.php/CSRFGuard">http://www.owasp.org/index.php/CSRFGuard</a>).  Or some methods you can use in your application in the OWASP ESAPI (<a href="http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/org/owasp/esapi/HTTPUtilities.java">http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/org/owasp/esapi/HTTPUtilities.java</a>) <br>
> </div>
> <div>--Jeff<br></div>
> <div class="gmail_quote">On Thu, Apr 17, 2008 at 9:56 AM, Jeroen van Dongen <<a href="mailto:jeroen at jkwadraat.net">jeroen at jkwadraat.net</a>> wrote:<br>
> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Dear,<br><br>I'm currently reading up on CSRF defenses and a highly recommended<br>approach is to include a session-bound (or data-set bound) token in<br>
> forms and / or urls.<br><br>At various places it is described as a "robust" and "nearly impossible<br>to beat" way to defend against CSRF. However, it seems to me that it<br>is (conceptually) easily beaten. Perhaps I'm wrong (hope so), but<br>
> let's have a go ...<br><br>The basis of this defensive technique is that the nonce a) cannot be<br>guessed by the attacker and b) is not automatically send by the<br>browser upon request (as opposed to cookies etc.).<br>
> However, the nonce IS send by the server to the client upon receiving<br>a valid request. THE problem with CSRF is that the attacker is able to<br>make VALID requests to the server, impersonating the real user,<br>because the browser will happily send every required cookie,<br>
> authorization header etc. along.<br><br>So if that is the case, whats to stop an attacker from first<br>requesting the target form with a GET and then submitting the form<br>with any desired values (including the freshly server-supplied and<br>
> thus valid nonce) just like the user would do? Perhaps implemented as<br>a flash banner running on the attackers site?<br><br><br>Interesting references in this case:<br>[1] <a href="http://www.xml.com/pub/a/2006/06/28/flashxmlhttprequest-proxy-to-the-rescue.html" target="_blank">http://www.xml.com/pub/a/2006/06/28/flashxmlhttprequest-proxy-to-the-rescue.html</a><br>
> [2] <a href="http://www.webappsec.org/lists/websecurity/archive/2006-07/msg00069.html" target="_blank">http://www.webappsec.org/lists/websecurity/archive/2006-07/msg00069.html</a><br>[3] <a href="http://blogs.zdnet.com/security/?p=946" target="_blank">http://blogs.zdnet.com/security/?p=946</a><br>
> <br>Regards,<br>Jeroen<br><br>----------------------------------------------------------------------------<br>Join us on IRC: <a href="http://irc.freenode.net/" target="_blank">irc.freenode.net</a> #webappsec<br><br>Have a question? Search The Web Security Mailing List Archives:<br>
> <a href="http://www.webappsec.org/lists/websecurity/" target="_blank">http://www.webappsec.org/lists/websecurity/</a><br><br>Subscribe via RSS:<br><a href="http://www.webappsec.org/rss/websecurity.rss" target="_blank">http://www.webappsec.org/rss/websecurity.rss</a> [RSS Feed]<br>
> <br></blockquote></div><br><br clear="all"><br>-- <br><br>--pl 
> 
> ------=_Part_18564_11189025.1208455082264--
> 


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