What is local storage?
Local Storage refers to a property that allows sites and applications to save key-value pairs e.g. {“theme”:“dark”} locally on your browser using JavaScript. This is so that the data can be retrieved by the website easily.
For example, when you set a preference for website A to use a dark theme, this is stored as a key-value pair on your browser, so the next time you visit website A, it remembers your preference and will use a dark theme.
This is because local storage is persistent, which means that it will never expire. As long as the browser cache is not manually cleared by the user, these key-value pairs persist even when the browser is shut down and/or restarted.
The catch is that it is only retrievable by the same website.
On the other hand, the Hypertext Transfer Protocol, or more commonly known as HTTP, is a stateless protocol, i.e. the server does not keep track of the state of the client.
Let’s look at the website (https://set-localstorage.herokuapp.com/) to illustrate the usage of local storage via HTTP.
Imagine a scenario where a student logs in to their academic portal via HTTP and has to update their particulars such as their name and NRIC.
Although the data is submitted to the server, the developer designed the website to display the information on the main page.
As HTTP is a stateless protocol, this means that every time the student goes to the main page, the website has to resend the request to retrieve the particulars of the user. To simplify this process and make it more convenient for end-users, the developer can make it such that the information is retrieved from the browser’s local storage rather than retrieving it again from the server.
Clearing local storage
As seen in the screenshot below, the “name” and “NRIC” of the user were stored in the user’s browser.
Although it is possible to implement functions to clear the local storage when the user logs out or when the validity of the session timeouts, there are cases where websites do not clear the information at all.
Local storage is persistent
Local storage remains persistent even after closing and reopening the browser. The information stored on the local storage will remain available on the user’s browser.
This usually does not present a security concern if the student was using his own PC to access and fill in the form. However, if he was accessing the site and filling up the form from a public terminal, such as one in the library, the next user using the same browser would be able to access and see his name and NRIC in the browser’s local storage.
Besides being openly accessible to anyone who next uses the same browser, there are other ways where local storage can be misused. Below are two examples.
Cross-site scripting (XSS)
As local storage was never intended to be secure, there is no data protection and any JavaScript on the website can access it. Hackers can exploit the existing XSS vulnerability on the website like the following screenshot when the user browses to https://set-localstorage.herokuapp.com/xss-injected-page.html.
In an actual hacking situation, the user will not even notice the sensitive information was already captured by the hacker. The information would be sent to the hacker’s server instead via XSS.
JavaScript libraries
Most of the time, websites use JavaScript libraries to function. It is like the bread-and-butter for developers. It is possible but rare to not use JavaScript when developing a website.
The first threat to consider is if the website uses JavaScript hosted on external sources like CDNs, they could potentially be breached, and a malicious JavaScript could instead be executed on the website. This could be prevented by using Subresource Integrity (SRI) hash to verify that the resources fetched were not changed. However, not all JavaScripts used could be hashed as SRI hashes are intended for static content, and for example, Google Map JavaScript could not have an SRI digest as Google would dynamically change their content over time.
The second threat is that the hacker could find and exploit an unknown XSS vulnerability in the third-party libraries imported to the server used by the website. Yes, zero-day vulnerabilities on JavaScript should be considered as well. There was an XSS worm that was known to propagate across Myspace called Samy Worm (https://samy.pl/myspace/tech.html) and the creator also did an exploit of how it was possible to still retrieve data from a cleared local storage in Evercookie (https://samy.pl/evercookie/).
How to prevent the misuse of local storage
Given the potential vectors where malicious actors can access information on your browser's local storage, it is easy to see why sensitive information such as Personally Identifiable Information (PII), authentication tokens, user locations and API keys, etc., should never be stored in the local storage.
Conclusion
Local storage should only be used to store non-sensitive data like users’ preferences such as themes, language, etc.
The following are several ways where an attacker could retrieve the sensitive information stored in the local storage:
- Physical access to the browser
- XSS
- Cross Domain Script Included
- JavaScript Known Vulnerabilities
- Zero-day
Therefore, to prevent local storage attacks, websites should follow best practices and only store sensitive data on the server-side.
