I would appreciate some advice on options for the session save path.
I am writing some software for podcast management. I cannot assume that the users of the software have root access to their server or the ability themselves to create directories or change owners or permissions or the ability to change settings in php.ini. Nor can I assume that the servers on which the software will run will have safe mode activated or open basedir restrictions. I want make life more difficult for anyone minded to read session data which isn't theirs or to hijack a session.
I have two broad choices. One is to leave things as they are. The default session save path will presumably have 0777 permissions, with the risks that that entails. The other is for the software to create a new sessions folder. I can do this as a sub-folder of a folder which for other reasons requires 0777 permissions. The sessions folder would be owned by www-data, and permissions would be set at 0700. So no-one other than the web server could read the session data. However, the sessions folder would in principle be readable by a programme running as www-data on the same server. And it would be below the document root, so - again in principle - it would be accessible from the web (whereas the default session save path is not generally web accessible).
I am not convinced that the option of creating a new sessions folder significantly improves security overall. What do others think?
PS. Edit. The more I think about it, the more I conclude that session save path and the security of session data in it is a server administrator's problem, and not one that it is sensible to try to solve in an individual php script.
Session save path
Moderator: General Moderators
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: Session save path
Moving the session data to a new location can improve your security. This requires that the new location is not accessible by 3rd-parties. On a shared hosting server, the home account folder, and everything below it, is only accessible by the specific user. The same applies to databases. If you move your session data into the database, then only the specific users can access them. This certainly is more secure than keeping the session data in the temp directory of the system that can lead to poisoning and storage attacks.
I'm not sure about significance, but it does improve your security unless the server is not properly secured (e.g. improper permissions).cpetercarter wrote:I am not convinced that the option of creating a new sessions folder significantly improves security overall.
The application must take care of it. The server administrators can't simply make any global settings that dynamically apply to different applications differently. Only the applications know where they are located, what they can access, etc.cpetercarter wrote:PS. Edit. The more I think about it, the more I conclude that session save path and the security of session data in it is a server administrator's problem, and not one that it is sensible to try to solve in an individual php script.
-
cpetercarter
- Forum Contributor
- Posts: 474
- Joined: Sat Jul 25, 2009 2:00 am
Re: Session save path
Thanks for this helpful reply.
PS. Edit. In Debian systems (eg Ubuntu)I believe that the standard location of session save path is /var/lib/php5, which is owned by root with 0733 permissions. This means that www-data can write new files to the directory, and can read, change and delete existing files within the directory, provided that it knows the correct file name (ie the session id). But it cannot list the contents of the file (no read permission), and cannot therefore go on fishing expeditions to find and read files where it does not know the session id. This sounds a lot more secure than the 0777 permissions in /temp, since it makes it very difficult for anyone to access session files which they did not themselves create. Also, I understand that Debian systems do not rely on php to clear outdated session files in garbage collection, but use a chron job instead. This means that, if you change session save path in a script which is then run on a Debian server, there will be no garbage collection of outdated session files, unless the server administrator re-enables garbage collection in php.ini. Since a lot of folk have Debian servers, this is another argument against altering session save path in a script.
Is this true in all circumstances? The folder where session data are stored - regardless of where it is - must be readable by www-data (or whatever name the web server uses). So is it not readable by a php programme running somewhere else on the same server? If the server administrator has set open base_dir restrictions for each site on the server, this can of course be prevented, but that underlines my point about the security of session data being a responsibility of the server administrator.On a shared hosting server, the home account folder, and everything below it, is only accessible by the specific user.
Yes, I think that using the database to store session data is likely to be more effective, from the point of view of security, than changing the session save path.If you move your session data into the database, then only the specific users can access them. This certainly is more secure than keeping the session data in the temp directory of the system that can lead to poisoning and storage attacks.
PS. Edit. In Debian systems (eg Ubuntu)I believe that the standard location of session save path is /var/lib/php5, which is owned by root with 0733 permissions. This means that www-data can write new files to the directory, and can read, change and delete existing files within the directory, provided that it knows the correct file name (ie the session id). But it cannot list the contents of the file (no read permission), and cannot therefore go on fishing expeditions to find and read files where it does not know the session id. This sounds a lot more secure than the 0777 permissions in /temp, since it makes it very difficult for anyone to access session files which they did not themselves create. Also, I understand that Debian systems do not rely on php to clear outdated session files in garbage collection, but use a chron job instead. This means that, if you change session save path in a script which is then run on a Debian server, there will be no garbage collection of outdated session files, unless the server administrator re-enables garbage collection in php.ini. Since a lot of folk have Debian servers, this is another argument against altering session save path in a script.