Session Management and Security

Question

This is my current session management:

if(!isset($_SESSION["user"]["authenticated"]) || 
    !$_SESSION["user"]["authenticated"])
  redirect("login.php");

if($_SESSION["user"]["browserHash"] != md5($_SERVER["HTTP_USER_AGENT"]))
  redirect("logout.php?err=browser_mismatch");

if($_SESSION["user"]["IPHash"] != md5($_SERVER["REMOTE_ADDR"]))
  redirect("logout.php?err=ip_mismatch");

if(!isset($_SESSION["user"]["nonce"]) || 
  $_SESSION["user"]["nonce"] == $_COOKIE["SITE_nonce"])
{
  $nonce = md5(mt_rand() . time() . $_SERVER["REMOTE_ADDR"]);
  $_SESSION["user"]["nonce"] = $nonce;
  setcookie("SITE_nonce", $nonce, (60 * 15), "/path");
}
else
  redirect("logout.php?err=nonce_mismatch");

I am aware of changing IP issues an plan on using only the first 3 parts of the IP address. But what I am concerned about is the attacker is able to sniff headers and such. Then I won't be protected right? If I were an attacker within the victims network, I would simply make a quick GET request after I sniff one response header and I will get the regenerated nonce. Is there really a way to prevent this?

If it wouldn't be too much, I was also hoping on getting an insight on my approach. How can this be circumvented? Am I missing something big?

If you are using SSL, you are off the hook. If not, there is always a way to sniff the login credentials, session cookie's or normal cookies and use them to fake an identity. What you could do is store as much information as possible in a database and check them everytime a request is done. This could include browser, operating system etc. As the cookie is tied to the browser which is normally installed on one pc, you would recognize changes and could react accordingly. — Sgoettschkes, Aug 26 '11 at 07:48

score 0 · Answer 1 · answered Aug 26 '11 at 07:51

0

To prevent sniffing of headers, you need to secure the connection over SSL/TLS.

answered Aug 26 '11 at 07:51

hakre

193,403
52
435
836

Jacco · Accepted Answer · 2011-08-26T23:08:29.433

Your approach with recreating the nonce will fail if the user makes a new request after you, on the serverside, updated the nonce, but before the user receives the new cookie.

this happens for example if the user hit's F5 after a failed page load or if they open a lot of links in new windows/tabs.

Drop the idea for the IP-check. The IP address can change completely for many reasons. Think about load balancing proxies or mobile users switching roaming area for example.

A user-agent change could be detected and you could ask for a their password, but having them relogin (and restart what they where doing) is not very user friendly.

All in all, you are trying to protect your system from session stealing, with a session based on a cookie value. You need SSL for this, all other options will do little in terms of security. A cookie based session token is the currently accepted method for managing sessions, and deemed safe enough.

Also, CSRF attack are way more dangerous than session hijack attacks, and you do not stop those with what you propose. So my advice would be: focus on that area first.

I see. I never thought of that scenario! I really was hoping that there is another way to implement Session Hijacking prevention other than SSL since I noticed that even "big" sites do not use SSL in all their pages. I am already doing readings on CSRF and I guess I really have to redo my links and forms to include 'transaction tokens or nonces' and really important transactions to ask for a re-authentication. I never thought protecting against these can be so hard! Thanks — Rolando Cruz, Aug 26 '11 at 17:47

Session Management and Security

2 Answers2