[WEB SECURITY] Defeating nonce/token based CSRF protection

Mike Duncan Mike.Duncan at noaa.gov
Fri Apr 18 15:01:26 EDT 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arian J. Evans wrote:
> Oh, please: let's not start suggesting security-fantasy again.
> 
> The list has had too much of this lately.

Hey, if you don't like the list content -- you are more than welcome to
leave. This crap doesn't help anyone. Keep your misguided comments to
yourself cause it does not help the discussion at hand.

> 
> On Fri, Apr 18, 2008 at 6:56 AM, Mike Duncan <Mike.Duncan at noaa.gov> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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.

No one has mentioned where exactly this application is deployed. The
author asked a simple question -- you are delving into questions which
are not part of the discussion to try and make yourself look better.

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

Client-certificate authentication is and has been a REAL mechanism of
authentication for a LONG TIME. Just because you don't use it, doesn't
mean others don't/can't. Again, interjecting your personal feelings
about technologies does not help the discussion.

It all depends on the application and user base -- not our opinions. I
am just suggesting possibilities -- far from a complete list which no
one could probably give anyways. That is kinda the point of the list, ya
know.

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

So, you are assuming you can get around something you have no idea
about? You are assuming an IPS will "block" everything "bad" when that
is clearly not the point.

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

Yeah, when using SSL or some non-standard protocol. A proper IPS would
have features built-in to actually decrypt this traffic if using SSL and
there are other ways to detect and manage other protocols. Besides, no
one said anything about a HIPAA application.

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

I really cannot believe I saw someone on this list actually type
"ROFLMAO". You should seriously consider not typing this 133t stuff as
it does not help your argument.

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

This is actually not that hard to do, again depending on a lot of other
things. SSL communication with a web service taking input from a
front-end technology like an applet or flash could accommodate this
requirement easily, for example.

> 
> (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.)
> 

No one knows and that is the point as well. Why comment on something you
or I have no idea about? We cannot know the exact details regarding the
situation of the author -- so you should adjust your comments accordingly.

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

The first real piece of information that is helpful in this whole
message. Why could you not say that to begin with?

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

...and...  It is called "in depth" for a reason. IDSs and IPSs need to
be deployed in a correct manner to even be helpful and need to be used
with a lot of other things. An IPS alone is not going to help against an
AJAX attack where the service on the back-end is not properly
authenticating the front-end, for example. But this does not mean that
you should avoid an IPS at all costs -- as you are suggesting. You
should also take into consideration proper application design and
testing for example as well.

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

Why? Cause you say so? Given the above comments, I am willing to bet you
are not anywhere in a position to give such a comment.

My point is clear: Do not trust one thing to protect your application.
What are you saying? Don't deploy a lot of protection cause in your
opinion none of it will work? So, instead rely on the developer to parse
and encode application content properly and code it more smartly based
on use-cases with the application.

You are thinking far too deeply into this question.

> 
> The correct answer is:
> 
> Yes, this can AND WILL happen. It already happens today.

I never disputed this fact and I am not quite sure why you are even
saying this. Everyone knows that web applications get taken every second
of the day. How does that help someone who specifically asked a question
about a certain web application protection mechanism?

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

How does this help when an application can and will behave exactly like
a human. No amount of testing or detection will catch all cases and you
are basically saying this is the only way to do it.

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

The attack that I suggested could be very far from a mass attack. Only
if the phishing is wide spread enough and enough people fall for the
ploy will your protection scheme work -- eventually. How many
compromises would happen before the application starts to "think" an
attack is happening exactly? Are the accounts harvested until this point
something you are willing to give up in order to avoid other
technologies which may help in preventing these attacks?

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

It is very easy to defeat profiling in applications for the most part.
All the attacker(s) need to do is profile the application and your time
and efforts may be for not.

There is a reason why cops should not profile too much -- because not
everyone is a criminal. When you profile too much -- you are going to
get a lot of false-positives (angry mobs of users and helpdesk staff)
and if you do it too little you could be getting false-negatives
(compromises).

All and all -- used with other stuff though -- this could be a good
thing to deploy -- given your development team has enough resources to
accurately profile the use-cases as needed. This is probably why you are
mentioning that you do not see this deployed a lot -- because no one has
the time or resources to figure out what the majority of users are doing
on mass applications. This would require proper testing and time to do
correctly and with the current economy, I highly doubt many
organizations have the man power and resources to do this throughly.

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


In contrast, your opinions are few and between when it comes to actual
content. You are relying on the application and/or possibly a network
device solely to take care of your infrastructure based on user
interactions with the system. This has just as many pitfalls as my
suggestions -- but I never said any of my suggestions would be perfect
alone as you are suggesting.

Truth is, you should do all of the above as much as possible. Sometimes
it is not possible to do some things and some things you can deploy more
than others. _It all depends on the environment the author is in_.

On a side note, you should definitely work on your communication skills.
Attacking someone else because they have a differing opinion than yours
does nothing but hurt your own argument. Instead of commenting flat out,
suggest your ideas and even suggest how some of my ideas are not going
to work in a particular situation -- all in a conventional, convincing
way. We all find that type of conversation helpful...not seemingly,
blasting commentary.

- --
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFICPAEnvIkv6fg9hYRAtI/AKCI2Fwsw/S2wFN8JMMKZz2bWLOKFgCfZD/B
bXXsnO+sjWTw3YtmNacqAmE=
=1HSN
-----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]



More information about the websecurity mailing list