PHP Session Fixation / Hijacking

Question

Ok, there are two separate but related problems, and each is handled differently.

Session Fixation

This is where an attacker explicitly sets the session identifier of a session for a user. Typically in PHP it's done by giving them a url like http://www.example.com/index...?session_name=sessionid. Once the attacker gives the url to the client, the attack is the same as a session hijacking attack.

There are a few ways to prevent session fixation (do all of them):

• Set session.use_trans_sid = 0 in your php.ini file. This will tell PHP not to include the identifier in the URL, and not to read the URL for identifiers.

• Set session.use_only_cookies = 1 in your php.ini file. This will tell PHP to never use URLs with session identifiers.

• Regenerate the session ID anytime the session's status changes. That means any of the following:

  • User authentication
  • Storing sensitive info in the session
  • Changing anything about the session
  • etc...

Session Hijacking

This is where an attacker gets a hold of a session identifier and is able to send requests as if they were that user. That means that since the attacker has the identifier, they are all but indistinguishable from the valid user with respect to the server.

You cannot directly prevent session hijacking. You can however put steps in to make it very difficult and harder to use.

• Use a strong session hash identifier: session.hash_function in php.ini. If PHP < 5.3, set it to session.hash_function = 1 for SHA1. If PHP >= 5.3, set it to session.hash_function = sha256 or session.hash_function = sha512.

• Send a strong hash: session.hash_bits_per_character in php.ini. Set this to session.hash_bits_per_character = 5. While this doesn't make it any harder to crack, it does make a difference when the attacker tries to guess the session identifier. The ID will be shorter, but uses more characters.

• Set an additional entropy with session.entropy_file and session.entropy_length in your php.ini file. Set the former to session.entropy_file = /dev/urandom and the latter to the number of bytes that will be read from the entropy file, for example session.entropy_length = 256.

• Change the name of the session from the default PHPSESSID. This is accomplished by calling session_name() with your own identifier name as the first parameter prior to calling session_start.

• If you're really paranoid you could rotate the session name too, but beware that all sessions will automatically be invalidated if you change this (for example, if you make it dependent on the time). But depending on your use-case, it may be an option...

• Rotate your session identifier often. I wouldn't do this every request (unless you really need that level of security), but at a random interval. You want to change this often since if an attacker does hijack a session you don't want them to be able to use it for too long.

• Include the user agent from $_SERVER['HTTP_USER_AGENT'] in the session. Basically, when the session starts, store it in something like $_SESSION['user_agent']. Then, on each subsequent request check that it matches. Note that this can be faked so it's not 100% reliable, but it's better than not.

• Include the user's IP address from $_SERVER['REMOTE_ADDR'] in the session. Basically, when the session starts, store it in something like $_SESSION['remote_ip']. This may be problematic from some ISPs that use multiple IP addresses for their users (such as AOL used to do). But if you use it, it will be much more secure. The only way for an attacker to fake the IP address is to compromise the network at some point between the real user and you. And if they compromise the network, they can do far worse than a hijacking (such as MITM attacks, etc).

• Include a token in the session and on the browsers side that you increment and compare often. Basically, for each request do $_SESSION['counter']++ on the server side. Also do something in JS on the browsers side to do the same (using a local storage). Then, when you send a request, simply take a nonce of a token, and verify that the nonce is the same on the server. By doing this, you should be able to detect a hijacked session since the attacker won't have the exact counter, or if they do you'll have 2 systems transmitting the same count and can tell one is forged. This won't work for all applications, but is one way of combating the problem.

A note on the two

The difference between Session Fixation and Hijacking is only about how the session identifier is compromised. In fixation, the identifier is set to a value that the attacker knows before hand. In Hijacking it's either guessed or stolen from the user. Otherwise the effects of the two are the same once the identifier is compromised.

Session ID Regeneration

Whenever you regenerate the session identifier using session_regenerate_id the old session should be deleted. This happens transparently with the core session handler. However some custom session handlers using session_set_save_handler() do not do this and are open to attack on old session identifiers. Make sure that if you are using a custom session handler, that you keep track of the identifier that you open, and if it's not the same one that you save that you explicitly delete (or change) the identifier on the old one.

Using the default session handler, you're fine with just calling session_regenerate_id(true). That will remove the old session information for you. The old ID is no longer valid and will cause a new session to be created if the attacker (or anyone else for that matter) tries to use it. Be careful with custom session handlers though....

Destroying a Session

If you're going to destroy a session (on logout for example), make sure you destroy it thoroughly. This includes unsetting the cookie. Using session_destroy:

function destroySession() {
    $params = session_get_cookie_params();
    setcookie(session_name(), '', time() - 42000,
        $params["path"], $params["domain"],
        $params["secure"], $params["httponly"]
    );
    session_destroy();
}

Both session attacks have the same goal: Gain access to a legitimate session of another user. But the attack vectors are different:

• In a Session Fixation attack, the attacker already has access to a valid session and tries to force the victim to use this particular session.

• In a Session Hijacking attack, the attacker tries to get the ID of a victim’s session to use his/her session.

In both attacks the session ID is the sensitive data these attack are focused on. So it’s the session ID that needs to be protected for both a read access (Session Hijacking) and a write access (Session Fixation).

The general rule of protecting sensitive data by using HTTPS applies in this case, too. Additionally, you should to do the following:

To prevent Session Fixation attacks, make sure that:

• the session ID is only accepted from a cookie (set session.use_only_cookies to true) and make it for HTTPS only if possible (set session.cookie_secure to true); you can do both with session_set_cookie_params.

To prevent Session Hijacking attacks, make sure that:

• the session ID in the cookie is only readable by your server (set session.cookie_httponly to true)
• an additional source of entropy is used (see session.entropy_file) as PHP’s random number generator has a known weakness; many security advisories suggest at least 128 bit of entropy length (see session.entropy_length)
• a strong cryptographic hash function is used (see session.hash_function); at best it is a computationally expensive hash function like Whirlpool that for example is five times slower than MD5 and thus allows only a fifth of the number of hash operations in opposite to MD5.

To prevent both session attacks, make sure that:

• to only accept sessions that your application have initiated. You can do this by fingerprinting a session on initiation with client specific information. You can use the User-Agent ID but don’t use the remote IP address or any other information that might change from between requests.
• to change the session ID using session_regenerate_id(true) after an authentication attempt (true only on success) or a change of privileges and destroy the old session. (Make sure to store any changes of $_SESSION using session_write_close before regenerating the ID if you want to preserved the session associated to the old ID; otherwise only the session with the new ID will be affected by those changes.)
• to use a proper session expiration implementation (see How do I expire a PHP session after 30 minutes?).

The tokens you mention are a "nonce" - number used once. They don't necessarily have to be used only once, but the longer they're used, the higher the odds that the nonce can be captured and used to hijack the session.

Another drawback to nonces is that it's very hard to build a system that uses them and allows multiple parallel windows on the same form. e.g. the user opens two windows on a forum, and starts working on two posts:

window 'A' loads first and gets nonce 'P'
window 'B' loads second and gets nonce 'Q'

If you have no way of tracking multiple windows, you'll only have stored one nonce - that of window B/Q. When the user then submits their post from window A and passes in nonce 'P', ths system will reject the post as P != Q.

I did not read Shiflett's article, but I think you have misunderstood something.

By default PHP passes the session token in the URL whenever the client does not accept cookies. Oherwise in the most common case the session token is stored as a cookie.

This means that if you put a session token in the URL PHP will recognize it and try to use it subsequently. Session fixation happens when someone creates a session and then tricks another user to share the same session by opening a URL which contains the session token. If the user authenticates in some way, the malicious user then knows the session token of an authenticated one, who might have different privileges.

As I'm sure Shiflett explains, the usual thing to do is to regenerate a different token each time the privileges of a user change.