Tutorials

Sessions and cookies: Adding state to a stateless protocol

by Daniel Egeberg on Jun 5, 2008 6:45:45 AM

Security issues

Because the cookies are transferred unencrypted (unless you are using SSL) and because they will be stored in plaintext on the client computer, it is not advised that you store any sensitive information in the cookies. Such information could, for instance, be the username and/or password. For purposes such as authentication it would be best to store a unique identifier in a cookie and store the rest of the information on the server. In that way it never leaves the server and therefore it is stored in a safe manner (providing your server is secure). Seeing as sessions do this, they would be a better choice for that purpose.

An instance where you would not want to use sessions instead of cookies would be if you need Javascript or another client-side scripting language to access the information. Seeing as session data is stored on the server, there is no way whatsoever it can be access from the client machine. Again, this information should not be sensitive.

A problem related to this is a security issue known as XSS (Cross Site Scripting). This vulnerability exists if users are able to post information (via a form or the URL for instance) and that information is redisplayed on a page without being properly escaped. In that way a malicious user will be able to execute any arbitrary Javascript code on the client machine without the user or you knowing it. The reason why this is a problem regarding cookie and session security is that cookies will be default be able to be viewed by Javascript. There are a number of different ways you could deal with this. The first and most obvious one is to properly escape all output coming from a user. The function htmlentities() can take care of that. Another way is by setting the httponly parameter for your cookies. In that way the browser will not give Javascript access to the information that cookie holds. If you are using sessions, then you can call session_regenerate_id() on every request. By doing that the user will get a new session ID each time and it means that if a malicious user ever gets a session id, chances are it will be invalid by the time he gets to try it because it changes often. You can use any combination of these three things (although you should always do the first). Stealing the session IDs and attempting to use them is known as session fixation. There are plenty of resources available regarding both XSS and session fixation available if you want further information regarding those two subjects.

Conclusion

That's all I have to say about cookies and sessions right now. With this new information you will be able to remember things about your users.

Comments

Thanks, this tutorial helped me out.

1. GreenUser on Aug 15, 2008 3:24:45 PM

Good tutorial, it helped me out as well. :)

2. BuzzardB on Oct 2, 2008 5:47:49 PM

i want to store cookie value in database and fetch that value and save it as session so whenever i delete cookies of browser i should retrive same state before deleting cookies
i am doing for portal of extjs and want this code in php

3. rohan354 on Oct 10, 2008 5:54:14 AM
Login or register to post a comment.