Session spoofing (PHP)

Question

I am coding a website in PHP that contains the boolean $_SESSION['logged_in']. This is set to true when a username and password match are present in the database.

I am quite new to sessions and was just wondering if it could be possible for an unregistered (or, for that matter, registered) user to bypass the login process by setting this boolean to true, as would be possible with a cookie.

I understand that the user would have to manipulate a server-side variable from the client-side, but my questions are how easy would this be, how would the user go about accomplishing such a task, are there any known exploits, and what are the best practices / preventative measures to avoid this sort of attack?

Wheeled

If a client can change session data on the server without you specifically allowing it you have bigger problems than that. I would be more worried about some crappy shared hosting with some shared temp directory in which the session data is stored. Or even session fixation. – Haines

#6912723 – Hexa

The best practice to avoid is if you were assigning $_SESSION variables directly to unfiltered user input. NEVER TRUST INPUT FROM THE USER. EVER If indeed you are filtering the input, then I don't see how it could be done – Hexa

Is it "possible", yes. Can it be 100% prevented? Not by anything that can be controlled on your side. But, it is incredibly unlikely provided that you follow good standards. php.net::Sessions and Security – Gifford

Answer 1

Let's start with the good news: The $_SESSION array is by default completly invisible and inmanipulable by the client: It exists on the server, and on the server only, in an execution environment, that is not open to the client.

Now back to earth: It is quite easy, to get your PHP code "nearly right" and thus open a door between the client and the session as seen by the server. In addition to this, stealing a client session (including a cookie) is quite easy.

I recommend a few mitigations, that have been proven quite effective:

• Do not store a "logged in" value - instead store a "session cookie" value, and set the cookie to the client. On a client request make something along the lines of $loggedin=($_SESSION['cookie']==$_COOKIE['session']). This makes the attacker need both: cookie and session ID.
• Refresh the session cookie quite often, on a wrong cookie kill the session. If a black hat steals cookie and session, the next click by the real user will log out both and create a logable event.
• If your requests come from JS, think of creating a simple authentication function: Instead of sending the authentication token, salt it, pepper it with a timestamp, then hash it. Send salt, timestamp and hash. Make the server check the timestamp.

Interlanguage

I loved the salt pepper thing – Foundation

I don't understand how the 1) point should help. $_COOKIE is known to the client, if attacker get this cookie by XSS attack, he can login anyway. – Ampersand

Answer 2

It is not possible for anyone but your code to manipulate values in a session. For someone to bypass that, he'd have to have permission to run code on the server or exploit a security hole in your code or the server (either way a security exploit). If a user is able to do that, he probably doesn't need to bother with fiddling with session values, since he can do virtually anything else on the server directly as well.

Pooka

Answer 3

The only way I can see where this attack would be possible is if there is some other exploit in your code, or if they have access to your server (via another means). Of course, if they have access to your server, they have access to your database, sourcecode, probably web logs, possibly all raw internet traffic including passwords....

Modernistic

Answer 4

The most common problem encountered in the domain of sessions is Session Hijacking. This is due to the fact that sessions are associated with a session-parameter. This parameter needs to be supplied by the user everytime when he sends a Request to the server. As you can imagine if someone is able to guess or retrieve the parameter, they should they can 'hijack' the session.

Edit: For security measures against it take a look at the post of Eugen Reck.

Etherege