Page 1 of 1

Preventing session hijacking

Posted: Fri Nov 21, 2003 11:18 am
by microthick
In creating a secure login / authentication area of a website, what are some things I can do to ensure that user's sessions are as hard to hijack as possible, without resorting to SSL.

I understand that I can't ever completely prevent the possibility, but I'd like to make it as hard as possible.

Currently, my login system works as follows:

1) User logs in with username and password.
2) Username and password are verified against database records. Password is stored in database, hashed with md5 and salt.
3) Upon successful verification, session.logged_in is initialized and session.user_ip is set to the user's ip.

Then, when visiting any secure page, session.logged_in and session.user_ip are checked.

I'm fairly new to this security stuff and would like some tips on how I could secure things better.

Posted: Fri Nov 21, 2003 1:50 pm
by Stoker
ssl has little to do with session security other than that eavesdroping on the connection is prevented..

One simple way of securing the session data (on the server) is to store it encrypted on the server and give the (random) passwd to the client in a cookie, this way there is no existense of the key on the server and only the owner of the session has it...

Using the same approach is useful even if you dont encrypt it, just use the cookie-value as a password to get access, and/or a checksum of the data..

Posted: Sat Nov 22, 2003 11:25 am
by cybaf
well, the problem of session hijacking has little to do with encryption of session data on the server.

your aproach seems pretty good, but as you probably know it is not very safe anyways. If an attacker would like to steal a session they can spoof the ip or even if the attacker is behind the same proxy/firewall as the user, it would work instantly as long as the attacker can sniff the network and get the session cookie.

However, I think you need to take a look at the security of the loginphase aswell. How is data sent over the network in the loginphase?

take a look at this topic for further info: viewtopic.php?t=14658

also check this paper out (and the links it referes to):
http://www.acros.si/papers/session_fixation.pdf

Posted: Sat Nov 22, 2003 11:44 am
by Stoker
on a shared-hosting server I think it is important to protect sensitive data in the session storage, this way no-one can peek in files and find a session id/ip and spoof it without the correct key (which is not on the server).. If you are worried about eavesdropping on the connection the answer is SSL.

Posted: Sat Nov 22, 2003 4:37 pm
by microthick
I like the idea of having all session information encrypted and have implemented this already.

this might sound like a totally newb-ish question, but what should i do with the session id? i know its being set but i'm not using it anywhere right now. i suppose the web server needs it to handle sessions.

since im not needing it, i havent encrypted it.. should i be encrypting it?

Posted: Sat Nov 22, 2003 7:41 pm
by Stoker
how do you identify a session? that is usually (always???) done with the session id...

Posted: Sat Nov 22, 2003 8:56 pm
by microthick
well, why would i need to identify the session right now?

all i want to ensure is that the person who is looking at the current page is the person who logged in.

i thought that the session id is just for the web server itself so it can differentiate the sessions correctly, like how a router can route data via mac addresses.

Posted: Sun Nov 23, 2003 5:44 am
by cybaf
well since http is a state-less protocol the only way you would "know" if the user who is looking at a page is the one logged in sessions or cookies are the only answer. (as far as I know)... and you can't store any session variables without starting a session. and starting a session would mean to bind a user to some data on the server, which is done with the session id.

Or did you have something else in mind on how to bind the data on the server with the user?
Stoker wrote:on a shared-hosting server I think it is important to protect sensitive data in the session storage, this way no-one can peek in files and find a session id/ip and spoof it without the correct key (which is not on the server).. If you are worried about eavesdropping on the connection the answer is SSL.
I havn't thought much about this since I'm hosing my own server, but it does seem to be a good idea.