11

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 ?

Improve this question
5
  • What sort of site is it? Commented Aug 18, 2010 at 22:57
  • 9
    @MrXexxed a site where the developers don't want it to be hacked. Commented Aug 18, 2010 at 23:43
  • @The Rook, I was speaking to the OP, it was a genuine question, your comment is both facetious and entirely unhelpful. Commented Aug 19, 2010 at 0:15
  • 3
    @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. Commented Aug 19, 2010 at 0:39
  • possible duplicate of PHP Session Security, What is the best way to prevent session hijacking? Commented Apr 19, 2012 at 9:21

3 Answers 3

Reset to default
28

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

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

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/…
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...

Improve this answer

3 Comments

"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.
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)...
It's not "forging" if you can access packets routed to that IP.
0

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.

Improve this answer

4 Comments

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.
@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.
@AgmLauncher this is the equivalent of storing a password in plaintext in the database. One must plan on failure.
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.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.