First of all, I want to say that in security the problem is never final. Having said that and not talking about other session-related topics and responding to the specific case of Session Hijacking , say the following:
session_regenerated_id()
for the sake of ease and / or maintenance must be performed after the correct validation of credentials. However I have seen applications where it is performed every 30 minutes and in extreme cases what I consider a paranoia at every request . In login for most projects ... it's enough! It does not solve but it makes it difficult!
Before session_regenerated_id()
is required to call session_destroy()
and why not session_unset()
... which clearly answers the question.
Using some fields in the session to validate the connection is also important, such as HTTP_USER_AGENT
or others. Also amenable to manipulation but one more time ... It does not solve but it hinders!
If session hijacking is a problem and depending on the project SSL responds to this problem. Once again it does not resolve completely because there is someone who says that he can "give back" to https but ... It hurts and much.
Very useful also a TOKEN
mechanism written in session for each request
followed by elaborate policies for process authorizations.
Finally the list does not end because the solutions can be many and had some more, nevertheless a study on the matter and the constant monitoring of the monitoring on the applied process is also an excellent complement to the solution.
In the applications that I create, I always make the user available to a page where they can see the active and open sessions and the already expired sessions ... which makes the user more informed and concerned, minimizing the problem.
Also say that PHP sessions are files stored on the server and this can cause some entropy to the server depending on the number of accesses putting it vulnerable to other types of attacks, but it depends of the type of project.