Effective way to protect session hijacking in php

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:

1. Change the PHPSESSID key altogether to something generic like id
2. 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.
3. I would add a short session expiration.
4. 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.
5. Put a logout button, so that the user will be able to terminate his session.
6. Use javascript to count the time, over 5 mins will alert the user to continue his session.
7. 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?

UPDATE I thought to do this: Symmetric encryption on the session id with key A Symmetric encryption on a randomly generated token that will be in the post field with key

The randomly generated token will be appended to the session id too and then encrypted.

On Request, I should get those variables: $_SESSION['PHPSESSID'] (has the randomly generated token encrypted in it) $_POST['RandomlyGeneratedToken']

Decrypt session id with key A and decrypt randomly token with key B. Do 2 checks: -Check the token if it is the same as the token on the first request sent. -Check if the token exists in the sessionid.

Possibility for the hacker: -Bruteforce the session id. My session id is long enough it would take him time. I could employ a system that detects massive flow of requests from the same ip with different session id and slow him down with the sleep function.

-Eavesdrop the traffic and get the session id from the user and also the token and try to submit those. hmm... I will have to regenerate the session id with every request and expire the session quickly on certain pages..may be 1 minute.. But how fast can he eavesdrop?

Answer 1

"Change the PHPSESSID key altogether to something generic like id"

This is security through obfuscation and a weak on at that. The user only needs to view their cookies and put together which is being used for the session id to bypass this

"Generate token per page and put it on the page and then validate it as well as teh session."

this is an interesting idea. but what if the user has multiple pages open? can you support multiple tokens? when do the tokens expire?

"I would add a short session expiration."

Good idea but this might effect users who stay on a page for a long time and then hit refresh only to find that they are logged out too soon

"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."

why use RSA encryption? why not hash it with something one-way like SHA? don't forget to add salts or intialization vectors

"Put a logout button, so that the user will be able to terminate his session."

who ever hits the logout button? ;-)

"Use javascript to count the time, over 5 mins will alert the user to continue his session."

YES

"Save session in cookies only."

dont do this, save the data server side always. cookies can be manipulated as they are stored client side

as for your other comments: you can store your session variables in a database and this allows you to check for other things like ip address and the like (though you can check ip etc with custom session handling functions: http://php.net/manual/en/session.customhandler.php). However, if you use a database and you regenerate your session ID too frequently (e.g. with every page load) you'll find that if your user hits the refresh button rapidly the id will regenerate more quickly than your server can update it in the database and the session will be lost.

"How does session regeneration works, is the old session key destroyed automatically"

yes unless you write custom code then it depends on your custom code

I hope my answers were somewhat useful, but i recommend following the guidelines for OWASP for session management so that you follow best practices: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

EDIT

im not sure what do you mean by token? do you mean token as in session id? What value would that provide? Is your token a session variable? that doesn't make sense as it's value is stored server side the key to which is the phpsessid whose abuse you are trying to prevent.

Also- never count on a hacker's ability not to understand your logic. If they want to understand it they will.

lastly, why do you need so much security? there is such a thing as good-enough security (if you follow certain standards). you likely don't need to protect against foreign government hackers else you'd probably outsource this project. follow best practices outlined in easily googled tutorials or guidelines such as the OWASP one i provided above. It'll be sufficient :-)

edit "Also, you say the optimal storage is database? what about the last method that I described against brute forcing"

database session storage isn't necessarily optimal. you use it when you need to such as when you load balance multiple web servers that need to share session data.

two ways to hinder brute force attacks are to 1) have a really long session id, and 2) regenerate it frequently