Re: Reality Check: Session Hijacking

From: mrbog (dterrors_at_hotmail.com)
Date: 05/07/04 

Date: 6 May 2004 21:42:20 -0700

"Adriaan" <red@de.solidareit> wrote in message news:<409aa897$0$30724$e4fe514c@dreader9.news.xs4all.nl>...
> No. You wrote you're *not* using SSL if the data is no longer too sensitive,
> and that you're putting some encrypted thing in a hidden FORM field for
> those pages. So: those pages are not viewed over SSL, and hold some static,
> encrypted value which you (and so: anybody) can also decrypt. That't what
> you were writing, right?

No. That is not my method. I'm not putting hidden fields in http
forms. You still don't get it, and actually, I'm relieved that you
don't get it because it means you're not an ***, it's just that
you're not getting it! I'm going to explain it again again again, in
yet another way. THINK THINK THINK. I know this will seem slow but
after we've spent so much time, this is my last attempt to correct
your thinking:

Let's define the setting:

A web site, which has both sensitive pages/apps and non-sensitive.
For example of non-sensitive- some flat html pages that just go over
http and are public, for forms. This site also has sensitive apps
like a user editing his home address and credit card number, whatever-
private data.

The user needs to be able to both see this data and edit it. Without
exposing this data.

So, with my method:

1. The user is always challenged when he starts to use a secure app,
and I don't mean just the first time, I mean each and every time he
STARTS to use the secure app. Subsequent pages of the app don't
challenge him because subsequent pages are getting his auth info from
hidden fields. And NOT from the session.

2. If the user, or a hacker, attempts to make a request (get or post)
to ANY PAGE of a secure application, without also including the auth
info in that post request, then the secure app has no way of
recognizing who he is (because that data isn't in the session either),
and it prompts him for name/pw and starts him on page 1 of that secure
app. (That is not true of your method).

3. If the user logs into a secure application, and then leaves it
(goes and clicks on a flat http page in another window for example),
he is exposing his session cookie. With my method, that's not a
problem. There is no security consequence to that. If a hacker gets
his session cookie, the hacker won't be able to login to any secure
apps with it. Why? because there's nothing in the session about being
logged in- there's no "isauthenticated" bit, or username/pw, whatever,
NONE of that is in the session. The secure app may not know the
difference between the user and the hacker, but so what? It won't
allow either one of them in unless the request includes auth data,
name/pw.
---------------------------------------------------
And now, your method:

1. User starts to use a secure app over HTTPS, and is prompted for
login the FIRST time, and the first time only, and will never be
prompted for login again until his session expires.

2. After logging in, the user wanders away from the secure app (clicks
on a flat http page in another window, for example), and therefore
exposes his session cookie over unencrypted http.

3. A hacker pulls down that session cookie- it's in plain text when
it goes over http, when the user wandered away from the secure app and
went to http. He then creates an https request to the SECOND page of
your secure app- using a fake session cookie he created, which is
identical to the user's session cookie.

4. Your app accepts this spoofed request as though it came from the
LOGGED IN user, because it just checks the hacker's session and the
session has your "isauthenticated" bit set to true. The secure
information has been compromised.

5. MY METHOD DOESN'T ALLOW THAT.

The hacker can't get authentication information from my method unless
he decrypts the SSL and reads the hidden fields- which only travel
over SSL in the hidden fields of secure https apps in my method.

I AM NOT SAYING that you are transmiting name/pw over http. I AM
SAYING that in your method, after a user has logged in, the single
only criteria that the subsequent pages of your application require in
order to verify that a user is who he says he is, is the session
cookie. And session cookie themselves aren't secure.