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

["Hong Cho" <hongcho@xxxxxxxxx>]

Mike,

The MITM (or as you said "code-in-the-middle") attacks are very
effective _once_ the attacker is able to insert him/her/itself in the
middle.

One possible framework (?) solution is SSL with mandatory client
authentication.  There are SSL proxies out there, but as far as I know
no proxy can work with SSL client authentication (unless the client
certificates are compromised).

Of course, it doesn't do much for CSRF however.

Hong.

On Thu, Apr 17, 2008 at 12:57 PM, Mike Duncan <Mike.Duncan@xxxxxxxx> wrote:
> -----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@xxxxxxxxxxxxx>
>  > To:   websecurity@xxxxxxxxxxxxx
>  > 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@xxxxxxxx
>  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]
>
>

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