NYCPHP Meetup

[Chris Shiflett]

--- charlie derr <cderr at simons-rock.edu> wrote:
> If the entire transaction (both authentication and all content served) 
> was done via https, then it really wouldn't be a security problem to
> use this model you scoff at (session data in the url), right?

Scoff seems a bit harsh. :-) I was just trying to clarify what I thought
was being suggested. Also, passing session data around on the Internet
would include cookies and POST data also, not only URL variables.

To answer your question, it would still be a security risk. Let me try to
think of a crazy analogy to clarify this...

Say you have a 5 year old daughter. You let her walk across the street,
but in order to make sure it's safe, you only let her do this when there
is no visible traffic in either direction. If there is no traffic, then
she's perfectly safe, right?

Well, perhaps she will be safe. But, why let her cross the street in the
first place? This is an especially poor choice if there is no reason. Who
knows what else can happen, and maybe you're not as good as you predict at
sensing the absense of traffic. Why take an unnecessary risk? It makes no
sense.

The same goes for Web security in many ways. If we focus on preventing
only the risks that we're aware of, being careless otherwise, we're sure
to fail. There is no reason to be passing session data back and forth over
the Internet for every transaction, unless:

1. The data can safely be considered public
2. You have plenty of extra bandwidth but need to save processing and
storage resources

That's about the only scenario I can think of where this would be an
acceptable decision, although there may be others.

> I'm just wondering if I'm missing something in my analysis -- the way
> I see it, if the entire conversation is encrypted via https, then it's
> not a real problem security-wise except for the one niggling issue of
> a public access machine being used to access the system (someone could
> conceivaly sit down later and prise anything that was in the url out of
> the browser history).

SSL certainly doesn't solve everything, otherwise Web application security
wouldn't be much of a topic to talk about. :-) I can think of a dozen
different types of attacks that can be successful despite SSL off the top
of my head. For example:

1. Perhaps you think it is best to store all session data in cookies. You
use SSL, and you even set the secure attribute in the cookies, so that
they're not mistakenly sent over an insecure connection. This seems pretty
safe, but unfortunately you find that some of your users use IE (seems
likely), and then you learn that everyone's session data is being
compromised by way of browser vulnerabilities (see
http://www.peacefire.org/security/iecookies/ and
http://shiflett.org/articles/passport-hacking-revisited - unfortunately
the original source of the IE 5.5 and 6.0 vulnerability is now a 404).

2. So, you decide to change your approach, and you store all session data
safely in a database, and you only put a session identifier in a cookie.
You use SSL for everything again, so that you're protected. Oops! People
are still having their cookies compromised, so attackers are using the
stolen session identifiers to impersonate users on your site. Well, all
SSL does for you is require the attackers to type an extra 's'. That
didn't really help.

3. You decide that cookies must be the problem (and the fact that
unknowing users don't realize the serious security hazards of using IE).
You change your session mechanism to only pass the session identifier in
the URL, and because you're using SSL, this should be safe. Oh no! Foiled
again! You learn later that attackers are now using session fixation
attacks to cause unknowing users to pass a session identifier of the
attacker's choosing. So, while the attacker can't snoop the session
identifier, it doesn't matter, because the attacker is the one who chose
it.

I could go on, but the point is that there is no simple solution to every
potential risk. SSL is great, and it solves some fundamental problems, but
it's a very small piece of the puzzle.

Hope that helps.

Chris

=====
Chris Shiflett - http://shiflett.org/

PHP Security Handbook
     Coming mid-2004
HTTP Developer's Handbook
     http://httphandbook.org/