What is best practice regarding the naming of the PHPSESSID cookie? Symfony2 allows you to change this via the configuration and you can also change it in php.ini's session.name.
Why would you want to though?
It allows you to run multiple applications on the same site that each need their own cookies to perpetuate the session id. Of course, the same could also be accomplished by setting the session cookie path and/or cookie domain properly.
Another reason could be that you want to hide the fact that you're using PHP and the name PHPSESSID is pretty indicative of that fact.
Or you just don't like the name; much up to you - the developer - to choose a pretty name if you want to.
It may also be considered as a kind of trivial "security through obscurity" practice. Various HTTP fingerprinting applications try to detect the technologies used to implement a web application by monitoring the server header, page prefixes, session ID cookie name (which you'll change) and behavior of the web server upon receiving crafted requests.
Although these kind of stuff barely increase the security of web apps, they may be used to fool potential attackers. Jack's answer points out the main benefit.
Related
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.
The PHP HybridAuth require the use of PHP session, however, we want to avoid using server side session since we are running the app on multiple machine.
We don't mind if user need to authenticate with provider every-time when needed, so, is it possible to avoid the need of using PHP session when using the HybridAuth?
[1] http://hybridauth.sourceforge.net/userguide/HybridAuth_Sessions.html
Short answer is no.
A longer answer is that it is possible (but in most cases will require sessions on the authentication provider) but to explain the options here would take far too long and from the tone of your question you would need a very detailed description of the potential options.
But this based on a premise that you can't have sessions across multiple machines. This is trivial. Even running sessions across multiple datacentres is a simpler solution And since you don't appear to be using the session for anything other than authentication you are not going to run into problems of scalability.
If you don't use PHP session mechanism for your application, you can override the default session storage by creating your own storage functions, with awareness of multiple servers.
For instance:
http://php.net/manual/en/function.session-set-save-handler.php
You can then either set the session in Memcached (for this particular case, you should only use php.ini with the following instructions: http://php.net/manual/fr/memcached.sessions.php), or MySQL, or a physical storage accessible by all servers (such as NFS).
Although, I think that even if you have multiple servers, default is to redirect the user to the same IP address (in DNS Round-Robin declaration, or in standard load-balancers), so a unique storage on each server, not visible by the other servers, should work.
I'm on board with the whole cookieless domains / CDN thing, and I understand how just sending cookies for requests to www.yourdomain.com, while setting up a separate domain like cdn.yourdomain.com to keep unnecessary cookies from being sent can help performance.
What I'm curious about is if using PHP's native sessions have a negative effect on performance, and if so, how? I know the session key is kept track of in a cookie, which is small, and so that seems fine.
I'm prompted to ask this question because in the past I've written my web apps and stored a lof of the user's active data, preferences, and authentication information in the $_SESSION variable. However, I notice that some popular web applications out there, like Wordpress, don't use $_SESSION at all. But sessions are easy to use and seem fairly secure, especially if you combine it with tracking user-agent / ip changes to prevent session hijacking. So why don't Wordpress and other web apps use php's sessions? Should I also stop using sessions?
Also, let me also clarify that I do realize the server must load the session data to process a page request, but that's not what I'm asking about here. My question is about if / how it impacts the network performance, especially in regard to the headers being sent / received. For example does using sessions prevent pages or images on the site from being served from the browser's cache? Is the PHPSESID cookie the only additional header that is being sent? These sorts of things.
The standard store for $_SESSION is the file-system with one file per session. This comes with a price:
When two requests access the same session, one request will win over the other and the other request needs to wait until the first request has finished. A race condition controlled by file-locking.
Using cookies to store the session data (Wordpress, Codeigniter), the race-condition is the same but the locking is not that immanent, but a browser might do locking within the cookie management.
Using cookies has the downside that you can not store that much data and that the data get's passed with each request and response. This is likely to trigger security issues as well. Steal the cookie and you've got the data. If it's encrypted, an attacker can try to decrypt it to gain the data stored therein.
The historical reason for Wordpress was that the platform never used the PHP Sessions. The root project started around 2000, it got a lot of traction in 2002 and 2004. As session handling was only available with PHP 4 and PHP 3 was much more popular that time.
Later on, when $_SESSION was available, the main design of the application was already done, and it worked. Next to that, in 2004/2005 wordpress decided to start a commercial multi-blog hosting service. This created a need in scaling the application(s) across servers and cookies+database looked more easy for the session/user handling than using the $_SESSION implementation. Infact, this is pretty easy and just works, so there never was need to change it.
For Codeigniter I can not say that much. I know that it stores all session information inside a cookie by default. So session is just another name for cookie. Optionally it can be encrypted but this needs configuration. IIRC it was said that this has been done because "most users do not need sessions". For those who need, there is a database backend (requires additional configuration) so users can change from cookie to database store transparently within their application. There is a new implementation available as well that allows you to change to any store you like, e.g. to native PHP sessions as well. This is done with so called drivers.
However this does not mean that you can't achieve the same based on $_SESSION nowadays. You can replace the store with whatever you like (even cookies :) ) and the PHP implementation of it should be encapsulated anyway in a good program design.
That done you can implement a store you can better control locking on (e.g. a database) and that works across servers in a load balanced infrastructure that does not support sticky sessions.
Wordpress is a good example for an own implementation of sessions handling totally agnostic to whatever PHP offers. That means the wheel has been re-invented. With a view from today, I would not call their design explicitly innovative, so it full-fills a very specific need in a very specific environment that you can only understand if you know about the projects roots.
Codeigniter is maybe a little step ahead (in an interface sense) as it offers some sort of (unstable) interface to sessions and it's possible to replace it with any implementation you like. That's much better for new developers but it's also sort of re-inventing the wheel because PHP does this already out of the box.
The best thing you can do in an application design is to make the implementation independent from system needs, so to make the storage mechanism of your session data independent from the rest of the program flow. PHP offers this with a pretty direct interface, the $_SESSION array and the session configuration.
As $_SESSION is a superglobal array you might want to prevent your application to access it directly as this would introduce global state. So in a good design you would have an interface to it, to be able to fully abstract away from the superglobal.
Done that, plus abstraction of the store plus configuration (e.g. all in one session dependency container), you should be able to scale and maintain your application well over as many servers as you like for whatever reason. Your implementation then can just use cookies if you think that's it for you. However you will be able to switch to database based session in case you need it - without the need to rewrite large parts of your application.
I'm not 100% confident this is the case but one reason to avoid the built-in $_SESSION mechanism in PHP is if you want to deploy your web application in a high-availability web farm scenario.
Because the default session behavior in PHP is to store session objects in process, in memory, it makes it hard (if not impossible) to have multiple servers processing requests from the same user. You would only have this if you wanted to deploy your web application in a web farm environment where you have a number of PHP web servers processing requests for your app to balance the load.
So, while in-process session state is generally much faster than a database-based solution, the latter is favorable when you need to process a huge number of requests and to service the capacity a web-farm environment is used.
As I said in the beginning, I'm not 100% sure if PHP supports configuring the session state provider to be a database, or session state server, instead of the in-process default.
I've seen many sites give up the use of the default handling of sessions in PHP for their own method and I still have no clue why.
They are definitely running PHP and it just seems pointless to me that people would design their own method. Is there some sort of limitation that I do not know of or is it purely so they have control of everything?
(I tried asking them and yeah they either didn't have a way of contacting them or they "saw something somewhere against using PHP sessions" without knowing what it actually was)
Default sessions are stored on the hard drive, usually in the /tmp directory.
When your site gets larger, 1 computer isn't sufficient to run it.
Therefore, people resort to load balancing (among other solutions).
Load balancer effectively switches between a cluster of computers. Therefore, if by any chance you got served by computer #1 on your first request and then by computer #2 at your second request - the second computer cannot read the session since it's not in its /tmp folder.
This is a simplified scenario of course since there's much more to application scaling but this is one of the reasons why people resort to overriding the default session mechanism.
The other thing of interest is storing sessions in the db thus making them searchable and what not. You can also create an interface for effectively forcefully logging people out, which is something that the default mechanism cannot provide.
I would have thought a principal reason for rolling your own session-handling functionality is for the purposes of testing. If you're running unit tests, you won't necessarily have a browser environment going. You won't be able to set cookies, and so PHP won't set $_SESSION variables for you.
If, however, you wrote your own session handling class(es), then you could create a mock class for running unit tests. The object would behave like a "real" session, but you won't have to faff about with browsers, cookies and human beings.
Well with the standard setup you are tied to using the file system, saving session data unencrypted etc.
Writing your own session handling using session_set_save_handler you can adjust the sesssion management to your needs ... applying encryption, saving session in a database, synchronizing the sessions with separate software systems ...
1) Session are still widely used. They works and do the work, so there is not point to change it unless a special case.
2) However, Session is weak, it relies in a single PHP (that can be stolen). However, it is possible to protect a session using different method such cookie + ip + expiration.
So yes and no. Session are still widely used but require a fine tune.
What are the security risks associated with turning off "session.cookie_secure" in PHP under secure connections? I'm itching to turn this off since I'm unable to access session data from https pages to http pages.
The risk is that the cookie data is transfered over plain HTTP. Anyone sniffing packets on the network would be able to view the data in the cookie. Then, they can pretend to be you (Session Fixation).
Now, some would argue that if someone can sniff packets on the network, that they are in a position to execute a MITM attack so it's not a huge deal. However this is not 100% correct. Look at what happened with Google. They were able to sniff raw WIFI traffic without actually compromising the network (which would be required for a MITM attack). Sending cookies over HTTP can open up session hijacking attacks where if you kept them to HTTPS only they would not be.
If you need access to be secure, keep secure_only set. If you don't care about the data (or use multiple-factors, or want to risk it), then open it up...
One potential workaround is to use a custom error handler, and set 2 session identifiers (one is secure_only). Then you can "log in" via both, yet require the secure one for anything important (Such as accessing important data. This would require some work to do correctly, but could be a decent solution to the problem...