6

I have a site where a user can create an account and log in. When the user logs in, after I validate the user's password and username, I give them a PHP session variable containing their username. That is how they access features on my site such as creating a blog post and changing their user bio.

Can someone wanting to get on my site through another person's account fake a session variable containing the username of the user? If so, how can they do this? And are there any ways to prevent this?

  • Can you elaborate what exactly you mean by session variable and “contains username”? You cannot mean cookies and the user name in plain text. Maybe the $_SESSION object contains the username? Why don’t you use a database? – Tobi Nary May 10 '18 at 7:56
  • "Can someone wanting to get on my site through another person's account fake a session variable containing the username of the user? If so, how can they do this? And are there any ways to prevent this?" "Short" answer Yes if the attacker is on the same webhosting and all apache virtual hosts share the same session directory.. This attack is called session poisioning you can prevent it by using always using session_save_path() – Raymond Nijland May 19 '18 at 11:12
5

No. Session data is stored on the server.

The session ID is the only thing transferred back and forward between the client and the server. Therefore, unless the server is hacked or has a server-side bug, the client cannot change the session data directly. In your case, the username in the session variable seems to be part of the session ID or it's replacement (this is a little unclear).

That does not mean that the system does not have to ensure that only the valid client knows the session ID, because that's what links the client to the specific session. That is why the session_regenerate_id() function must be used every time a login attempt is performed. This prevents session fixation.

| improve this answer | |
  • 2
    "unless the server is hacked or has a server-side bug, the client cannot change the session data directly" Not complety true.. If the attacker and victim share the same webhoster and the server is configured to store all apache virtual hosts sessions within one directory.. A attack that is called session poisioning through session modification is possible... it's like a session fixation attack through two virtual hosts (domains) session_regenerate_id() would indeed also would stop this attack.. Better is to use a session_save_path() so your sessions are in a other path. – Raymond Nijland May 19 '18 at 11:18
  • 1
    It's still a server-side miss-configuration. – Overmind May 21 '18 at 5:08
2

The PHP sessionid issued after a successful login is generated on the server-side and only contain random data. The sessionid is sent as a cookie, and is included in every subsequent request from the client.

The session data is stored on the server, and the session id is used to reference this data for each request. The PHP sessionid is considered secure.

This has not always been the case. In previous versions of PHP, the session id was random, but the random generator was only seeded by the servers current time, remote address and process id. Once an attacker was able to figure out the state of the random generator, she could predict previous and future session id's. See http://seclists.org/fulldisclosure/2010/Mar/519

This made it possible for attackers to steal sessions for other users.

What have happened since then, is that PHP in addition to the old weak generation, it fetches 32 bytes from a good random source such as /dev/urandom on a linux system.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.