Session Security

Question

I'm working on a public site which will use DB backed user sessions keyed to a session ID. I'm trying to prevent session hijacking and tampering; the session data I return to the client has limited value in and of itself, but I'd like to prevent wholesale theft. I've worked out a little scheme here, but I'd like to get some feedback and criticism.

• When the session begins, the client is given a unique key and a hash of their session's data.
• On each subsequent request the client sends a session key + the hash of their session data.
• If the session data is modified, the client is provided with a new hash value reflecting their session data.
• If a request for comes in with an incorrect hash that does not match the database, the session is flagged as compromised. The request and all subsequent requests for the session result in a new session being created by copying the compromised session. The new sessions reference the session they were copied from for security auditing purposes.

I figure I can watch the requests which get compromised to scan for large-scale attacks.

Many thanks in advance.

Answer 1

That sounds fine.

One thing you might want to throw into your authentication algorithm is the IP address of where the user is coming from.

It might not be so great for current user authentication but in the event a session is compromised, a different IP would be a huge flag but you can use that information to add to an IP tables rule for blocking potential malicious users.

One other thought is to track the referring URL. In regards to malicious behaviour, seeing where someone is coming from for any consistencies may shed light of holes in the program (if any).

Answer 2

This seems relatively secure, but there are a couple of ways this can be circumvented:

• If the session key is stolen, the hash can be stolen too. As long as the legitimate client doesn't do anything, the hijacker can just take over, and maintain key/hash/data consistency. You won't see a thing until the legitimate client wakes up... if ever.

• In any case, if your hash is not cryptic / secure enough, it can simply be guessed from the data (which can probably be sniffed too). You should probably use some kind of random salt (per session, per user, per time-frame...) to make sure this is as hard to guess as can be.

Answer 3

I don't understand what the point of the session data hash is. What problem does it solve?

It will probably cause problems, e.g. when loading two pages in two tabs simultaneously. If the first request changes session data, but the other one is already sent, it'll have the incorrect hash.

Also, if you copy the old session, I don't know what you've achieved with this?

Just have a simple session id and:

• change it on login to avoid session fixation and
• lock it to an IP to avoid an attacker assuming control via sidejacking.

To prevent an attacker from seeing the data, you'll have to use SSL.

Answer 4

You can't count on the IP address being unique or not changing. Corporate firewalls routinely coalesce or even randomly change IP addresses via NAT translation. It can make the system more secure, but it plays havoc on server's authentication schemes that try to require the same IP address.

In the last few years there's another concern -- systems are a lot more mobile than they used to be. I routinely 'hibernate' my notebooks instead of shutting them down, but that means I'm coming from different at IP addresses at home, work, starbucks, etc. This can trip up servers with session timeouts as short as 15-30 minutes - it just takes the amount of time for me to get from my office to lunch, etc.