Resident XSS (Rootkits in your Web application)

The new HTML5 was brought the internet community with a whole bunch of new features, to help us create a more dynamic and smooth client side, whether for the mobile apps or to a browser based client. Among its new feature you can find: CSS3, Drag&Drop, localStorage & sessionStorage, Streaming, Geolocation, Webworks and whatnot.

Wait! (imagine you hear the rewind sound): local & session Storage? does that mean that I can store data on the client? -Yes!
Well, it sounds like a great feature isn’t it? they all are… but are they safe? – A big fat No!

But lets concentrate in the session & local storage, shall we? What if someone store things for me? evil things… it means that my own browser will betray me and hold malicious data that could harm me! how does that work?

Lets say that the  site you are using stores some of your account details into your local & session storage, so later on it could read information from your client, sparing it to send requests to the server.

In this scenario, our website stores your account#, the SessionId, your username and some other string that will be displayed on the screen when you enter the website (sounds like… exactly!).

Our 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:

residentXSS_before(Click on the image to enlarge)


Notice that the message withing 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 code behind it looks something like this:

var username = window.sessionStorage.getItem(“User”);
var speech = window.sessionStorage.getItem(“Speach-of-the-day”);
var action = window.sessionStorage.getItem(“Random-action”);

and calling them using:

<h1> <script>document.write(“Hello ” + username); </script> </h1>
<h3> <script>document.write(speech);</script> </h3>
<a href=”#”> <script>document.write(action);</script> </a>

Now, what if this website is vulnerable to a Reflected XSS? in that case the XSS would be active once, on the response that includes it. But what if! this website uses the client side storage to display information?

— If the attacker injected some malicious content to our sessionStorage and the website does not perform client-side encoding/ escaping (wait… client-side? yes!) then the XSS would take residence (thus, the name) inside our browser, just waiting to be called by the client.

Its also very simple to do so, all the attacker needs to know is the name of the key within the storage and then change it simply using: sessionStorage.setItem(key);

So, let go back to the example. The attacker managed to implement a code inside our sessionStorage using regular XSS. Then it will look like this:

residentXSS_after(Click on the image to enlarge)


Notice that the Speech-of-the-day key has changed, and it now contains a script. The next time (and everytime after that) the page refreshes, the XSS will be executed:

residentXSS_alert(Click on the image to enlarge)


What can we do about it? — as I mentioned earlier, before reading content from the client-storage escape it! so when called, even if someone planted a malicious script – it won’t be executed:

residentXSS_escaping(Click on the image to enlarge)


With all the cool features HTML5 has brought to us, a lot of new security issues has been introduced. An important part of them involve data stored in the client, or taken from it. Since the client should never be trusted, all the data in it, no matter if we stored it or not –  should be mitigated, and we should take any precautions possible when dealing with it.


One Response to “Resident XSS (Rootkits in your Web application)”

  1. It’s nearly impossible to find experienced people about this subject,
    but you sound like you know what you’re talking
    about! Thanks

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: