views:

56

answers:

2

I use HTTPS, but want to minimize the risk of someone evil crafting their own cookies with a session ID that someone else actually uses recently.

As a session variable I have an expiry time so the session is invalidated if it hasn't been used recently, so I figure the window of opportunity is when the victim is active or recently left the site without logging out properly.

I don't expect huge amounts of traffic and I use the standard php methods of generating session IDs. I believe the "risk" of someone actually succeed (or even try) hijacking someones session here is close to zero.

What I would want to do is to "identify" the remote user somehow, without using $_SERVER['REMOTE_ADDR']. My thoughts being that the attacker would have to both find a valid session ID, as well as impersonating the different properties of the actual user.

I don't want to force the user to use a certificate to log in. I want it to work in all standard web browsers, even for my grandmother and other non tech-people like her.

So, what I originally wanted to ask was: are there any "properties" of the HTTPS session that could be used? Would they be useful? If so, how do I find them? phpinfo() reveals nothing HTTPS specific. (Is it because httpd doesn't expose it?)

Should I just use a concatenation of HTTP_USER_AGENT + HTTP_ACCEPT + HTTP_ACCEPT_LANGUAGE + HTTP_ACCEPT_ENCODING + HTTP_ACCEPT_CHARSET or something similar that is assumed to be unique enough between users?

Very happy for all answers! (But please read the question before answering with only referrals to other questions on StackOverflow) Thank you!

+2  A: 

You need to ensure that you've got both the secure and http_only flags set on your session cookies. You also need to change the session_id when a user authenticates to avoid session fixation problems.

While what you propose should be relatively safe in terms of finger-printing, it's not really all that selective - otoh there are lots things which should NOT be used for fingerprinting (like CLIENT_ADDRESS) so its not really very easy to suggest something better.

Apart from my suggestions above, I'd recommend spending your time looking at other potential security problems.

C.

symcbean
+1 good advice.
Rook
+1 for concise advice about session fixation. Thanks!
MattBianco
+2  A: 

The OWASP top 10 is an excellent aid for this class of attacks. Specificlly you need to worry about these three:

A2: Cross-Site Scripting (XSS)

A3: Broken Authentication and Session Management.

A5: Cross-Site Request Forgery (CSRF) (Also known as "Session Riding")

Almost all of the $_SESSION variables are known to the attacker and can be any value. There is no point is checking these variables as it is trivial for an attacker influence them. A important exception is $_SERVER['remote_addr'] which is pulled directly from apache's TCP socket, thus this value cannot be spoofed or otherwise tampered with. However, if the attacker is on the same network segment (such as if he was sipping a cup of coffee right behind you at the cafe), then the attacker would have the same ip address.

Rook