So Using an SSL certificate for encryption and using simple server directives of the following
session.cookie_secure session.cookie_httponly session.use_only_cookies
Seems to prevent about 99% of the problems related to session hijacking since I started using this for sites I run etc. It seems like the only reliable way to stop session hijacking is TO KEEP ATTACKERS FROM EVERY GETTING THE SESSION ID OF ANOTHER USER TO START WITH.
MY LINE OF THINKING ____________________
It's impossible on my site for an attacker to edit a cookie or just simply "guess" a session ID as the session Id's on my server are configured to be over 30 random letters and numbers long i.e. nobody could ever guess that beyond ridiculous mathematical theory as even guessing thousands of ID's a second wouldn't work.
I notice on a lot of other forums and stuff users try to figure out ways to stop attackers once they have a session ID but this line of thinking is again wrong as they shouldn't be able if at all possible to get another users session id to start with. Let us say they do though?
Here are some of the methods I've heard of to keep the session from being hijacked
1. You could save the users IP in session and if the IP doesn't match the last IP you expire the session....this seems like a HORRIBLE IDEA though as some ISPS change IP addresses constantly. So this isn't an option.
2. Just like with the IP address you could save the USER_AGENT from server and if it doesn't match the last one the session again expires but this also seems like a stupid idea because this can be spoofed or an attacker could use the same browser.
3. The regenerate session ID on the start of every page. While in theory this could help it's a fundamentally stupid idea because this would only work if you visited another page BEFORE AN ATTACKER HIJACKED YOUR SESSION USING THE OLD ID. If an attacker took over your session with your old ID and went to another page the ID would change again thereby actually logging out THE VALID USER AND KEEPING THE HACKER IN SESSION which would do the opposite of what was intended.
So there you have it. It seems like the only good method of stopping session hijacking is using the directives I outlined up top to STOP an attacker from getting session ID's. This focus on exotic methods to stop attackers once they have a session ID are flawed.
IS my thinking correct?