Difference between PHP Sessions and Cookies
For a long time, it was unclear to me the difference between a session and a cookie. Largely, because they seemed so intertwined and used for similar purposes.
Recently, I have been working on client project where we are introducing SAML based single sign-on but our codebase isn't what sets the cookie that needs to be destroyed upon logout. The cookie is created by the identity provider so it proved difficult to delete. The domain on which our codebase resides has the same root domain as the identity provider domain (so it wasn't a cross-domain issue) but I ended up having to explicitly define not only the path but the cookie domain as well when deleting the cookie.
Ultimately, the summarized difference between sessions and cookies are as follows (thank you to Gizmola at PHP Freaks for the detail):
Cookie: A key/value pair that is stored by the user's browser and is available in the superglobal $_COOKIE array available in PHP. The cookie request is initiated with an explicitly defined expiration date. For example:
setcookie('cookieName', $some_value, time()+3600, "/", ".example.com")On the next server request, $_COOKIE['cookieName'] will be available. If you use a browser tool to look at the cookie, it will have an expiration date.
Session Cookie: Identical to the above but defined without an expiration date. If you use the same browser tool it will say that the cookie expires at the end of the session; which is ultimately when you close your browser. For example:
setcookie('cookieName', $some_value); PHP Session: a server side mechanism that will associate a bunch of data with a session id. Every time a session is invoked, it serializes/unserializes it. This could be more data than just a single key/value pair that a cookie supports, but the way of associating this data with a user is by creating a cookie (regular or session as described above) in their browser that contains the session id. This way, the right data can be retrieved for a given user based on the value of that cookie.
Written by Tim Fernihough
Related protips
3 Responses
@kunalvarma05
It really depends on what you're doing. You'll never want to trust something from the browser just as-is. Anything stored in a browser (ie, a cookie) can be modified so that poses a potential problem.
With PHP Sessions, you generally have to create an identifier for that user (and store it in a cookie). Don't store a raw value in that cookie that is passed into a database query in order to retrieve data. A modification to the cookie would mean the identifier is lost but if someone gets a hold of your session id somehow, your session could be hijacked.
Summary
Use a cookie whenever possible with encrypted values.
If the situation allows it and the data you are storing is not critical, don't store it in plain text but rather encode the value using a decent encryption algorithm and then store it in a cookie. If the situation demands that you use a session with an identifier cookie but you're concerned about session hijacking - simply make sure that the IP address or something somewhat uniquely identifying is fed in as a parameter to the algorithm that generates the session ID.
@kunalvarma05
Happy to help - do you have a particular scenario that might be easier to work with? Perhaps we can use your example.
@kunalvarma05
Well with login I would recommend a cookie. There is no need to use a session and all well known frameworks and content management systems set a cookie. It's up to you to set a normal cookie or a session cookie depending on what your business logic requires (ie, so the user is logged out if they close the browser). Typically, even a non-session cookie has a lifetime somewhere on the order of a few months. If you want to accomplish a persistent login session similar to Facbeook where a user checks off a checkbox that says something like "keep me logged in", that is a hashed/salted cookie value that matches an entry in the database for a given user. This allows for a cookie that ultimately never dies until the user clears their cookies.
I saw your original post actually said credit card details. Under no circumstances should you be storing anything having to do with credit card details in a cookie. I assume you're building a front-end interface that interacts with a 3rd party credit card gateway. If you're simply trying to accomplish some form of recurring billing, look into their API. They likely have a token based system to accomplish this. Your site visitors will appreciate knowing that you take the security of their details seriously.
Hope this helps!
