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

[planetlevel <planetlevel@xxxxxxxxx>]

------=_Part_18564_11189025.1208455082264
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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@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>&nbsp;</div>
<div>You use a different CSRF token for each user.&nbsp; So the attacker has no way to get yours.&nbsp; 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>).&nbsp; 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 &lt;<a href="mailto:jeroen@jkwadraat.net";>jeroen@jkwadraat.net</a>&gt; 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&#39;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 &quot;robust&quot; and &quot;nearly impossible<br>to beat&quot; way to defend against CSRF. However, it seems to me that it<br>is (conceptually) easily beaten. Perhaps I&#39;m wrong (hope so), but<br>
let&#39;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--