[WEB SECURITY] Defeating nonce/token based CSRF protection

Arian J. Evans arian.evans at anachronic.com
Fri Apr 18 19:08:34 EDT 2008


<intelligent_thoughts=inline>

On Fri, Apr 18, 2008 at 12:01 PM, Mike Duncan <Mike.Duncan at noaa.gov> wrote:
>
> 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.

I am trying to reality-ground this discussion.

There is a significant upsurge in traffic and users on this list.
These type of recommendations you made only help to
confuse and mislead people looking for real solutions.

I am pointing that out.


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

Sorry; I was trying to be polite and give you the benefit of the doubt.
In general, I don't think client-side SSL is very useful for stopping
attacks like we are discussing and it has manageability negatives.

Client-side SSL is completely pointless in a discussion about CSRF.


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

You are correct. So,

Speaking technically: it won't help at all in this discussion, or to be fair:
most webappsec discussions.

Those are my thoughts. My feelings are my own private concern.


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

No doubt. You can disagree all you want. I think your post and
suggestions are going to mislead well-meaning people new to
the field looking for useful solutions, so i am responding with
that perspective that your suggestions are not useful ones.

No hard feelings.


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

I do not assume things.

I've taken apart the webappsec specific "defenses" on most
of the major IPS before, some network firewalls, and many
of the WAFs. My knowledge here is about 1.5 years old, so
I could be wrong. But I doubt it.

I was speaking of facts. Todays IPS and IDS don't offer any
meaningful, useful, or even interesting controls for the subject
matter of this thread.

Now an NBAD...that's a different story. If Lancope understood
this space, I think they could offer some interesting solutions.
But they don't. So no point being that horse too.


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

I'm not sure what a "proper IPS" is, but as of recently most didn't
support shared-key SSL. More importantly- that's almost *never*
how they are deployed. And,

More importantly: they aren't useful for this topic.


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

I thought that you were joking and responded in kind.

Evidently you were not.

Wh00t.

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

No it wouldn't.

I cannot prove a negative, as it's logically invalid, so I'm stuck
with pointing out though that if it is PUBLIC and passed to the
CLIENT then all PUBLIC CLIENTS can make use of it.

I do not call that a "secret".

Yes, I've reverse engineered SWFs using binary, encrypted AMF
and extracted their crypto keys and replayed sessions and/or
retrieved sensitive data from production systems using these
mechanisms today, in the real world.

They don't work.


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

Sorry, you are aboslutely correct. I was being polite.

Let me restate:

That is *not* a solution I would recommend to anyone, nor do I think
it would work.


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

Thank you for the compliment.


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

This is the second time this month someone has put words into
my mouth, or spun my comments.

I *never* said to avoid IPS.

I said IPS is not helping them. And it's not. There's an ocean
of weak and compromised web applications backing up my
statementon this.

I am very open to exploring the value of controls like IPS, firewalls,
or perhaps even client-side anti-virus. I would be excited to see
someone from ISS/IBM, Recourse, Sourcefire, etc. speak up about
how their controls could help mitigate threats to our web applications.

You could lead this charge.

Perhaps by starting such a dialogue we could help them provide
us with features that we need.


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

It is a vacuous suggestion because recommending "defense
in depth" after suggesting a panopoly of controls that won't
work for this situation does not provide the reader with any
useful, actionable advice.

In general the "Defense in Depth" mantra is the domain of
Infosec Policy-Builders and Castle-Defenders.

The concept of "Don't count on one magic pill" is valid.

However, the "controls" that are most often recommended
by the "Defense in Depth" crowd for software security uses
don't usually provide much defense in my experience.


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

I found the "Defense in Depth" suggestion non-actionable.


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

CSRF, in the case of SAMMY for example, did not  behave
"exactly" like a human, or "at all" like a human. Very very
little profiling would have been needed to detect and
squash Sammy, for example.

I said that gross attacks, e.g.-many password resets, are easy
to detect, and they are.

I said specifically that attacks against a single user are
more subtle, and require more context, like a notion of
where they came from, how they got there, and the state
of other bits in the session & use-context.


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

Those are all good questions, and I have relevant and useful
answers. I addressed much of this in a WAF and material
released in 2004 and 2005.

Search for Paraegis here:
http://www.blackhat.com/html/bh-europe-06/bh-eu-06-speakers.html

The rest of the material is spread around the web. I'm going to
revisit this soon and put all the links in one place.


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

I did not make many suggestions.

I responded primarily to point out that yours were not useful ones,
particularly for folks new to this list looking for useful answers.


>  Truth is, you should do all of the above as much as possible.


I could not agree with you less.


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


I'm not sure what the first sentence means, but I think we agree.


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


I apologize for your feelings, Mike. I can see where my commentary
would come across harsh. I had some humor at your expense,
too, which isn't a very nice thing to do.

I'll buy you a beer (or tea if you teatottle) to assuage your anguish
if we meet in person.


PS - For the rest of you on the list -- don't think for a minute
that claiming I have offended you or hurt your  "feelings" that
you're going to get a free beer out of me.

Everyone have a good weekend, and for you IPS and
firewall jockeys:

Remember to Block Finger!!!!

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