6

I was trying to build my own secure PHP Sessions Class, when i was actually wondering what's stopping someone from emulating the session?

IE, why wouldn't a code on test.php

$_SESSION['logged_in'] = true;

Not be able to work on index.php where

if($_SESSION['logged_in'] == True){
 echo 'logged in';
}

I understand that the way about this is to secure the session by generating a secure ID by locking it to the IP Address and User Agent, but how exactly does that work?

Meaning if i were able to guess the session ID would i be able to set the $_SESSION['logged_in'] = true and emulate the login? Should i then change the SESSION variable to check for login to a more secure one?

Sorry for my questions and hope i make some sense...

Ja͢ck
  • 170,779
  • 38
  • 263
  • 309
user2587774
  • 125
  • 9
  • Do you have `session_start();` on every page? – Mark Oct 03 '13 at 08:06
  • 1
    You should take the WebGoat lessons from OWASP, they help you to understand things better, which is a requisite to create secure things.https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project – pdu Oct 03 '13 at 08:10
  • 1
    More lessons [here - Damn Vulnerable Web App](http://www.dvwa.co.uk/) – Aaron Gong Oct 03 '13 at 08:13

2 Answers2

6

First of all, session data is only stored on the server, so an outside client can't simply create their own session data and send it to your server.

It therefore comes down to actually guessing the session identifier of someone else and assume their identity; this is quite difficult, but not impossible. In a situation whereby an attacker can tap the network traffic between the victim and your server, it's downright impossible to stop them.

There are a few things you can adopt to make things safer, though:

  1. Use SSL; see also session.cookie_secure.
  2. Generate identifiers from a good random source, i.e. /dev/urandom on Linux machines; see also session.entropy_file.
  3. Regenerate the identifier when a user logs in or out; see also session_regenerate_id()
  4. Use HttpOnly cookies (and only cookies) to perpetuate a session identifier; see also session.use_only_cookies and session.cookie_httponly.
  5. Use strict sessions; see also session.use_strict_mode.
  6. Keep a computed hash of the user agent in the session and make sure it doesn't change, e.g.:

    $_SESSION['_agent'] = sha1($_SERVER['HTTP_USER_AGENT']);
    
  7. Try to reduce the lifetime of a session as short as possible and use an advanced "remember me" feature to regenerate sessions as they expire.

It's also important to know when a potential hijack has taken place and take appropriate action when that happens. You will need to keep track of which sessions belong to which user so that you can invalidate all of them when one of them has been breached.

Btw, locking the session to an IP address is tricky; some ISP's will make it seem that a user comes from various addresses or multiple users come from the same address. Either way, it might be better to keep track of the user agent, since that's less likely to change.

Ja͢ck
  • 170,779
  • 38
  • 263
  • 309
  • @user2587774 You're welcome; if it helped answer your question, do consider to accept it as your answer :) – Ja͢ck Oct 03 '13 at 14:38
3

Guessing the session id is not session hijacking. It is harder than to guess a password. But yes, if someone did get a session id, they would gain full access to the account in question.

Locking by the ID address simply means that you store the original IP address the user used when logged in in the session itself and check it at the beginning of every request to see if it hasn't changed. This way, even if an attacker gets the correct session id, they still won't be able to use it.

There's a good Wikipedia article on the topic, as well as related StackOverflow questions: 1, 2.

Community
  • 1
  • 1
Denis
  • 5,061
  • 1
  • 20
  • 22
  • You know the `$_SERVER` variables can be spoofed. So, you can't rely on `$_SERVER['REMOTE_ADDR']` for authentication, and specially in the age where [dynamic IP](http://www.noip.com/blog/2012/05/24/what-is-a-dynamic-ip-address/) is widely being used. Meaning, a user could be logged out, because the server changes the IP dynamically. – samayo Oct 03 '13 at 08:15
  • `$_SERVER['REMOTE_ADDR']` can be easily changed by the client, but it cannot be easily set to an arbitrary value equal to that of another client. – Denis Oct 03 '13 at 08:17
  • @Simon_eQ So how would one spoof `$_SERVER['REMOTE_ADDR']`? – Gumbo Oct 03 '13 at 08:18
  • So, what is the point relying in it? If the server changes IP every 5 means, then you should know, the user will be logged out every 5 minutes? – samayo Oct 03 '13 at 08:19
  • What? Servers rarely change IP addresses at all. – Denis Oct 03 '13 at 08:20
  • @Gumbo http://stackoverflow.com/questions/5092563/how-to-fake-serverremote-addr-variable/5092951#5092951 && http://stackoverflow.com/questions/6474783/which-server-variables-are-safe/6474936#6474936 – samayo Oct 03 '13 at 08:20
  • @Simon_eQ, your own second link clearly shows that `REMOTE_ADDR` is a server controlled value. – Denis Oct 03 '13 at 08:22
  • @Denis Wrong. I for one can tell you, I made small ControlPanel which allowed me to access mysql. I used to access my database from my phone, and it felt good while it lasted 5 minutes, and I had to log out, because Opera changed the IP for proxy reasons. And please read the first link too, not the second only – samayo Oct 03 '13 at 08:23
  • @Simon_eQ The attacker would need to guess the TCP sequence number to overcome the TCP handshake and be able to send the actual HTTP request. – Gumbo Oct 03 '13 at 08:34
  • 1
    @Gumbo What he means (I think) is that the client IP may change due to their ISP. – Ja͢ck Oct 03 '13 at 08:36
  • 1
    @Jack Well, I wouldn’t call that spoofing. – Gumbo Oct 03 '13 at 08:40
  • @Gumbo The underlying point is that if your IP address changes you would get booted out of your session. – Ja͢ck Oct 03 '13 at 08:43
  • 1
    @Jack Okay, this is absolutely true, but nobody argues against it. – Denis Oct 03 '13 at 09:14
  • There's a delicate balance between usability and security; binding an IP address against a session does neither any favours :) – Ja͢ck Oct 03 '13 at 12:23
  • I don't argue that, @Jack. The original poster assumed that in the question, I just clarified how the technique works, without passing judgement. – Denis Oct 03 '13 at 12:24