Cleaning up a website after a cross-site scripting attack may no longer be enough to protect its users

Websites that accidentally distribute rogue code could find it harder to undo the damage if attackers exploit widespread browser support for HTML5 local storage and an increasing tendency for heavy users of Web apps never to close their browser.

If browsers don't provide a mechanism for websites to securely recover from certain XSS (cross-site scripting) attacks, the attacks could become invincible and the site at the origin of the attack remain compromised indefinitely, warned vulnerability researcher and Google security engineer Michal Zalewski in a blog posting on Saturday.

[ The Web browser is your portal to the world -- as well as the conduit that lets in many security threats. InfoWorld's expert contributors show you how to secure your Web browsers in this "Web Browser Security Deep Dive" PDF guide. ]

The scope of client-side programming languages like JavaScript within browsers is limited by a critical security concept known as the same-origin policy. This prevents scripts running on certain Web pages from interfering with websites opened in separate tabs or windows.

In the case of XSS, attackers manage to insert rogue JavaScript code in targeted pages, where it is then executed in the context of their origin, defined by the domain, the protocol and the port number.

JavaScript is very powerful and is used in most types of Web-based attacks. Despite this, browsers don't currently provide a mechanism that can be used to invalidate such code, something that would provide compromised websites with a way to request a clean slate once they had resolved the problem.

A normal response to XSS attacks is to patch the vulnerability, invalidate session cookies so that everyone is forced to re-authenticate, and optionally force a password change. But this is not enough, because, according to Zalewski, once compromised a Web origin can stay tainted indefinitely.

"At the very minimum, the attacker is in full control for as long as the user keeps the once-affected website open in any browser window; with the advent of portable computers, it is not uncommon for users to keep a single commonly used website open for weeks," he said. "During that period, there is nothing the legitimate owner of the site can do -- and in fact, there is no robust way to gauge if the infection is still going on."

In essence, there is no way for websites to ensure that their users are no longer affected by an XSS attack. Still, one would be inclined to think that such an attack would stop at some point without the website's intervention, such as when closing the tab or the browser, but as it turns out, that's not necessarily the case.

There are several methods that attackers can use to extend their hold on a compromised origin pretty much indefinitely, according to Zalewski.

One such scenario would involve inserting rogue JavaScript code into a popular Webmail service or social networking site. This code could run in the background with the ability to obtain window handles for every new tab opened as a result of clicking on a link from the compromised page. If the newly opened pages had the same origin as the original page, or loaded a piece of code from the same domain, the rogue code could copy itself over to them and the process could begin again.

If Facebook were targeted by such an exploit, then given the way users constantly open new pages from the site, or external websites carrying Facebook "Like" buttons, the compromise could go on for as long as one of those pages remains open.

Shutting down the browser should in theory end any such attack. However, there are now ways of overcoming this too, using technologies such as HTML5 local storage or Web Workers, a special API for running JavaScript code in the background.

The problem with prolonged origin compromises is that they can bypass other security precautions as well. For example, if someone connects to an unsafe wireless access point, their browser can be tricked into thinking it has visited, say, Facebook.com through a combination of DNS poisoning and invisible frames containing rogue code, all without the user being aware. Later, that rogue code can hijack a real Facebook session when the user is logged in from a safe environment.

Such attacks can also lead to multiple account compromises if the affected computers are used by different individuals. They are not yet common because there are other, simpler techniques that hackers use, including exploiting remote code execution vulnerabilities. However, as exploit mitigation technologies advance, that could change.

"Today, it's so easy to phish users or exploit real RCE [remote code execution] bugs that backdooring Web origins is not worth the effort. But in a not-too-distant future, that balance may shift," warned Zalewski, who wants browser vendors to act now to make sure that point is never reached.