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.
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!
Have a questions, looking for an expert opinion
If a website is registered with a hosting company over a shared platform, then could that website's session variables be hacked by others working on the same shared platform?
Thank You.
I'd say shared hosts are less secure in that regard, as I've personally seen several shared hosts where everybody could view the temp folder where session files are stored. As php default dictates, file names equal session ID, meaning I could from there easily go to the corresponding site, put in the file name into a cookie, and thus hijack the session.
As mentioned in other answers and comments, competent hosts may avoid this through proper administration and sandboxing. Investigate yours.
There's also alternative session storage methods, such as through database. One could also regenerate the session ID often, to decrease the window for any potential hijack. Take a look at http://php.net/manual/en/session.security.php and http://php.net/manual/en/class.sessionhandler.php for some more details.
All that said, you're still better off avoiding sensitive data in session variables altogether.
At first you should ask yourself: Who do you trust? Sessions exist (besides sharing data between requests) to enable the developer to store and controll data outside the users reach. This was the problem and this is solved by sessions.
If you are in a shared environment it is possible for other processes and users to access your stored information and change it, but - and that's a big one - it is also possible for them to access your database and your code. So there is nothing to really help you in the case of evil attackers from within your system.
The only thing that will help is competent administration. In shared environments it is crucial to sandbox each application running on the server. They have to set session_save_path on a per user base, just as they should do with everything else.
I have found in my server, that some files are stored inside the webroot, for example
example.com/files/longnamewithcode_1234293182391823212313231230812.pdf
They are stored for a web app and hace sensible info on them.
If you access example.com/files you get an empty index.html, so you can't directly scan the directory. Anyway, I'm concerned about this: I feel that it is not safe and I would like to know what kind of attacks could be made to access the files. I understand that some brute force attack would be possible, but with the long code names I guess it's a less big problem.
Finally, I would say that the correct way is storing the files outside the web folder and return them with PHP, but I'm not sure I'll be able to have access to the code to change this.
If you have to make the files accessible from webroot by the webserver you can't really make it more safe than use sufficient amount of entropy in the file names, but that still not account for simply sharing a the links by users that get a hold of them somehow.
If you want to implement the permission checking inside php take a look into the various X-Sendfile implementations on popular webservers like, mod_xsendfile (apache), XSendfile (nginx) or X-LIGHTTPD-send-file (lighttpd). This allows you to use the webserver to serve the file basically as efficiently as simply accessing it from the webroot after you validated the accessing user.
have you considered an .htaccess file to restrict who is allowed to access those sensible files? you tagged it, but i'm not sure why you are not using it. =)
If you wish to block everything in the folder you can use an .htaccess file to block all connections.
Try
deny from all
in the .htaccess file in that directory. This will deny all access to anything in that directory including the index file.
The question is
Are the files supposed to be accessed by users freely?
If yes, don't worry about those files too much (as long as they're not writeable).
If no, i.e. users have to be logged in to download them, move them out from the publicly accessible folder and deeper into the application. Write a php script that will manage the permissions for the file i.e. /download?file_id=1.
Since the default /tmp is usually open to all accounts in a shared host it's generally advised to use session.save_path and set a different location.
Is it assumed that a better location is in /home/username/example_session_tmp/ as long as it's not in /home/username/public_html/?
If so, wouldn't that still be vulnerable in case a hacker were able to inject a script in public_html and read ../example_session_tmp/? Or is it the only way and it's generally assumed your site is secured from script injections?
Note: Database session handler is an alternative option but let's assume it's not possible.
If a hacker gets a script into your site, there isn't a lot you can do to stop him from snagging sessions. If your webserver has access to the sessions then that user will. No matter where you stick it the hacker can find with with a simple call to session_save_path.
To sum up:
Prevent hackers from getting access. Who cares about sessions if your server is wide open? Secure this first.
Setting the save_path to ~/sessions should prevent other shared hosting users tampering with your sessions. This does not prevent someone who gains access to your webserver from seeing and tampering with sessions.
I agree with you for putting in /home/username/example_session_tmp/.
But,
If you have only one site per server, you don't need to change the path
If you want to make shared hosting your solution, moving to a new path is a good idea (you can check for apache-mpm-itk or php5-fpm)
If you want to have multiple servers, the easiest way is to put the session in the database, or create a shared folder (nfs, samba) for the sessions files.