Thread

The default session library in Code Igniter only stores “userdata”. These aren’t really sessions, but rather encrypted cookies. Cookies are stored client-side, which may cause major security compromises. This library extends the default session class with “serverdata” - actual server-side sessions. It also adds options to prevent session hijacking, such as regenerating the session id, encrypting the session cookie, validating ip- and user-agent consistency and/or session lifetimes.

/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *\
  *
  * SESSION FIXING LIBRARY
  *
  * Code Igniter is cool, but its sessions are rubbish.
  * They're actually not even sessions, but encrypted cookies.
  * Encrypted or not, session data should NOT be stored client-side.
  * It's security-suicide; the encryption can be broken.
  * When that happens, hackers write their own session content.
  * 
  * Still, for cookies, they are nicely protected.
  * We'll use them to store the session id. (NOT session data)
  *
  *
  * This library extends the default session library. 
  * Instead of only managing userdata, it allows manipulation of serverdata as well.
  * 
  *
  *
  * When called, the session class now starts or loads an actual session.
  * Extra security to avoid session hijacking:
  * - Session id is stored in an encrypted cookie
  * - Sessions not started by session->start are denied
  * - When the user agent changes, session aborts (optional)
  * - When the ip address changes, session aborts (optional)
  * - Regenerates session id whenever using it (optional)
  *
  * @copyright  Stratadox 2013
  * @link     <a href="http://www.stratadox.com">http://www.stratadox.com</a>
  * @php     5.4+
  *
 \* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */

The source code is available through this link:
stratadox.com/CI_Session_Class.zip

Meaning?

CI has been using the DB for session storage for a very long time, so your initial statement is already wrong. It only defaults to cookies to avoid a dependency to a correctly configured database after installation.

As to the “extra security”, I don’t really see it. The cookie was already encrypted, and you need to load the Session library to use the session data, I don’t see why calling an additional method will introduce additional security?

And finally, PHP 5.4+ for a CI library is a bad idea, given the target audience…

Even if the default ‘sessions’ are also saved in the database, modifying the cookie modifies the session. This means anyone with access to the cookie and the means to re-encrypt it could insert their own session content - which produces unchecked user input on a very sensitive level. Not very secure.

The cookie CI uses is encrypted, but once the encryption is broken an intruder has access to all the session data.

Using this library, however, if a hacker decrypts the cookie, all they gain is the session id - something that is usually stored unencrypted. The session id alone cannot modify or even read the session data.

As for the PHP 5.4 thing, the library has a dependency on session_status which is introduced in 5.4. Using the latest PHP version is recommended whether you use this library or not.

Which is true for any encryption mechanism, including yours. So what makes your solution more secure?

It is not the encryption mechanism that is the weakness (that is published), but the key used, and if the hacker can obtain the key, the hacker can do that in both cases.

You say that the session id alone is not enough to access the session. What else is required then? And is that always available?

The biggest issue you have with sessions is exactly that, how do you securly tie a server side session store to a specific session? User agent is unreliable, IP address is unreliable (and can even change within a session), what else is there? Session id rotation is a commonly used mechanism to reduce the window of opportunity, but has severe issues when it comes to concurrent access, so imho not a real solution either.

I understand the dependency, but my point is that the majority of CI users use CI because of it’s support for legacy platforms, I think the people using it on a 5.4+ platform is a minority. Also, using it will make your application a lot less portable, because you introduce the version dependency, which will make people reluctant to use your library.

So what makes your solution more secure?

This solution is more secure because decrypting the cookie only gives you access to the id of the session. In the default library, decrypting the cookie gives you access to the complete content of the session: the data itself. With this expansion, the raw session data is in no way ever presented to the user, not even encrypted.

It is not the encryption mechanism that is the weakness (that is published), but the key used, and if the hacker can obtain the key, the hacker can do that in both cases.

A (determined) hacker can eventually get the key. It may require brute force, but it can be done. However, if all you win with this decryption is the session id, as is the case with this library, using that much force makes little sense. When you can potentially win access to all user accounts, as can be the case with the default library, the time spent on decrypting becomes rewarding. (And thus more likely)

You say that the session id alone is not enough to access the session. What else is required then? And is that always available?

The session data is valuable, the session id in itself is nothing. The session id is also valuable, but only because it may provide access to that data.

An id alone is not enough for the user to read or write session data - only the PHP script with access to that key gets to see the session content.
The end-users only need to deal with the outcome of that PHP script. Storing the actual raw session data on the users’ machines is a pretty bad idea: it’s not necessary for anything and degrades the security.

The biggest issue you have with sessions is exactly that, how do you securly tie a server side session store to a specific session? User agent is unreliable, IP address is unreliable (and can even change within a session), what else is there? Session id rotation is a commonly used mechanism to reduce the window of opportunity, but has severe issues when it comes to concurrent access, so imho not a real solution either.

This library provides tools for a defence-in-depth strategy; several tools are available to protect sessions from hijackers.
Sessions can be only accessed by a server-side script that has a valid session-id cookie, can decrypt that cookie and successfully validates the session. So, to break into another user’s session, a hacker would have to steal their cookie and decrypt it, before the validation even begins - and even if the validation succeeds the attacker wont get the raw session content.
In comparison: if someone’s cookie gets stolen and decrypted while using the default library, the thief can access the complete session data and (depending on the implementation) possibly even modify it.

I understand the dependency, but my point is that the majority of CI users use CI because of it’s support for legacy platforms, I think the people using it on a 5.4+ platform is a minority. Also, using it will make your application a lot less portable, because you introduce the version dependency, which will make people reluctant to use your library.

I suppose you’re right. The only dependency it has on 5.4 is replaceable for the most part by isset($_SESSION), I’ll probably change that one of these days.

In the default library, decrypting the cookie gives you access to the complete content of the session

Not when the session data is stored server-side, which you should ALWAYS configure.

In that case, the cookie only contains:

foreach (array('session_id','ip_address','user_agent','last_activity') as $val)

So no payload in the cookie.

This invalidates your other points too, as they are based on the assumption that session data is stored client side.

Not when the session data is stored server-side, which you should ALWAYS configure.
(...) based on the assumption that session data is stored client side.

The notion that session data is stored client side isn’t that much of an assumption, it’s just the default behaviour of the default session class.

When sess_use_database is set to true, the data is indeed not kept in the cookie.
However, even when the session is kept in the database, the session cookie can be used to insert raw data into the database session. For example, when you store user_id and language in the session, an unauthenticated user armed with the encryption key could set user_id to the administrator id in the session cookie and have the script update the language, causing sess_write to be called, inserting both language and user_id into the session data in the database. The hacker would acquire administrator rights once this is successfully done.

I do understand this sort of things are implementation-dependant and might be prevented when the developer knows and acknowledges the problems, but even so it introduces unnecessary risks to the security of the application - risks that are avoided with this library.

As for the PHP 5.4 thing, the library has a dependency on session_status which is introduced in 5.4. Using the latest PHP version is recommended whether you use this library or not.

I’ve seen this on a recent project, but perhaps you’d consider making it more portable by checking the version of PHP.  Something like

if (version_compare(PHP_VERSION, '5.4', '<')) {
    // XXX This is not 100% reliable,
    // if session_start() followed by session_write_close() ...
    $iSessId = session_id();
    if(empty($iSessId))
        session_start();
} else {
    switch(session_status()) {
        // ...
    }
}