xdljzq
Last Updated: February 25, 2016
·
13.07K
· timfernihough
Tim january

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.

Say Thanks
Respond

7 Responses
Add your response

2061
Pro pic

@tim, which one is the better from security perspective?

over 1 year ago ·
2127
Tim january

@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.

over 1 year ago ·
2132
Pro pic

@timfernihough Hmm, the Summary does prove out to be knowledgeable. Any alternative/s as to the Session thing without encrypting and storing it in cookies? Does regenerate session id make any difference?
Any Example you'd like to give?
P.S. Appreciate your way of explaining :)

over 1 year ago ·
2133
Tim january

@kunalvarma05
Happy to help - do you have a particular scenario that might be easier to work with? Perhaps we can use your example.

over 1 year ago ·
2135
Pro pic

For instance, a website's login system...

over 1 year ago ·
2183
Tim january

@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!

over 1 year ago ·
2200
Pro pic

Actually I am not building a Billing System, just wanted to get better knowledge on it. Because I don't really have any experience with the billing systems. Anyway, I was looking into making a useful CLASS in PHP for the Log in and User Authentication system. But, I always lack that Security thing(I never really got clear with which one is better: Session or Cookie, until now), which was my actual concern when I first read your pro-tip. What your solution says, is that setting an Encrypted value for each user related to his/her cookie in the Database, and authenticate with it when he/she signs in. In this case I'd actually use a Normal Cookie because, I need to build a 'Remember me' thing, which would let me set a custom expiration date.

This was a real help, I actually gained some Pro-Knowledge.
Thanks :)

over 1 year ago ·