Session hijacking prevention methods?

Question

I read on how to protect a session in php, there are a few, but they are not so effective like adding to a session the useragent,ip and port and encrypting them both. What is a good way to prevent session hijacking? I thought to take the following steps:

Change the PHPSESSID key altogether to something generic like id
Generate token per page and put it on the page and then validate it as well as teh session. That would reduce my reliance on session alone for validation.
I would add a short session expiration.
Add more variables to the session id and encrypt it, so it would be longer and harder to crack. Perhaps I would use RSA encryption.
Put a logout button, so that the user will be able to terminate his session.
Use javascript to count the time, over 5 mins will alert the user to continue his session.
Save session in cookies only.
The difficulties that I heard are: When you use token per page, you need to disable the back button? why is that?

A few other things are also unclear? Is saving session in the database more secure? why? How more secure is to use SSL? How about regenerating session id very quickly, would it help?

What system would prevent brute-forcing the encryption key (would identifying the ip of the user who tries to flood the server with massive attempts to guess the session id would help?)?

How does session regeneration works, is the old session key destroyed automatically, what if the hacker obtains an old session key would it still work? Please, it is important for me to understand session security, because I am learning how to be a penetration tester?

Steve M · Accepted Answer

I think the first step is to encrypt the traffic.  This will prevent hackers from being able to sniff packets and grab someones session cookie.

Using a token per page, means there's 1 token for every page render which is included as part of the page submit.  The token from the page must match what was last rendered by the server and is validated on the server side with each page submission.  So using the back button would cause the token on the client to become out-of-sync with the server. 

-- Page A loads with token XYZ, the session also holds XYZ as the valid token value
-- Page A submits to the server with token XYZ, the server compares the two tokens and they match
-- The server does it's processing from Page A and generates a new token ABC and returns to the client Page B
-- Page B loads with token ABC, the session also hold ABC as the valid token value

At this point if I hit the Back button, Page A will display and it contains token XYZ.  If I try to submit page A again to the server, the server will compare XYZ from the page to ABC from the session and see they don't match.

Saving the session in the database doesn't buy you anything.  The key is trying to prevent a client from overtaking a users session.  The memory on the server where the session is stored should be secure. 

What  you want to do is use SSL, as I said to prevent sniffing of the line.   The entire session should be encrypted (SSL), not just the login.  Encrypting the login process may protect the users password, but it doesn't protect the session cookie used from that point forward.  If the attacker has the session cookie, they don't need the password--for that session.  

Regenerating the session ID with each request is a similar tactic to the token but the session ID changes every time rather than a token.  So just as with the token, an old value does not work, you have to have the current value. 

I suggest visiting OWASP.org and reading up there.

Trending News

Session hijacking prevention methods?

1 Answer