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.
Related
Hi I have to retrieve data from several web servers. First I login as a user to my web site. After successfull login I have to fetch data from different web servers and display. How can I share a single session with multiple servers. How can I achieve this?
When I first login it create session and session id saved on temp folder of that server. When I try to access another server how can I use current session that already created when I logged in. Can anybody suggest a solution?
You'll have to use another session handler.
You can:
build your own (see session_set_save_handler) or
use extensions that provide their own session handler, like memcached
In complement to all these answers:
If you store sessions in databases, check that garbage collecting of sessions in PHP is really activated (it's not the case on Debian-like distributions, they decided to garbage sessions with their own cron and altered the php.ini so that it never launch any gc, so check the session.gc_probability and session.gc_divisor). The main problem of sessionstorage in database is that it means a lot of write queries and a lot of conflicting access in the database. This is a great way of stressing a database server like MySQL. So IMHO using another solution is better, this keeps your read/write ratio in a better web-database way.
You could also keep the file storage system and simply share the file directory between servers with NFS. Alter the session.save_path setting to use something other than /tmp. But NFS is by definition not the fastest wày of using a disk. Prefer memcached or mongodb for fast access.
If the only thing you need to share between the server is authentification, then instead of sharing the real session storage you could share authentification credentials. Like the OpenId system in SO, it's what we call an SSO, for the web part you have several solutions, from OpenId to CAS, and others. If the data is merged on the client side (ajax, ESI-gate) then you do not really need a common session data storage on server-side. This will avoid having 3 of your 5 impacted web application writing data in the shared session in the same time. Other session sharing techniques (database, NFS, even memcached) are mostly used to share your data between several servers because Load Balancing tools can put your sequential HTTP request from one server to another, but if you really mean parallel gathering of data you should really study SSO.
Another option would be to use memcached to store the sessions.
The important thing is that you must have a shared resource - be it a SQL database, memcached, a NoSQL database, etc. that all servers can access. You then use session_set_save_handler to access the shared resource.
Store sessions in a database which is accessible from the whole server pool.
Store it in a database - get all servers to connect to that same database. First result for "php store session in database"
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.
During my research I have found opinions pointing in both directions on this issue. A discussion would be appreciated to clarify this issue.
We are aware of the obvious advantageous security aspects on storing the session data in the database.
Option 1:
Using the default session storage on the filesystem (defaults to /tmp)
Option 2:
Using session_set_save_handler() to
store the session data in the/a
database.
My questions are:
On a high traffic site, what example would give the best performance?
Is this a matter of system hardware and where the current bottlenecks on this specific site are? In this case, the site is heavily pointed toward displaying specific user data from the database. Possibly this would be a question in need of serverfault input.
The site will probably have to propagate on to multiple servers soon, to deal with load and accessibility from other parts of the world. Think CDN. Does this affect my decision? I'm thinking it would be much easier to manage session information between the different computers if it is stored in the database.
Reason why storing to /tmp isn't favored on high traffic sites is because they use load balancing. Load balancing effectively swaps which machine delivers the data. If the session is in /tmp, not all machines have the same /tmp directory which means your users might start appearing logged in or logged out for no apparent reason.
That's why some sites store data in databases. However, that's ineffective as every request to the site means pulling info from db, which means connecting constantly, transforming data from text to an array and so on.
So, there's the third option - store the session data with Memcache. It's really easy, and if you google-fu a bit about this, you'll find answers and you can set the whole thing up in less than 5 minutes.
That's about all that I need to ask
I am dealing with a site right now and I can't see a really significant difference in storing my sessions in a database table over and not doing so.
There are a couple reasons why I sometimes store session data in a DB. Here are the biggest two:
Security Concerns on a Shared Server If you're running on a shared server, the chances are that it's easy for other users of the server to meddle their way into your temp directory and have access to the session data you have stored there. This isn't too common, but it can happen.
Using Multiple Servers If you're upscaling and using more than one server, it's best to store the session data in a database. That way the data is easily available throughout your entire server stack (or farm depending on how big you're going). This is also attainable through a flat file system, but using a database is usually a more elegant, easy solution.
The only thing I can think of for not using a database is simply the number of queries you'll be running. For each page load, you'll have an extra query to gather the session data. However, one small extra query shouldn't make that much difference. The two points I outlined above outweigh this small cost.
Hope that helped a bit.
On a shared host when you have no control over who can access the directory where session files are stored. In this case storing sessions in the DB can offer better security.
And one scenario with which I have no experience myself, but I believe is a realistic scenario:
On a loadbalanced server farm where subsequent requests of one user can be dispatched over multiple servers. In this case you could choose to have one central DB server. In such a scenario, if you wouldn't have such a centralized session repository, session data of users would get lost because they could switch servers per request.
There is a huge difference when you are using several servers, with a load-balancing mecanism that doesn't guarantee that a given use will always be sent to the same server :
with file-based session, if the user is load-balanced to a server that is not the same as the one which served the previous page, the file containing its session will not be found (as it's on another server), and he will not have his session data
with databased-based or memcached-based sessions, the session data will be available from whatever server -- which is quite nice actually, in this quite of situation.
There's also a difference when you are using some shared hosting : with file-based session, if those are placed in the "temporaty" directory of the server (like /tmp), anyone might read your sessions files, depending on the configuration of the server. With DB-based sessions, this problem doesn't exists, as each user will have a different DB and DB user.
In addition to the above posts:
Database sessions (when session table is of Memory type) are faster.
When using file-based sessions, session file is locked until script ends. So, user cannot have two working at the same time scripts on server. This matters for example, when you write a download server. User downloads a file, script sends file to him, leaving session file locked. And user cannot at the same time browse the contents of file archive.
I wrote a PHP web-application using SQLite and sessions stored on filesystem.
This is functionally fine and attractively low maintenance. But, now it needs to run on a shared host.
All web-applications on the shared host run as the same user, so my users' session data is vulnerable, as is the database, code, etc.
Many recommend storing sessions in DBMS such as MySQL in this situation. So at first I thought I will just do that, and move the SQLite data into MySQL too. But then I realized the MySQL credentials need to be readable by the web application user, so I'm back to square one.
I think the best solution is to use PHP as a CGI so it runs as different user for each web-application. This sounds great, but my host does not do this it uses mod_php. Are there any drawbacks from an admin's point-of-view for enabling this? (performance, backward compatibility, etc)? If not then I will ask them to enable this.
Otherwise, is there anything I can do to secure my database and session data in this situation?
As long as your code is running as the shared web user, anything stored on the server is going to be vulnerable. Any other user could write a PHP script to examine any readable file on the server, including your data and PHP code.
If your hosting provider will allow it, running as PHP as a CGI under a different user will help, but I expect there will be a significant performance hit, as each request will require a new process to be created. (You could look at FCGI as a better-performing alternative.)
The other approach would be to set a cookie based on something the user provides, and use that to encrypt session data. For instance, when the user logs in, take a hash of their username, password (as just supplied by them) and the current time, encrypt the session data with the hash, set a cookie containing the hash. On the next request, you'll get the cookie back, which you can then use to decrypt the session data. Note however that this will only protect the current session data; your user table, other data, and code will still be vulnerable.
In this situation, you need to decide whether the tradeoff of the low cost of shared hosting is acceptable considering the reduced security it provides. This will depend on your application, and it may be that rather than trying to come up with a complex (and possibly not even very effective) way to add security, you're better off just accepting the risk.
I don't view security as all or nothing. There are steps you can take. Give the web db user only the permissions it needs. Store passwords as hashes. Use openid login so users provide their credentials over SSL.
PHP on cgi can be slower and some hosts may simply not want to support more than one environment.
You may need to stick with your host for some reason, but generally there are so many available that it is a good reminder for people to compare functionality and security as well as cost. I have noticed many companies starting to offer virtual machine hosting -- nearly dedicated server level security in terms of isolating your code from other users -- at what is to me reasonable cost.
A shared host is no way to run a web site if you are conscious about privacy and security of your data from the sites that you share the server with. Anything accessible to your web application is fair game for the others; it'll only be a matter of time before they can access it (assuming they do have incentive to do that to you).
"you can place your DB connection variables in a file below the web root. this will at least protect it from web access. if you're going to use file based sessions as well, you can set the session path in your user's directory and again outside the web root."
I don't have an account so I can't downvote that.. but seriously it is not even relevant to the question.
Duh you store stuff outside the webroot. That goes for any hosting scenario and is not specific to shared hosting. We're not talking about protecting from outsiders here. We're talking about protecting from other applications on the same machine.
To the OP I think PHP as CGI is the most secure solution, as you already suggested yourself. But as someone else said there is a performance hit with this.
Something you might look at is moving your sessions and db to MySQL and using safe_mode and/or open_basedir.
I would solve the problem with a infrasturcture change instead of a code one.
Consider upgrading to a VPS server. Nowdays you can get them very inexpensive. I've seen VPS's starting # 10$/mo.