Re: Reality Check: Session Hijacking

From: Adriaan (red_at_de.solidareit)
Date: 05/08/04 

Date: Sat, 8 May 2004 17:39:53 +0200

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

Ok, I'm finally getting your point! And I agree: if one authenticates over
SSL, then goes to non-SSL pages while the PHP session is kept alive, some
sniffer could get the session id while that session would have some
"isAuthenticated" set to true. Next, the so-called hacker could even jump
into the SSL pages if those do not enforce one to re-present some
credentials. And though I feel we already agreed that a user would be
reprompted for credentials whenever something really sensitive should be
done, even then the so-called hacker could jump into the application a
second later.

Still, first of all, rather than storing some encrypted authentication
details I'd then store some random number, and set the same number in the
session. On a non-shared server only your application can read that number
from your session, and using SSL for the secure parts also makes sure no
sniffer can get that random number. I guess that number doesn't even need to
change every time the user re-enters some credentials, as long as it is only
encoded into pages that are requested over SSL.

But, though I did not give it much thought yet: then why not simply store
the SSL session id (as taken from $_ENV['SSL_SESSION_ID'] or likewise
$_SERVER, so obviously not the value of PHPSESSID) in the PHP session, and
compare the two values instead of using "isAuthenticated"? As far as I know
the SSL session id should be maintained across requests, even over proxy
servers. No need for any extra fields in your pages then, and your visitor
will be happy that the brower's Back button is still fully operational!
Hmmm, too bad, I might be wrong here: quick tests with non-official server
cert show that the SSL session id does change with each page refresh, so
it's probably not the "master" session id that is used to create temporary
keys for each subsequent request :-(

To extend on Daniel's suggestion to set an explicit path for the session
cookie: http://php.net/session-set-cookie-params also allows one to specify
a value for session.cookie_secure. I wonder if that setting also enforces
the SSL session id to match, but as it enforces a SSL connection no matter
what, that's not what you want anyhow, as for performance you want to be
able to use non-SSL whenever possible. Fair enough. You could still call
this method to set the path though, and to set cookie_secure to get two
sessions: one for SSL and another for non-SSL. However, you might want to
sync those two, which is not really possible I guess.

If using the SSL session id is not possible, then (as we did already agree
on re-authenticating whenever a sensitive page should be shown) a more
user-friendly and easier to implement solution might be the following. This
doesn't mess up the browser's Back button (I guess one does not want to
encode the credentials into the URL GET parameters as those might show up in
the browser's history, even though I think those should not be sent along in
any HTTP Referer header when jumping to another site), though less secure:

- when page is accessed over SSL: check if "isAuthenticated" in session is
true, if not: prompt for credentials
- whenever page is accessed over non-SSL: remove the "isAuthenticated" no
matter what

This, of course, could still be abused: if a so-called hacker gets the
session id from a non-secure page, and then actually waits until the user
uses the same session id to continue on a SSL secured page (after presenting
a password) then that session id could be used to jump into the secured
session, as long as the user did not yet go to a non-SSL page. Obviously, as
your first concern is about someone sniffing into the data, it then indeed
is feasible that such hacker will be waiting for one to log in. Furthermore
the user might close the browser while on a SSL page, leaving the hacker
with a functional session id. So: certainly less secure than your solution.

> 1. User starts to use a secure app over HTTPS, and is prompted for
> login the FIRST time, and the first time only

Well, not only the first time, but also when sensitive parts of the
application are entered, but like I wrote: I felt we already agreed on that.

Adriaan

Quantcast