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.
Related
I'm confused about something and need some explanations.
In my practice I normaly see that 90% of PHP developers all sensitive informations like database connections, FTP, SMTP setup etc. store inside some variable, array, objects or constants.
I wonder now is better to use some ini file out of root and store there? Or is better to hide somewhere .ini file and deny access via .htaccess?
Generaly, I want to save that sensitive data on most secure way.
There is no perfectly safe choice, but some are better than others.
Don't save sensitive information in your project's source code -- you don't want your passwords and API keys on github.
Saving sensitive information in a database is fine, but then you still need somewhere to store the database credentials, and you're right back where you started.
You can save sensitive information in environment variables. These would usually be set up in your web server's configuration file(s).
Saving sensitive information in an ini file is fine, provided the following:
The file has the minimal permissions required.
The file is completely outside the web server's document root and thus can't ever be served directly. Don't put the file in your main directory and then use .htaccess to deny access to it.
The file is not committed to source control. If you're using git, edit your .gitignore so that the file is ignored.
These should also go without saying:
The user account running the web server process should never have write permission to the files it's serving.
Other non-privileged users on the machine running the web server process should not have read access to the files it's serving.
For me, I would suggest to store it in a dot file such .env (like what Laravel does), or environment variables, or INI file (as what you said above) as long as it is hidden from the world or if some hack your server, they won't be able to see it easily or they won't be able to access it.
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 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)
I'm having an issue with a Symfony2 site. I've got the codebase running on a production server, which is absolutely fine but I'm trying to get another developer started on the project and we're running into issues getting the build up and running. The environments are pretty much identical, the developer is using a Vagrant instance, the same provisioning on that instance was used to provision an EC2 instance on AWS.
When a form is submitted the action goes through and stores values to the session using Symfonys session handler before redirecting to another action which makes up step two of the form. I can see in Xdebug that the values are being added to the global $_SESSION variable, however when I reach the next break point in the second action the $_SESSION variable is missing the content that it had on the previous action. I'm not clearing the session anywhere, and as I said it works fine on production.
It's almost as if Symfony isn't storing session data between page loads, does anybody have any ideas?
Things tried
Adding cookie domain to the config
Setting permissions to 777 (just to test)
PHP Versions are one minor iteration apart (5.4.28-1 vs
5.4.27-1)
I had a similar issue after upgrading from PHP 5.4.27 to PHP 5.4.28, and in my case it was related to this bug: https://bugs.php.net/bug.php?id=66171
Quote from the description:
Second problem: When the session.save_path is a directory that
everyone can write into (like on Debian), even if it's not possible to
find the IDs of existing sessions, a local attacker can just create a
new session file with malicious session data, chmod it to 666 and
access any webapp hosted on the system with the session ID he chose.
The webapp then opens the session file and treats it as if it had
created it. My fix: fstat() the session, check the uid that created
the file. If it's neither the result of getuid() nor uid 0, ignore the
existing file.
They now compare the owner of the session files with the user executing the PHP script, and if the uids do not match, the session file will be ignored.
In my case, the apache user had write access to the session files through group rights, but because the uid did not match, PHP would not load the session files.
Have a look at your session files (you can find the save path in your php.ini file), and make sure the owner of the files match the user attempting to access them.
What's the best way to search if a PHP session has been created on the server?
For example, store the name Joe somewhere in a session, and then after Joe closes his browser, can I then lookup (in a php script elsewhere on my computer) if Joe's session still exists on the server (i.e. not yet expired)?
Session data is usually stored in the server's temporary directory (the session.save_path setting).
While it is theoretically possible to search through that directory, go through every session file, open it, and look for whether it's Joe's session, it's not a clean approach, and there are many ways it can break - for example if the server doesn't give you a list of the files in the temporary directory to start with. Or what if a user has multiple simultaneous active sessions?
If you really need this, you should probably create a custom session handler that stores its data in its own directory or database. For that custom handler, you can then implement an interface that allows you to query whether a certain user is logged in, or a specific session exists.
In the server the check the path set to store sessions in php using directive session.save_path
and then try decode the files in there using session_decode() method
More information can be found in below links
Location of session files
Reading Session Data