Why Cookies Are Better Than Sessions
In the past I’ve gotten quite a bit of heat from my colleagues for utilizing cookies over sessions with PHP, and I’ve finally had enough! I will now go ahead and explain the reasons why I use cookies over sessions for everything.
Cookies have been around since day one with dynamic scripting languages. They were the first tracking mechanism ever utilized on the internet and will be the last. Here’s a definition straight from Wiki:
HTTP cookies, sometimes known as web cookies or just cookies, are parcels of text sent by a server to a web browser and then sent back unchanged by the browser each time it accesses that server. HTTP cookies are used for authenticating, tracking, and maintaining specific information about users, such as site preferences and the contents of their electronic shopping carts. The term “cookie” is derived from “magic cookie,” a well-known concept in unix computing which inspired both the idea and the name of HTTP cookies.
Cookies have been of concern for Internet privacy, since they can be used for tracking browsing behavior. As a result, they have been subject to legislation in various countries such as the United States and in the European Union. Cookies have also been criticised because the identification of users they provide is not always accurate and because they could potentially be used for network attacks. Some alternatives to cookies exist, but each has its own drawbacks.
Cookies are also subject to a number of misconceptions, mostly based on the erroneous notion that they are computer programs. In fact, cookies are simple pieces of data unable to perform any operation by themselves. In particular, they are neither spyware nor viruses, despite the detection of cookies from certain sites by many anti-spyware products.
Most modern browsers allow users to decide whether to accept cookies, but rejection makes some websites unusable. For example, shopping baskets implemented using cookies do not work if cookies are rejected.
While sessions can make the tasks of the programmer easier they open up a lot of nasty holes which you need to immediately close and fix. The two most notable vulnerabilities to sessions are the following:
Session Fixation: These are attacks which attempt to exploit the vulnerability of a system which allows one person to fixate (set) another person’s session identifier (SID). This attack is greatly enhanced when the SID is attached to the query string. (Which usually is the case.)
Session Poisoning: These attacks exploit insufficient input validation in server applications which copies user input into session variables. The underlying vulnerability is a state management problem; shared state, race condition, ambiguity in use or plain unprotected modifications of state values. Session poisoning has been demonstrated in server environments where different non-malicious applications (scripts) share the same session states but where usage differ, causing ambiguity and race conditions. Session poisoning have also been demonstrated in scenarios where the attacker is able to introduce malicious scripts into the server environment, which is possible if attacker and victim shares a web hotel.
Before I start explaining myself you should also know that there are several vulnerabilities to cookies if used inproperly, as well. The following list is the main vulnerabilities with using cookies inproperly:
Cookie Theft: Cookies theft is any process allowing an unauthorised party to receive a cookie.
Cookie Poisoning: The process of tampering with the value of cookies is called cookie poisoning, and is sometimes used after cookie theft to make an attack persistent.
Both of the above mentioned cookie vulnerabilities are easily patched up with a bit of brain and leg work.
Firstly, use a “session identifier” as the cookie, instead of, say, the user’s ID or name. Save the session id in a database on the server as well as in the cookie on the clients computer. Set a crontab to delete the session id from the database after a certain time length to ensure limited tampering time.
Secondly, use encryption (SSL if possible) on and when you set the cookie in the database and clients computer.
These two methods of securement make it quite impossible to exploit.
To patch up and fix the vulnerabilities with sessions is impossible. Here are the reasons why:
1. (and only #1): Regeneration Of The SID On Each Request is pretty much the only way to fend off the attacks on sessions, and is quite impossible to use contently. Known cases where session regeneration may cause problems include when third party software such as ActiveX, Java Applets, or browser plugins communicate with the server as well. Third party software could cause logouts, or the session could be split into two separate sessions. In this day and age the websites which have user systems which need to utilize some form of tracking, be it a cookie or session, almost always uses third-party software, such as Flash, Java applets, or browser plugins, mentioned above.
So, the developer is left with the decision of either being able to use third-party software securely with cookies or only their own software with sessions securely. Which would you choose?
