Session hijacking and PHP

Question

Lets just consider the trust that the server have with the user.

Session fixation: To avoid the fixation I use session_regenerate_id() ONLY in authentication (login.php)

Session sidejacking: SSL encryption for the entire site.

Am I safe ?

Jerky

What sort of site is it? – Staffan

@MrXexxed a site where the developers don't want it to be hacked. – Usable

@The Rook, I was speaking to the OP, it was a genuine question, your comment is both facetious and entirely unhelpful. – Staffan

@delete me Why does it matter? People need to protect their users from attacks like session hijacking. Its sad that most developers don't care or don't know to stop such attacks. – Usable

possible duplicate of PHP Session Security, What is the best way to prevent session hijacking? – Chaparajos

Answer 1

Read OWASP A3-Broken Authentication and Session Management. Also read about OWASP A5-CSRF, which is sometimes called "session riding".

You should use this code in a php header file:

ini_set('session.cookie_secure',1);
ini_set('session.cookie_httponly',1);
ini_set('session.use_only_cookies',1);
session_start();

This code prevents session fixation. It also helps protect against xss from access document.cookie which is one way that Session Hijacking can occur. Enforcing HTTPS only cookies is a good way of addressing OWASP A9-Insufficient Transport Layer Protection. This way of using HTTPS is sometimes called "secure cookies", which is a terrible name for it. Also STS is a very cool security feature, but not all browsers support it (yet).

Usable

Your answer deserves at least a +10, and with my vote you got it. Couple of questions just to make sure I understood: 1) cookie_secure would enforce me to work always on https when in session, wouldn't it?! 2) What does cookie_httponly do? I read PHP explanation, but I don't get when it says that prevents JS form reading cookies, actually cookies should be read by JS in many circumstancies. Thanks, and FYI: since PHP 5.3.0 session.use_only_cookies is 1 by default it.php.net/manual/en/… – Sidelong

Answer 2

I would also suggest storing the user agent and ip information in the session, and verifying it on each request. It's not bullet-proof, but it is a fairly significant increase in robustness. While UA forging is really easy, IP forging, while possible, is MUCH harder... But you may have issues with users who are behind a round-robin IP system such as AOL users...

Quiberon

"ip forging" or more commonly called ip spoofing, is impossible for a TCP connection over the internet due to the three way handshake. However a legitimate user's ip address can change during a session due to load balancers on a corporate network or changing wifi hot spots. – Usable

It's quite possible. It just requires a MITM style attack (where the attacker gets access to one of the end point routers, and then can do what they wish)... – Quiberon

It's not "forging" if you can access packets routed to that IP. – Missal

Answer 3

the best practice i have ever found is save the session data to database or a text file. the database will have user agent, and IP record and check it every request for ensure that the session never been hijacked by other.

for example how session saved at database you can see the implementation at codeigntier session library. in my opinion this way fairly save to prevent someone to hijact session.

Stig

Checking the user agent is meaningless because this is an attacker controlled variable. Storing the session id in the database means that sql injection gives the attacker immediate access to the system, so he won't need to break a password hash to login. Checking the ip address is error prone because this can change on a legitimate system, for instance if he is behind a load balancer on a corporate network. – Usable

@Rook - You are assuming that the database is vulnerable to SQL injection. Proper use of prepared statements or stored procedures, and proper sanitation of parameters, will not allow SQL injection. – Backstretch

@Backstretch this is the equivalent of storing a password in plaintext in the database. One must plan on failure. – Usable

Ok Rook, how about you provide an actual solution instead of just saying what's wrong with every other (PROVEN) solution? I just think it's hilarious that you think session management in a database is a bad idea. – Backstretch