[WEB SECURITY] Defeating nonce/token based CSRF protection

Arian J. Evans arian.evans at anachronic.com
Thu Apr 17 14:25:41 EDT 2008

If you'll look at the CSRF protection in the WAF Mark Belles and I released
at BlackHat in 2005, you'll see it not only uses OTTs, but has explicit
design requirements (so by design can never be cookies):

1) Tied to user auth
2) Tied to use-pulse (time)
3) Tied to use-frequency

So a token can be one time, and limited to say 1 hour (password reset form)
or less, in addition to tying to entity or explicit user.

What we did was replace resources with this, so while you could certainly
scrape-out the token, you could not blindly CSRF unless you had an XSS on
the site. If you have an XSS on the site, it doesn't matter what you do for
CSRF protection.

I was all hot to trot on tokens, particularly for learning and enforcing
behavioral use-case, not to mention a general narcissistic fascination with
my own ideas, until I came to the conclusion that every site has n+1
exploitable XSS which makes tokens kind of useless for this today, since
they can be fetched, manipulated, etc.

Arian Evans, software security stuff

reformed hacker turned animal rights activist to meet vapid chicks concerned
with those tasty animals

On Thu, Apr 17, 2008 at 10:58 AM, planetlevel <planetlevel at gmail.com> wrote:

> Jeroen,
> You use a different CSRF token for each user.  So the attacker has no way
> to get yours.  You can see a simple implementation in the OWASP CSRFGuard
> project (http://www.owasp.org/index.php/CSRFGuard).  Or some methods you
> can use in your application in the OWASP ESAPI (
> http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/org/owasp/esapi/HTTPUtilities.java)
>  --Jeff
> On Thu, Apr 17, 2008 at 9:56 AM, Jeroen van Dongen <jeroen at jkwadraat.net>
> wrote:
> > 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
> >
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20080417/aa35b2a8/attachment.html>

More information about the websecurity mailing list