[WEB SECURITY] Defeating nonce/token based CSRF protection

Eric Rachner eric at rachner.us
Thu Apr 17 17:30:55 EDT 2008


In re.: "It is very possible to get through this protection
unless you deploy security with multiple layers of depth."

Such as...?  Once a phishing victim has mistaken www.evil.com for a trusted
application and logged in, the game is over.  There is no fancy token or
framework that can alter that fact.

- Eric

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

* PGP Signed by an unverified key: 04/17/08 at 13:40:08

Phishing is only the mechanism to get the user on the site. We are
"luring" them to the evil.com site.

My point is that evil.com code could actually scrape the actual.com site
and get the contents, including the token we are discussing. Once the
user is tricked into thinking the site is legit, he/she will login and
the request is only relayed to the actual.com site via the code behind.

USER <==> EVIL.COM <==> ACTUAL.COM

Evil.com will get all the credentials and unless there is some sort of
client authentication, as Hong pointed out, the server will probably
allow it.

We are simply pointing out a weakness with token-based authentication
mechanisms. It is not that I am not agreeing with you that we are
incorporating a lot of attacks here though. I am only agreeing with the
author of the thread. It is very possible to get through this protection
unless you deploy security with multiple layers of depth.


Eric Rachner wrote:
> 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
> 
> > Old 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]
> 
> 

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

* Mike Duncan (NCDC NOAA) <mike.duncan at noaa.gov>
* 0xA7E0F616 - Unverified(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]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5738 bytes
Desc: not available
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20080417/23f5aa13/attachment.dat>
-------------- next part --------------
----------------------------------------------------------------------------
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