[WEB SECURITY] Defeating nonce/token based CSRF protection

Arian J. Evans arian.evans at anachronic.com
Fri Apr 18 13:05:11 EDT 2008

Oh, please: let's not start suggesting security-fantasy again.

The list has had too much of this lately.

On Fri, Apr 18, 2008 at 6:56 AM, Mike Duncan <Mike.Duncan at noaa.gov> wrote:
> Hash: SHA1
> Eric Rachner wrote:
> > 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.
> What are you asking here? Several people just pointed out that some
> precautions can be taken to prevent this attack. Such as...
> * The framework issues a token for the login form.
> * The login form contains a CAPTCHA or visual identifier which must be
> authenticated as well.
> * Everything is over SSL.
> * The use of client-authentication via SSL could also be used.

Maybe for internal corporate apps, but Not in the Real Internet World.

It's technically, but not logistically feasible. That's why no one on the
planet uses this.

> * IPS which could look for suspicious attacks on the login form which
> would be indicative of a scripted attack -- possibly preparing for the
> phishing scheme.

Oh, please. This is ridiculous. No IPS today does anything useful
on the webappsec side. ISS claims to, but I seriously doubt that
they have a detection mechanism someone with a rudimentary
knowledge of scripting attacks (me) can't waltz around.

Usually they can't even see the traffic. By design, especially in
a HIPAA compliant network, this is almost always the case.

Stop recommending nonsense.

> * Proper session handling which would limit the token/session time to a
> very small window.
> * Maybe require that all clients must be on a certain subnet.

Again, maybe for internal corporate apps, but Not in the real Internet world.

> * Deploy a challenge-response system instead. The server could issue a
> token (challenge) and the client could generate one depending on the
> technology used within the login form.

ROFLMAO, are you serious?

>The server then successfully
> authenticates the generated token from the client but the token must be
> generated in a certain fashion which is secret to the user/attacker.

How could that be a secret? Pre-authentication, everything is public
in an Internet application.

(again, if you mean Intranet apps, or web interfaces to security
appliances, I'll give that this could be a mitigating step. Not for
common or RECOMMENDED use.)

> Of course there are ways around everything -- there is no such thing as
> perfect security. But, if you deploy many layers of protection you are
> doing the best you can. It all depends on your situation and your
> balance of usability and security.

So I think the things I have contention with take far more effort that
the limited value they provide.

I would argue that *rigorous output encoding of metacharacters so
they are safe for the protocol parsers & user agent* is about 900%
more useful than the things you recommended, but not mentioned,
and the same goes for behavioral profiling of use and mis-use cases.

People aren't doing those things well today, but they all have IDS
and IPS and it's not helping them. So,

> The author asked...
> "...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?"
> ...and we are answering: Yes, this is possible but security in depth is
> the best defense against this.

That is a completely vacuous answer.

The correct answer is:

Yes, this can AND WILL happen. It already happens today.

The proper mitigation steps are ones few people take today:
Behavioral Anomaly Detection. You could do this by thresholding
and profiling use of the form and tokens; I like to bind tokens to
a specific use-case including HTTP protocol headers and verb
(mostly to catch bad humans & bots), session token use, and a
behavioral use-case (submission over time, submission relative
to session & navigation patterns)

That latter part can be implemented in a rudimentary fashion
to limit abuse by attackers, by thresholding and profilng for
gross abuse cases (mass attacks). This should be easy.

More subtle attacks, against a single user, are going to
require you to have some specific use-cases in mind that
you can enforce without impacting users, e.g.-submission
over time & relative to a session metrics, etc. etc.

Your IPS and your IDS and your network firewalls and
your SSL and your frameworks and client-side "security"
aren't going to help you here.

I think we should start calling recommendations for random
network and crypto controls on our software:

"Defense in Density" instead of "Defense in Depth".

Arian Evans, software security stuff

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

Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

More information about the websecurity mailing list