Message-ID: <20070109190917.A31767@gwyn.tux.org>
Date: Tue, 9 Jan 2007 19:09:17 -0500
From: Peter Watkins <peterw@....net>
To: Jim Manico <jim@...ico.net>
Cc: bugtraq@...urityfocus.com
Subject: Re: Circumventing CSFR Form Token Defense

On Mon, Jan 08, 2007 at 07:49:04PM -1000, Jim Manico wrote:
> CONJECTURE: An attacker could write a hybrid "html inspection, CSRF attack" mimicking an exact important form (like the funds transfer form for an exact bank) **even if the form in question uses form tokens**.
> 
> Here are the components of this theoretical attack:
> 
> 1) The attacker manually reads the HTML of the the form they are trying to mimic for the purpose of trying to discover the *form element name* of the hidden variable that contains the form token.
> 
> 2) The attacker creates a 2-phase javascript program, similar to a HTTP Trace attack that does the following:
>   a) The javascript makes a simple HTTP/S request to the form it is trying to mimic and inspects the returned HTML for the purpose of pulling out a valid form key since the form key NAME is known from (1). 
>   b) Use that form key value pair ripped from (a) as part of the actual CSRF attack.
>
> It would be a little complex to code, but would completely circumvent a form token defense if coding to attack an exact form of an exact bank.

Hi, Jim.

A good CSRF token countermeasure will at least associate each token with a 
particular user or (better still) application session object. So the Javascript
in step 2a would not have the session or user credentials of the victim, and
would only be capable of harvesting a token that would *not* be associated with
the victim. Remember, the key in CSRF is that the attacker does not possess
the session or authentication credentials of the attacker. The attack you 
outline would only really work in conjuntion with some other flaw like a 
browser not implementing proper Javascript security restrictions (allowing the
attacker to publish the JS attack code in a different JS security realm than
the targeted form but still make a request with the victim's credentials and
read the response to that request), or an application in the same Javascript 
and session/authentication realm as the target application having an XSS flaw
(thereby allowing the attacker to publish his JS attack code within the same
JS security realm as the target form and attack victims with "secure" browsers).

> Defense against this theoretical attack is to make the form element name for the form token itself hard to guess. 
> For example, do not use a hidden variable named "formtoken" : <some hard-2-guess #> use something like: 
> <hardtoguesselementname> : <hardtoguessvalue>

I don't think that would be much help. Assuming the attacker could complete
step 2a and obtain an HTML form with an anti-CSRF token that could be used
for a CSRF attack, the determined attacker would only need to examine a very
small number of forms to figure out how to identify a valid 
<hardtoguesselementname> : <hardtoguessvalue> token pair and proceed. This is
why it's important to tie the anti-CSRF tokens at least to individual 
authenticated users or session objects (and watch out for session fixation).

And, yes, I see now that my Bugtraq email from June 2001 did not specify that
each one-time-use token should be tied to a particular session object. In 
practice, I try to tie tokens to even more narrow scopes. For instance, in
an online trading application's "dump this stock" form, I would create a 
limited time token on a per-session and per-stock basis, e.g. the token on 
the form displayed at 16:15:30 to "peterw" for dumping all MSFT stock would 
only be valid for that session, for N minutes, for peterw, for dumping MSFT. 
I've been doing such things since June 2001 (sf.net still has the code), even
if I was too dense to spell that out on Bugtraq...

> I'll try to come up with sample attack code and do additional research if anyone considers this theory to be plausible.

Please do put together some sample attack code if you think I'm missing 
your point!

-Peter
http://www.tux.org/~peterw/

Powered by blists - more mailing lists