Membership
Main Menu
Forum Boards
Stats
- 18 tutorials
- 72,339 members
- 696,896 forum posts
- 11 blog posts
Tutorials
Sessions and cookies: Adding state to a stateless protocol
Views: 21155
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.
- « Previous
- 1
- 2
- 3
- 4
