HTML5 Security: Local Storage
In a previous article of mine, I discussed Cross Domain Messaging in HTML5. This article walks you through another feature, called local storage, and its security.
Local storage is one of the new features added in HTML5. It was first introduced in Mozilla 1.5 and eventually embraced by the HTML5 specification.
The data processed using the localStorage object persists through browser shutdowns, while data created using the sessionStorage object will be cleared after the current browsing session.
One important point to note is, this storage is origin-specific. This means that a site from a different origin cannot access the data stored in an application’s local database.
Let me make it clear with a simple example. Below is a sample HTML5 application, which is capable of storing data using the local storage feature. We can also retrieve the data stored in the database using the “Show Data” button.
Let us first observe the origin of this site.
Let us assume that this is “Application A”.
So here are the details:
Name: Application A
Let us click the Show Data button.
We are able to access the data stored by this application in the database. That is expected.
Now, let us try to access this data stored by application A from a different origin.
Let us assume that this is Application B
Here are the details:
Name: Application B
Please note that the port number is different from Application A.
Let us click the “Show Data” button.
When I clicked “Show Data”, there seems to be nothing displayed on the web page. This is because this application is running on a different origin.
Just to confirm, let us run a different application named “Application C” from the same origin as “Application A”.
Here are the details.
Name: Application C
Let us click “Show Data” and observe the result.
Nice! We are able to access the data from this application, since it is from the same origin as Application A.
To conclude, I have used the same code in all the above examples but with different origins. We inserted data into the database using Application A. When we tried accessing it from Application B, it failed due to the same origin policy.
Let us now see some attacks possible with HTML5 local storage.
Storing Sensitive Data
Developers may store sensitive information in these databases. It is possible to find API keys or similar sensitive data when working with APIs due to their statelessness. We can exploit them using an XSS vulnerability if there is no physical access to the device.
We can use the function setItem with some name-value pairs as parameters.
As we can see in the figure below, Chrome stores this data in the following path.
We can now go ahead and read this data from the SQLite database as shown below.
SQLite data, when not properly sanitized, may lead to script injection attacks. Let us see a simple example.
Below is the same form we saw in the beginning of the article.
Let us store some sample data and retrieve it back as shown below.
If this data is not properly sanitized, it will lead to stored XSS Vulnerability as shown below.
This time, let us enter the below piece of code into the message box.
<img src=’X’ onerror=alert(1);>
Let us click the “Show Data” button and see the result.
This article has discussed how the HTML5 local storage feature works and how Same Origin Policy restrictions are applied on the data being stored. Finally, we have had a look at some possible attacks on the HTML5 local storage feature. We will see other HTML5 features and possible attacks in later articles.
We've encountered a new and totally unexpected error.
Get instant boot camp pricing
A new tab for your requested boot camp pricing will open in 5 seconds. If it doesn't open, click here.