Forum Moderators: coopster

Message Too Old, No Replies

Secure sessions

         

optik

5:11 pm on Sep 14, 2009 (gmt 0)

10+ Year Member



I'm reviewing a sites code at the moment and have come to the user account section, the way it currently works is like this;

- Users enter username/pass
- This data is sent over https to a verification page
- Verification page checks the details
- If the details are correct a new session is created
- The session key is added to the database and the user gets a copy as a cookie
- All pages requiring account only access check the cookie key against the DB key
- When the user logs out or the account is left idle the session key in the DB is deleted

Is there any room for improvement here or is that sufficient. I have stored IP's in the past but as a lot of peoples IP's can be switched by there ISP's during a session this isn't practical.

My main concern is really that having a single cookie may not be very secure and it would be easy to generate random cookies until a match is found. The keys are md5 hashes so this would be unlikely but still possible.

Would using two cookies be worthwhile or maybe some other approach?

I know people may prefer PHP sessions but these are stills stored as cookies.

I can't see any benefit to using URL or header passed variables either as these could be easily manipulated as well.

I'm looking for the most secure method possible.

Thanks

jatar_k

4:58 pm on Sep 15, 2009 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



it depends on what you are trying to protect, if you have mildly sensitive data then you are probably fine as is though you may need to find something for session hijacking. As it stands right now I could get someone to send me (or steal) their sesion id and could instantiate a cookie that would give me access to their account as long as their cookie is alive.

You could have shorter keep alive times too

I tend to take some data that i have about a user that doesn't change and hash that up to provide a key, then i can compare that on each request.

always keep in mind that the more checks you add the more your users may have to relogin. This is accepted but deciding wher the invasive threshold is can be difficult.

optik

6:50 pm on Sep 15, 2009 (gmt 0)

10+ Year Member



Something I've read suggests the USER_AGENT info as a way to keeps tabs on a session. Not perfect but like you say it may help.

The data is sensitive which is a concern.

As far as I can tell there is no way to completely stop session hijacking.

jatar_k

6:57 pm on Sep 15, 2009 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



well, that may be true but if you expire sessions in some short period of time, 5 mins or even less, then you can significantly reduce the window. Whatever data you have about the person can help to make it harder as well.

user agent data is pretty good
geoip is something too, users seldom switch countries, though this requires some processing
though they switch ips, ip can be partially used, same ip as previous request is a positive, a changed ip is not a negative.

anything else you can find is good, i hate reying on a single piece of data, i like to start with two, plus if it is that sensitive then making users login a bit more is no big thing.

optik

2:28 pm on Sep 17, 2009 (gmt 0)

10+ Year Member



This may seem like a stupid question but does PHP use a regular expression when it reads session cookies or should I be reading PHP session data through a regular expression to prevent tampering?

jatar_k

2:33 pm on Sep 17, 2009 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



you mean from someone tampering with data on your server?

or with the cookie?

I am not sure what you would try and stop with a regex

bkeep

3:52 pm on Sep 17, 2009 (gmt 0)

10+ Year Member



I have implimented session_regenerate_id() as a small part in the battle basically as you said
user logs in
user is validated
session is created
user access new auth page
session id is regenerated

[us3.php.net...]

optik

5:57 pm on Sep 18, 2009 (gmt 0)

10+ Year Member



it's just that PHP reads the session ID from a cookie, I could edit that cookie an enter anything not just the hash that PHP makes, so when PHP reads the session cookies does it automatically prevent this kind of malicious input, I presume it would.

jatar_k

3:12 pm on Sep 21, 2009 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



yep you could edit the cookie but you would have to match another active cookie and if you add some other matching then you can be relatively sure that the user is accessing their own data

fast expiries also help keep this window small

the cookie is client side so there is no way for us to protect it