Unique everlasting session with low collision rate and is set across sub-domains

The goal is to try and make an everlasting SESSION without too much or unnecessary scripting for updating of sessions. And at the same time to avoid session collision as session collisions could lead to 2 users trying to make use of the same session. That would not look pretty! And it does happen. Also for websites that use different language sub-domains, it would be useful if session did not change so that you can easily go from one sub-domain to another without requiring new sessions.

STEP 0:

function getUserIP(){
    $client  = @$_SERVER['HTTP_CLIENT_IP'];
    $forward = @$_SERVER['HTTP_X_FORWARDED_FOR'];
    $remote  = $_SERVER['REMOTE_ADDR'];

    if(filter_var($client, FILTER_VALIDATE_IP)){
        $ip = $client;
    }else
    if(filter_var($forward, FILTER_VALIDATE_IP)){
        $ip = $forward;
    }else{
        $ip = $remote;
    }
    return $ip;
}
$ip = getUserIP();

STEP 1:

ini_set('session.gc_probability', 0);// 0% probability of purging session log files, in this case on startup we preventing sessions from ever being deleted!
session_set_cookie_params(0, '/', '.website.com');// allow same session to be set across sub-domains!
session_name('session');// now make sure that the same session will not be regenerated across sub-domains and stay the same!
session_save_path($_SERVER['DOCUMENT_ROOT'].'/SESSION');//finally sessions are stored in a folder of choice in say public_html folder..
session_start();// we allow sessions to be read or changed..

STEP 2:

```
if(isset($_SESSION['ip'])){// if IP session in session log exist, do..
if($ip!=$_SESSION['ip']){// if the current IP is not in the session log, then user privileges hasn't been confirmed!
session_regenerate_id();// make sure that current visitor will be forced to use a different session_id! // new session copy is generated!
session_destroy();// new session copy will be cleansed from previous data to be ready for use!
header('Location: .');// reload the cu

Since nobody else has chimed in here, I figured I would elaborate on my comments above. If your stated goal is to:

• have sessions that last indefinitely

• have sessions that are more secure than default settings

• have sessions that have have less chance of collision than default settings

Then this is the wrong approach. You are actually not meeting any of these goals, and in fact are making security and chance of collision worse.

First, these sessions will not be indefinite. You are setting session cookie lifetime with value of 0 which means that, if the browser is compliant with this setting, the cookie will only last as long as the browser is open. If that user closes their browser and then opens it back up 10 minutes later, they will get a new session. There is no setting that will make a session last forever, as sessions are not really designed to last forever. If you need data to persist between what truly are "sessions" then you need to look for another solution. I am not suggesting you change this setting at all, as for most use cases when using sessions as intended, a value of 0 for cookie lifetime is a reasonable setting.

So, now that we have established that you are not truly getting "everlasting" sessions, let's get into the security aspects.

Here are a few PHP documentation links I will refer to:

• Securing session INI

• PHP Session Management Basics

We will start with garbage collection. Since you are not getting long-lasting sessions, that fact that you want to collect session data files (or database records if one were to use a database to store the data) indefinitely, means that you are, in essence, accumulating attack vectors against your application. Ideally you should use an appropriate session lifetime and an aggressive approach to invalidating and pruning old records to minimize security risk. One comment from the session.gc_maxlifetime section of the securing INI link above seems very pertinent here:


If auto login feature is required, implement your own secure auto
login feature. Never use long life session ID for it.

Long sessions should not be purposed for long-term data persistence or used for authentication/authorization as it seems you are trying to do.

As I mentioned earlier accumulating these session files is like accumulating attack vectors, as you increase the opportunity for someone to execute a session hijacking or session fixation attack against your application. This coupled with the fact that you open the application to using session cookies over non-secure (HTTP) connection, means it would be trivial for a packet sniffer or man in the middle to grab a session ID from a legitimate user's request and use it FOREVER.

And while destroying/regenerating session id's across IP change boundaries is a reasonable security measure, it is by no means enough. That attacker could be sitting in a Starbucks along with the legitimate user using a wifi network which has the same exact IP address. A sophisticated attacker can also easily spoof their IP address.

Also, keep in mind that there are some legitimate use cases where a user might change IP address during a session (a user on a mobile device for example), so while, IP address can be used as one of the triggers for session invalidation, if you use some of the other takeaways about handling session securely, you might decide that it's importance as a criteria for session invalidation might not be worth a potentially bad user experiences if you had a high number of mobile users.

Accumulating these session files also does increase your risk of a session collision. Now that may be a pretty minute risk on a website with low traffic level anyway, but you are certainly making the probability of it happening worse, not better, with your approach. And the IP check has nothing to do with mitigating against session id collision as mentioned in your comments. That IP value is stored inside the session data and in no way helps mitigate a collision on the session id itself.

Let's talk about the session file save path. I know there was some back and forth on this in the comments, with me suggesting that putting these files in a web directory is a bad security practice. You are right that one could limit access to this directory in other ways, but why would you want to introduce a security vulnerability that you need an additional security measure to mitigate? You are making your application security more complex and more fragile to someone not setting things up properly than it has to be.

Additionally, it just makes no practical sense to be putting this data into your application web directory anyway, just from a straight separation of concerns/access standpoint. One doesn't typically configure database files, application logging, or other similar functionality that might read-write system files to do so into the application space, so why would you do this with session data?

Ideally, you write s

StackExchange Code Review Q#158767, answer score: 2