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();
}
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
