[web] PHP, sessions and security

Started by
23 comments, last by deadimp 16 years, 10 months ago
Hi all, I'm writing my own forum software, and I'm having a few issues with sessions. I'm using PHP sessions for logging users in, and keeping them logged in. The way I do this is, when a user logs in I check username and password, then store their user ID in $_SESSION. On each page, I call session_start(), then check to see if $_SESSION['uid'] is set, and if so then I grab that user from the database and use them as the active user. My questions are: 1) Is this secure? It just seems a bit horrible for me to be storing the user ID and then assuming it's correct. Is there not any way a user can fake the $_SESSION variable and log in as another user? 2) This requires cookies to be enabled, correct? And if so, is it worthwhile implementing some method that doesn't require cookies? 3) I see PHPBB doesn't use PHP sessions, it does it all manually. Anyone know if there's a good reason for this? Cheers, Steve
Advertisement
I'm pretty sure that PHP sessions just store a Session ID in the cookies and pulls the real session data from a database or flatfile of some sort. If someone were to get your Session ID and set it as their own, they might get access to the user secured information. If you're setting this up on a shared hosting environment, I believe session data is stored in /tmp and anyone else on the shared server could potentially get access to your session data. With access to that it would be fairly easy for someone to see what kind of information you're storing in the session and based on that, create or modify their own session on the server in order to log in to your system with false credentials.

As far as doing it without cookies, you'd have to create a hash of some sort based on their IP and browser info, both which are easy to spoof, or keep their 'session id' in the URL which is even easier to read then in a cookie.

All that said, I usually just use the $_SESSION variables.
I use your simple $_SESSION['uid'] method, but also keep track of a few bits of information (their browser type and IP address hashed along with a password) and if this changes after they log on then their session is cleared as a crude defense against session hijacking. (Session hijacking is the term you might want to look up - there is a vast amount of information on this topic). IP addresses are not exactly bullet-proof (two people on a work network could share the same IP, or the remote IP might change depending on ISPs).

The only security issue I've had thus far was using a particular page you could view other user's details - and by looking at their details you'd end up logged in as that user. This, however, was simply because register_globals was enabled and setting the local variable $uid was also overwriting the value in $_SESSION['uid'].

[Website] [+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++]

Awesome, that's all good to know, thanks. Any ideas about #3? One person told me "Because it's a bloated piece of s*it" [smile]
Isn't PHPBB notorious for having security problems? I wouldn't base any decisions on what they have implemented.
Quote:Original post by Evil Steve
Awesome, that's all good to know, thanks. Any ideas about #3? One person told me "Because it's a bloated piece of s*it" [smile]

Reasons phpBB might do it are:

  • PHP hasn't always had built in session support; maybe it's a hold-over from an earlier incarnation.

  • If the server is set up wrong, it can break the built in session support (for example, when I tested a PHP based website on the sourceforge project web servers, I found that session support was disabled/broken, so I had to write a session data handler to put all the session data into MySQL instead).

  • For servers that host several sites (ie, most of them), there will only be a single location used to store session data, and it will be readable and writable by the user under which PHP is running (or for slightly less well run web-hosts, it will be world readable/writable). This means that anyone else with hosting on that machine can write a script to access or edit that session data. That is of course a security hazard (although really, it's pretty hard to set up a server to have multiple virtual hosts and maintain security between them - insecure session data isn't really the biggest problem)

  • PHP can be configured to not use cookies to pass session IDs, or to try using cookies and fall back if they don't work. The alternative/fall-back is for PHP to scan the HTML that you're emitting, and modify any tags that contain links so that it can add the session ID to the query string. Personally, I've always found this to be a big pain in the butt, and very unreliable. You have some measure of control over it through the PHP configuration, but you just can't get the same amount of control that you'd get by doing it manually.


So the simple answer is: phpBB includes its own session handling code because PHP sessions are highly dependant on the server being configured correctly for the situation, and that just isn't something that can be relied upon for a piece of software designed to just start up and work correctly on almost any server.

John B
The best thing about the internet is the way people with no experience or qualifications can pretend to be completely superior to other people who have no experience or qualifications.
Quote:Original post by tstrimp
Isn't PHPBB notorious for having security problems? I wouldn't base any decisions on what they have implemented.
Good point [smile]
Quote:Original post by tstrimp
Isn't PHPBB notorious for having security problems? I wouldn't base any decisions on what they have implemented.


phpBB is mostly notorious for older versions being exploited, and vast masses of users not running the latest versions because the modified their forum's code (phpBB 2.x does not have a plugin system for modifications). Someone once wrote a worm that exploited some older versions. If you run phpBB you should upgrade when a new version is released. Collary: don't modify your forum's code (much).

<hr />
Sander Marechal<small>[Lone Wolves][Hearts for GNOME][E-mail][Forum FAQ]</small>

What you might want to do is store a login hash, that way you don't need to have a password in the session directly, but you can still verify credentials.
Quote:Original post by Pete Michaud
What you might want to do is store a login hash, that way you don't need to have a password in the session directly, but you can still verify credentials.

You should never store a password in the session.

What would be the point of that anyway? You only log in once, after that the newly created session can be identified using its session id (which in turn can be stored in the database together with other information like the user's ip address, to increase security).

This topic is closed to new replies.

Advertisement