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

[Ory Segal <SEGALORY@xxxxxxxxxx>]

--=_alternative 00675AFBC225742E_=
Content-Type: text/plain; charset="US-ASCII"

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@jkwadraat.net>
To:
websecurity@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]



--=_alternative 00675AFBC225742E_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Hi,</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">-Ory Segal</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">&quot;Jeroen van Dongen&quot; &lt;jeroen@jkwadraat.net&gt;</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">websecurity@webappsec.org</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">17/04/2008 06:59 PM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">[WEB SECURITY] Defeating nonce/token
based CSRF protection</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>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 &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'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] </font></tt><a href="http://www.xml.com/pub/a/2006/06/28/flashxmlhttprequest-proxy-to-the-rescue.html";><tt><font size=2>http://www.xml.com/pub/a/2006/06/28/flashxmlhttprequest-proxy-to-the-rescue.html</font></tt></a><tt><font size=2><br>
[2] </font></tt><a href="http://www.webappsec.org/lists/websecurity/archive/2006-07/msg00069.html";><tt><font size=2>http://www.webappsec.org/lists/websecurity/archive/2006-07/msg00069.html</font></tt></a><tt><font size=2><br>
[3] </font></tt><a href="http://blogs.zdnet.com/security/?p=946";><tt><font size=2>http://blogs.zdnet.com/security/?p=946</font></tt></a><tt><font size=2><br>
<br>
Regards,<br>
Jeroen<br>
<br>
----------------------------------------------------------------------------<br>
Join us on IRC: irc.freenode.net #webappsec<br>
<br>
Have a question? Search The Web Security Mailing List Archives: <br>
</font></tt><a href=http://www.webappsec.org/lists/websecurity/><tt><font size=2>http://www.webappsec.org/lists/websecurity/</font></tt></a><tt><font size=2><br>
<br>
Subscribe via RSS: <br>
</font></tt><a href=http://www.webappsec.org/rss/websecurity.rss><tt><font size=2>http://www.webappsec.org/rss/websecurity.rss</font></tt></a><tt><font size=2>
[RSS Feed]<br>
<br>
</font></tt>
<br>
--=_alternative 00675AFBC225742E_=--