[WEB SECURITY] Defeating nonce/token based CSRF protection

Mike Duncan Mike.Duncan at noaa.gov
Thu Apr 17 15:57:27 EDT 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ory Segal wrote:
> 
> 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.

They may not only have HTML, but code which executes without the user's
knowledge. It is not out of scope to realize something like this...

* I send an email which tells users to go to a website and login for
some reason.

* User goes to website.

* PHP code connects to actual site and gets token and even repeats page
contents as-is from actual site. Someone could do this using cURL.

* When the user logs in, we capture the information and perform a login
request using the token downloaded in the request to the actual site. If
the user/pass given is correct, we store this.

In this, the PHP code is actually the client logging in -- not the user.
Kinda like a code-in-the-middle attack. And the framework, server code,
whatever is on the server would/could not know the difference. We look
like a normal client/user.

I have wondered about this scenario before, as has the author of this
thread. I would wonder how a framework could prevent this actually. Any
ideas?

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

You are right about the limitations of the XmlHttpRequest, but I think
what the author and I are trying to get at is beyond this. CSRF is a
request on behalf of the actual user/site and can be performed countless
ways.

> 
> -Ory Segal
> 
> 
> 
> 
> From: 	"Jeroen van Dongen" <jeroen at jkwadraat.net>
> To: 	websecurity at 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]
> 
> 

- --
Mike Duncan
ISSO, Application Security Specialist
Government Contractor with STG, Inc.
NOAA :: National Climatic Data Center
151 Patton Ave.
Asheville, NC 28801-5001
mike.duncan at noaa.gov
828.271.4289
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIB6ulnvIkv6fg9hYRAlNyAJ9Peh1LvIUF7z0JPy4fzyVY0ifSuwCdFUes
ZqZMesmj81+EH0I0KwEZQWg=
=DzTC
-----END PGP SIGNATURE-----

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