Prevent PHP sesison hijack, are these good ideas?

Question

I'm doing a simple shopping cart for a small site.

I plan to store cart items as well as logged in user_id in session variables.

to make things a little more secure, I thought I'd do this:

1. sha1() the user_id before storing it in the session.

2. Also sha1() and store the http_user_agent var with some salt, and check this along with the user_id.

I know there is more one can do, but I thought this at least helps quite a bit right? and is easy for me to implement.

Keener

Answer 1

I think you misinterpret what session hijacking means. Your first idea doesn't seem to prevent session hijacking at all.

When you session hijack, you are stealing someone's session ID and pretending to be that session id. The user isn't able to change any actual session data, so it doesn't really matter if you encrypt/hash anything, as they won't be able to access it.

What you might want to do is store the IP and User Agent string in the session, and check it before declaring the user logged in on each page load. If the IP and User Agent doesn't match, chances are you should prompt them to log in. (Well, at least make sure the User Agent is the same)

Loralorain

Right, yes thanks for pointing that out!. I thought perhaps a hijacker could sort of fake a session and guess user_ids. So storing the ip and user agent, a hijacker could still steal that data right but they would have to actually fake their IP and own user agent to match? – Keener

The user can't directly access or change anything in $_SESSION. The only thing that they could potentially steal is PHPSESSID. There's no point obfuscating anything IN session data because only the server has access to it. – Loehr

Stay away from requiring an IP address match. Many folks out there have ISPs that change their IP addresses several times within a ten minute period. I kid you not. – Trowbridge

Answer 2

I thought this at least helps quite a bit right?

Not really. Hashing a user_id does nothing since the user_id is already presumably part of your session.

Hashing an IP or UA and requiring it to match is a weak form of verification that will also cause you serious accessibility difficulties. Proxied users may come from a different address each time; users may have a dynamic IP that changes regularly; a single IP may represent many actual customers. In all, this will cause more problems than it solves.

In any case none of this does anything against XSRF attacks, where the IP and UA will both match totally. See this question for some discussion of anti-XSRF strategies.

Octopod

Answer 3

Generally session hijacking refers to the notion that an individual attempts to access the session of the another, usually through a client-side substitution of data.

In example, person X fills out a login form at twitter.com. Twitter.com sends person X a cookie. Person Y, snoops the packet and manually inserts that cookie into their browser and visits twitter.com to find out they are logged in. This is session hijacking.

Then there is session fixation which is where I give you a link http://www.blah.com/?phpsessid=1234 and then pray that you go there and login, not noticing the PHPsessid in the URL. If you do, and if the site does not regenerate the session ID (as it always should on permission state change), then the hacker can now visit blah.com/?phpsessid=1234 and they will be logged in as you. In this manner they didn't have to snoop the session id because they were the ones who gave it to you.

Here is an excellent site with info on preventing basic PHP session hijacking which I believe can be a primer for your research.

http://phpsec.org/projects/guide/4.html

Amazed

phpsec.org is where I got the idea for using storing and checking the user_agent. Perhaps I'll just do that. It's easy to implement and better than nothing. – Keener