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.

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)

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.

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