I’ve seen several web applications implementing the user session ID (or token) in a custom HTTP header parameters thus avoiding to store the session ID in cookies. Additionally, some public web platforms save the same kind of token to track their user analytics. For instance, recently I notice that this mechanism was utilised by the New Relic REST API platform which is storing the user ID in a HTTP parameter called X-NewRelic-ID.
During testing of an application, I have found both a cross-site scripting and the session ID sent as HTTP header parameter . My goal was to steal the user’s session ID, which was sent to the application as X-Auth-Token in a custom HTTP header parameter.
Curious to understand why people persist in the use of this implementation I start searching around for information. I start playing with the web console of my browser while logged into the application – I was looking for the “auth_token” of my account. If I could find the variable that store the authentication token than I could directly retrieve this value without using any Ajax weapon. Simple as that!
What Are the Security Concerns?
In the past 5 years, the security around cookies has improved. All modern browsers accepts the security flags that can be set on cookies by web applications. Security flags are two (categorised as security flags but cookies have more) and are very simple to understand and deploy.
Secure – Disallow the transmission of the cookie to be sent over an unencrypted communication channel as such HTTP.
More information of these security flags and their implementation can be found in the OWASP website:
One more note. Cookies have not only these two flags. The importance of appropriately configure the “domain” and “path” flags on cookies is as crucial as applying the aforementioned conservation flags. If your concern is limiting cookies only to be sent to specific pages or subdomains of the web application, then the answer is: configure “domain” and “path” flags accordingly to your requirements.
So…What is localStorage?
In my understanding is nothing else that what the variable name states, however developers may have different myths on the existence of localStorage.
The following text has been taken from smashmagazine.com (http://www.smashingmagazine.com/2010/10/11/local-storage-and-how-to-use-it/):
“The main problem with HTTP as the main transport layer of the Web is that it is stateless. This means that when you use an application and then close it, its state will be reset the next time you open it. If you close an application on your desktop and re-open it, its most recent state is restored.
This is why, as a developer, you need to store the state of your interface somewhere. Normally, this is done server-side, and you would check the user name to know which state to revert to. But what if you don’t want to force people to sign up?
This is where local storage comes in. You would keep a key on the user’s computer and read it out when the user returns.”
What this guy think cookies have been used in the last 15 years for? It gets better:
“Cookies have a few limitations though:
– They add to the load of every document accessed on the domain.
– They allow up to only 4 KB of data storage.
I haven’t finished – I want to add a text from w3schools.com (http://www.w3schools.com/html/html5_webstorage.asp):
“With HTML5, web pages can store data locally within the user’s browser.
Earlier, this was done with cookies. However, Web Storage is more secure and faster. The data is not included with every server request, but used ONLY when asked for. It is also possible to store large amounts of data, without affecting the website’s performance.
The data is stored in name/value pairs, and a web page can only access data stored by itself.
Unlike cookies, the storage limit is far larger (at least 5MB) and information is never transferred to the server.”
The above text is correct! But be careful how you interpret it. Bear in mind that they are not referring to session ID. The web storage (localStorage) is used here to contain user’s information but It doesn’t mention the use of session ID or the use of web storage to maintain the state of the user session. Contrary to what was stated in the previous article.
LocalStorage can be a great place for developers to store user information but not a secure place to store the user’s session ID (or token) or other sensitive information. LocalStorage has been preferred to Cookies, but for the only reason of storing large data or information that are not need to be sent at each request to the application.
Finally, localStorage is not the place where you should store the user’s session ID.