PHP sessions - Security

[Far Cry]

I have a simple question: In this PHP sessions file, if the user's IP changes or the browser (agent) changes and is not the same as what is stored in the session, the session ID is regenerated. Should I destroy the session if either of these change or just regenerate like I did here?

 

<?php
session_start();
$username = $_SESSION['username'];
$userid = $_SESSION['userid'];
$userlevel = $_SESSION['userlevel'];
$valid = $_SESSION['valid'];
$agent = $_SESSION['user_agent'];
$ip = $_SESSION['ip'];

if($agent != $_SERVER['USER_AGENT']){
session_regenerate_id();
}

if($ip != $_SERVER['REMOTE_ADDR']){
session_regenerate_id();
}
?>

[premiso]

Why not just update the values?

 

My IP changes quite a bit given I hop from VPN to VPN, if the session kept dieing on me I would be pretty pissed off. Updating the session should suffice. As for the user_agent, that should only change if the user is using an extension for the browser to change it. But I still would just update the session values, no need to regenerate it.

[xyph]

Anyone hijacking a session could easily replicate the user-agent, so I wouldn't bother with that check.

 

Regenerating the session if the IP changes isn't a bad idea at all. The attacker will only have access to the session until the legitimate user tries to use his now expired session. When this happens, the user will have to log in again, regenerating and destroying the attacker's session.

[premiso]

When this happens, the user will have to log in again, regenerating and destroying the attacker's session.

 

Seriously? There are tons of legitimate reasons why an IP would change.

 

1: Connecting from a public network, sleeping your computer, connecting from home.

2: VPN connection, switching. I have multiple work VPN's and personal VPN's I switch to not to mention my home VPN as well.

3: Using a proxy for various reasons.

4: Connecting from your 3G/4G Mobile Broadband from somewhere.

 

Not to mention I probably missed a few, but the IP and user-agent really do not matter as much as them having a valid session cookie setup. If they are valid for that session, leave it open. Update your IP logs, and perhaps show them to the user (like google does with Gmail) and allow them to kill the session for any unknown IP's. But don't just automatically kill them because an IP changes. I would stop using the site if they did that to me.

[Far Cry]

I guess to further my question, what can I do to protect the sessions? Any suggestions?

[premiso]

what can I do to protect the sessions? Any suggestions?

 

Well, in reality, that is up to the end user. As long as your end is safe, IE the authentication from SQL Injection remote inclusion, your code does what it should to protect the user, you cannot necessarily control what happens on their end. Depending on the site and how secure it needs to be, sure checking IP's and user-agents can be a good thing, such as my banking site. I would prefer them to kill my session upon a new IP as appose to not. If your site does checkout's where users can buy data, make them enter a password before they are allowed to process the order if one has not been entered in the past 15-20 minutes (or if the IP /UserAgent has changed like Amazon does). This would help prevent orders from going through when the user should not be placing orders.

 

However, for a blog or forum type site, where nothing important is kept, that is way overkill. So as long as you do your part for the internal code, the user has to do their part by doing virus scans / trojan scans / malware scans. As this is where the majority of the hijacking will come from, their computer being infected.

 

So showing them a list of "Active" sessions at the bottom of a page (or top) and allowing them to kill any session is good practice. IE say they were using a public computer at their school and forgot to logout, providing them a way to kill that session by logging in and doing so is a good feature. Other than that there is not much you can do, again that is their issue if they get infected with malware and someone takes over their account, the best you can do is provide them with a method to contact you incase of an incident and/or an method for them to kill any active session or regenerate their own session id.

[xyph]

When this happens, the user will have to log in again, regenerating and destroying the attacker's session.

 

Seriously? There are tons of legitimate reasons why an IP would change.

 

Seriously? Did you read my solution? If the session is regenerated by the legitimate user's IP changing, they will get the newly regenerated ID. If the session is regenerated by the attacker, the attacker will get the regenerated ID, causing the legitimate user's ID to expire. An invalid session ID will require the legitimate user to log in again. When they log in, the session will be regenerated once again, causing the attackers session ID to expire.

 

Hope this makes more sense.

 

So showing them a list of "Active" sessions at the bottom of a page (or top) and allowing them to kill any session is good practice. IE say they were using a public computer at their school and forgot to logout, providing them a way to kill that session by logging in and doing so is a good feature.

 

This is WAY more complex than checking for IP changes (though you think it's overkill) and allows multiple session IDs to be valid for a single user. This is not a good idea.

 

Instead, if they were using a public computer and you regenerated the ID on IP change, them simply logging in at home would kill any sessions they left open elsewhere.

[premiso]

<removed>

 

One note:

 

allows multiple session IDs to be valid for a single user. This is not a good idea.

 

I beg to differ on this point completely. Especially with my mobile phone, if I were to be logged out of Gmail on my computer, because I logged in on it on my phone, that would be retarded. I had to enter a valid username and password to authenticate to my phone AS WELL as on my home computer. Why should either one kill the other's session? Both were authenticated just fine.

 

If you are worried about session attackers, give the user a method to destroy all sessions associated to their account. Do not kill all valid and active sessions just because they login from another location. That is just stupid.

 

And thinking about it, I do not even think my bank kills a session if I login from my phone and from my home computer at the same time. They are both valid sessions for my user as I proved authentication. So yea 1 session per user ever, is just a retarded ideology.

[premiso]

@xyph

After doing some Brainstorming with Josh in IRC. I think I might get where you are going with this and may have just been mis-interpretation.

 

If the site has a "Remember Me" feature, they generally store a cookie on the computer that authenticates the user. Just because the session was nulled, does not necessarily mean they are logged out. It just means that they will be re-authenticated via the cookie (again if they chose to use the remember feature) and a new session will be generated, meaning that they will not be logged out.

 

So yea, I guess to say as long as there is a "Remember Me" option for cookie authentication, I think the regenerating the session for the user would be fine and acceptable. Apologies for me mis-interpreting your text.

[xyph]

Yeah, and I was being far too black-and-white.

 

I don't ever see a case where a single user would need to access a resource from multiple locations at the same time. If a resource must be accessed from multiple locations at the same time, I would implement a group system, where the group has access to that resource and the users have access to that group. I see a user as a single entity, that wouldn't be two places at once.

 

I understand your point about 'remembered' access - though I really don't like the whole concept of it - it opens up holes. In this case, having multiple sessions is the smart way to go. I would store them separately as 'long term sessions' though, giving them a location name defined on creation ('Home', 'Office', 'Phone' etc.) and a last_used time.

When a user logs in with a long term session, that long term session ID is regenerated to help prevent theft. If an attacker logs in using one of the long term sessions, the user's long term session will expire. When a user visits the page with an invalid long-term session, a warning will be displayed saying that 'Someone has logged in using this location on a different device or the location has been deleted' The user will then log in again, and the long-term session will regenerate, causing the attackers session to expire. Otherwise, you would, as you said, present the user with last access times for all of their long-term sessions and offer the option to delete them.

 

From there you could create a short term session if you wanted to enforce only one active session at a time.

 

Multiple active sessions worry me when dealing with long-term sessions - if an attacker gets hold of a long-term ID, they could have long term access to the account. The only way I know to 'automatically' check for this is to see if there are multiple active sessions for the same user. I see it as another layer of protection, and that's why I don't like the idea of allowing it. I just don't see a case where a user would need/want that functionality.

[premiso]

Yea, I would agree on the long term sessions. Which is why I generally list all active sessions for users and let them choose to kill the extra sessions or not.

 

Different strokes for different folks