I have a client that is own a shared host the uses php sessions. The session save path is /tmp by default. They are having random logouts.
Could this be caused by any/all of these?
Garbage collection by other user on the server?
Someone clearing out /tmp files (User or cron). This seems unlikely as the host I am using is pretty well known
I can change the session save path to a folder under their control. Do you think this would be the best solution? I know shared hosts sessions are insecure as anyone can read them (and I think even write to them via nobody/apache user)
Related
I've seen this many times, especially when inspecting (older) browsergame scripts, storing they user sessions in e.g. /project/sessions or /project/tmp. Is there any valid reason not to use the default session save path?
From manual:
Warning
If you leave this set to a world-readable directory, such as /tmp (the
default), other users on the server may be able to hijack sessions by
getting the list of files in that directory.
Also usually the default temporary directory get cleaned on reboot and session data may be lost.
We have PHP5 FPM set up under Nginx. We use Memcached as our session handler.
session.save_handler=memcached
My expectation is that, without fail (notwithstanding some fatal error like the death of our Memcached server) that all sessions should make it to Memcached and explicitly NOT disk.
However, upon inspecting our application, I've found sessions on Memcached AND in /var/lib/php5/fpm/.
Some troubleshooting:
We are definitely getting new sessions set on Memcached. However, some sessions that I found on disk, don't appear on Memcached
The timestamps on the file based sessions are definitely recent - there are files in the current minute.
Permissions on the files are for the installation user - not root.
Despite having said point 3 above, there are SOME files that have the root user and group ownership. This I find weird. Why would there be sessions owned by root? That would mean that anyone trying to check the file (that has 0600 permissions btw) would fail.
So, I guess my questions amount to:
Is there any scenario in which it is valid that new session files are created on disk despite the fact that we use Memcached?
Any idea why we'd have session files that have a root ownership?
For context: I'm researching very sporadic session expiry issues. After having increased Memcached memory limits and concurrent connections (and that ultimately fixing a large number of the instances) we're still experiencing a small amount of the session expiries. Anyway, that is simply context - might not be important.
The session files were created by php-cli started by cron. cli config differs from fpm one and uses default file session handler.
Edit
Importantly, the cronjob must either be hitting a piece of code that manually starts the session
OR
the configuration directive session.auto_start for PHP5-cli must be set to true
I have learned that if I share a server with another host (which I do, as I have a virtualhost), then all the hosts share the same $_SESSION is the same across all the hosts.
Does it meant that other hosts can access some of the variables that I store in the $_SESSION?
Check the value of the following:
echo ini_get('session.save_handler');
echo ini_get('session.save_path');
If your save_handler is files and your save_path is a common directory like /var/lib/php5 then you're likely sharing session storage with other users on the server. You're still protected by the nature of the session hash id, but if you have sensitive information you might want to make a change. You could either change the save_handler to something like sqlite and provide your own local database file, or simply change save_path to a directory that's owned by you and has minimal permissions. You can change save_path in a .htaccess file:
php_value session.save_path = '/path/to/my/session/directory'
Or in your PHP source:
ini_set('session.save_path', '/path/to/my/session/directory');
Edit: Realistically though, if you have information sensitive enough to warrant this change, then you should be using a VPS and not a shared server.
Does it meant that other hosts can access some of the variables that I store in the $_SESSION?
I would say yes if the session id is the same and if using default configuration for sessions. In regards the session id being large, the chances of hijacking are pretty low, but then again anything is possible, even when using a single virtual host. It all depends on your particular circumstances.
But for all practical purposes I will dare to say you will be ok.
Good luck!
I read this post where the author advices to store session files in a different location on our application since sessions in /tmp/ are not safe. Is this a best practice that everyone follows? How safe does putting session files into other location will make any difference?
Need your valuable advice on this.
Thank You.
The problem is only that if you're on a shared host, the /tmp directory is typically shared by everybody, so other users will at least be able to list all files in the /tmp directory. They don't typically have access to those files, but just being able to see them may already be quite a security risk. Therefore it's better to store your temporary data elsewhere where only you have access.
This is not really of any concern if you are the master of your own server.
We have an array of autoscaling web servers on the cloud sharing sessions via a shared Network Attached storage.
We are considering other solutions but in the meantime I am looking for ways to make our system fault tolerant.
E.g. if shared storage is not available for whatever reason I would like php to ignore my session.save_path setting and fallback to the local filesystem instead.
Is there any clever workaround that would make this possible via standard php configuration?
You could use auto_prepend_file and do the check there and set the path to local if the path in the cloud is not available. This is not a fully automatic, ini only solution, but close to it.
Recommendation: if you want to share the session across several machines better use a database stored session solution.