views:

623

answers:

3

Hi. I'm working on an RIA in PHP. To try to prevent session hijacking I introduced a token, generated at login, based off a salt, ISO-8601 week number and the user's IP.

$salt      = "blahblahblah";
$tokenstr  = date('W') . $salt . $_SERVER['REMOTE_ADDR'];
$token_md5  = md5($tokenstr);
define("token_md5", $token_md5);

Currently, it's passed by GET or POST with every request, but I was wondering if I could avoid this by offering it as a cookie, since it is dependent on the user's IP. I'm just now learning sessions, so I was wondering if there are any security concerns with doing that? Is it a bad idea?

+4  A: 

session_regenerate_id() is great for preventing session hijacking.

session_regenerate_id — Update the current session id with a newly generated one

Continuously rotate the session_id for every page visit. Makes it very difficult to hijack a constantly moving target.

Mike B
I do have that as well, but I thought that was mainly for fixation: if (!isset($_SESSION['generated']) || $_SESSION['generated'] < (time() - 30)) { session_regenerate_id(); $_SESSION['generated'] = time(); } Is a token overkill if I have it regenerate with every request (app is mostly ajax-driven)?
Greg
If you don't pass `true` to `session_regenerate_id`, the old session can still be used by a hijacker. Also, "difficult" isn't the same as "can't". If you do and the hijacker is successful, the user is booted off their session.
outis
A: 

I have done a RIA with the same approach you have done, and I just set up SSL on the application for security. Since Flex and remoting is sessionless. I d recommend using SSL. My co worker also developed an application with user login/logout and he did the same thing.

+2  A: 

Any data the user keeps can be stolen; any data a visitor sends could be spoofed. Better to store the remote IP in $_SESSION when the session is opened, and compare the remote IP with every request. If they don't match, it's probably a hijack. Generate a new ID and have the user log back in.

outis
Do you think I should do this in combination with a regular session regeneration and a token or drop the other two and just compare IPs? I suppose the current token does cover this though, since it's salted with the IP of the user trying to gain access. That is to say, spoofing the token of a valid user wouldn't do any good unless you share an IP -- right?
Greg
Definitely not in combination. Session regeneration doesn't gain you much in terms of security, but feel free to use it for other purposes. As for the token, a hijacker could generate their own if they could work out the salt (which makes it less salt and more a secret key) rather than stealing the target's token. Considering that data from the client isn't trustworthy and that the main point of sessions is the only thing you need to store on the client is a session ID, drop any scheme that stores data on the client. Server side, the IP (and date) isn't secret, so a hash isn't needed.
outis