[WEB SECURITY] Defeating nonce/token based CSRF protection

Eric Rachner eric at rachner.us
Thu Apr 17 16:29:04 EDT 2008


Mike,

As far as I can tell, the scenario you describe is one where:

a) the victim navigates to www.evil.com
b) www.evil.com displays somebody else's content
c) the attack is successful when the victim is duped into
   logging in to the app via www.evil.com

Don't we have a word for that already?  (phishing)

-----Original Message-----
From: Mike Duncan [mailto:Mike.Duncan at noaa.gov] 
Sent: Thursday, April 17, 2008 12:57 PM
To: Ory Segal
Cc: Jeroen van Dongen; websecurity at webappsec.org
Subject: Re: [WEB SECURITY] Defeating nonce/token based CSRF protection

* PGP Signed by an unknown key

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

* Unknown Key
* 0xA7E0F616(L)


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



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