HTML5 is the newest version of the HTML. It offers new features that enhance support for creating web applications that can interact with the user and his/her local data and servers. HTML5 successfully does this more easily and effectively than has previously been possible.
In this article we will focus on the new client storage offered by HTML5. The new HTML provides us with the Local & Session Storage, which can hold 15MB and more of client data. The differences between them is that the Local Storage can be accessed from any window, while the Session Storage can by read/modified by the same window only. Additionally, the data within the Session Storage will be automatically deleted when the window is closed, whilst deletion of the data in the Local Storage must be done manually.
Let’s say that the web application stores your account number, the SessionId, username, and some other data that will be read later on in order to display the data without sending requests to the server. The website takes the data it previously entered to the storage and displays it when the page renders. This is how the page looks normally, along with the original information stored in the sessionStorage:
Notice that the message within the speech bubble takes its information from the Session Storage, as can be seen in the above image, right below the page. You can access the page’s Resources tab using Chrome’s Developer tools (a.k.a Inspect Element).
We can assume that the page’s code behind it looks something like this when retrieving the data from the Session Storage:
var username = window.sessionStorage.getItem(“username”);
var speech = window.sessionStorage.getItem(“Speech-of-the-day”);
var action = window.sessionStorage.getItem(“Random-action”);
If this website is vulnerable to a Reflected XSS (which in the regular case would be executed once on the response that includes it) and if the website does not perform client-side encoding (escaping), then this Reflected XSS can become a Stored XSS.
window.sesssionStorage.setItem(“Speach-of-the-day”, “<script>alert(‘Resident XSS…’)</script>”);
Let’s go back to the example.
The attacker managed to implement a malicious code inside our sessionStorage using regular XSS. Now it will look like this:
Notice that the value of the Speech-of-the-day key has been changed, and it now contains a malicious script (a simple alert for the PoC). The next time the page refreshes (and every time after that until the window is closed or the data is modified), the XSS will be executed:
One of the major purposes of HTM5 is to bring power to the client-side. Therefore, in order to prevent those new vulnerabilities that are introduced by HTML5, we need to make a remediation on the client-side. Thus, to prevent XSS in the client-side we should perform the same mitigation that we would implement on the server. But before we read content from the client storage we escape it! We do this so when it is called, even if someone planted a malicious script, it won’t be executed (just as any XSS):
With all the new powerful features HTML5 has brought to us, many new security issues have also been introduced. An important amount of them involve data stored in the client, or taken from it. As we already know, the client should never be trusted and all the data in it, no matter if we stored it ourselves or not, should be mitigated. We should take all precautions possible when dealing with it.