Secure Programming Tips – Cookie Creation & Session Management
Cookie Creation and Session Management
Cookie Creation and Session Management
Due to the stateless nature of how HTTP works, it’s virtually impossible for a web server to differentiate one request from another. As developers, it is imperative for us to implement some sort of session management to identify one user’s request from that of another. Most modern programming languages and web servers have mechanisms in place that ease management of users’ sessions by creating Session IDs. These session IDs help identify unique user requests. However, session IDs are often an attack target where a malicious user might attempt to guess a valid session ID in an attempt to hijack a current user’s session. Another similar attack would consist of a malicious user attempting to predict a future session ID. If a future session ID could be predicted, the malicious user could send a request to the server containing the future session ID and attempt to hijack a user’s session after that session ID was assigned.
The strength of a session ID is directly related to its length and the number of unique characters used to create it. The more characters the session ID contains, generally the more secure it will be. Ideally, a session ID should be at least 128 bits of entropy, which equates to about 16 characters in length. ASP.NET session IDs are 120 bits, but they have the added value of being signed and encrypted which all but ensures their security. ASP.NET session IDs are similar to GUIDS (Globally Unique Identifiers) and are virtually guaranteed to never repeat. If you are not using a language that generates session IDs or it generates session IDs that aren’t of sufficient size and strength, it is imperative that you, the developer, implement secure session IDs that are safe from attack.
In the event the web server you are using doesn’t support sessions, then the implementation of cookies is the best way to handle session management. Cookies are basically just pieces of data that can be persistent (stored on the user’s machine) or non-persistent (only available while browser is open and session is active). Before using cookies, it’s important to understand how to use them in a secure manner. The rest of this article will focus on the following areas of cookie security.
· Persistent vs. Non-Persistent
· Clear Text/Encoding/Encryption
· Security Issues of Poor Implementation
First, let’s get an understanding of what a cookie actually is and why it is used. Cookies are nothing more than pieces of text that are transmitted from the web server to the user’s browser. Why are cookies used? Generally, cookies are used to determine the authentication or authorization rights of a user; they can be used to track which items a user has added to his shopping cart in an e-commerce website. They can also be used to track a user’s actions within an application to determine preferences. These preferences can then be used for targeted advertising.
What is the difference between a persistent and non-persistent cookie? A persistent cookie is data that is saved to a user’s machine. A common scenario when a persistent cookie would be created is when a user logs into an application and chooses to have their identity remembered, such as using the “remember me” functionality of a site during the login process. The persistent cookie contains information that identifies the user on subsequent visits to the site. The cookie may allow the user to bypass the login functionality and gain automatic access into the site itself. A non-persistent cookie is data that is only available while the user’s browser is still open and the session is active. If the user explicitly logs out of the application or closes their browser the non-persistent cookie is destroyed. None of the data associated with a non-persistent cookie is written to the user’s machine.
You should never store sensitive or personally identifiable information, such as social security numbers, account numbers, or passwords, in a persistent cookie. When making the determination on whether to encrypt or encode the data or leave it in plain text is up to developer preference. However, it is recommended to encrypt any cookie data that is used as a part of the applications logic, such as if a cookie value is used to hide or display a link on the page. In the examples below we’ll look at some common security issues that can arise when cookies are implemented incorrectly.