Wednesday, January 16, 2008

Anti-XSS protection with NoScript

Cross-Site Scripting (XSS) vulnerabilities are usually programming errors made by web developers, which allow an attacker to inject his own malicious code from a certain site into a different site. They can be used, for instance, to steal your authentication credentials and, more in general, to impersonate you on the victim site (e.g. your online banking or your web mail).

This kind of vulnerability, often overlooked, is very widespread and becoming highly popular among hackers: someone even bothered to write a JavaScript-based bot, called Jikto, turning your browser into a zombie which relentlessly sends automated XSS attacks all around. Of course this tool has been built "for research purpose", but its code unfortunately appears to be leaked in the wild, so anybody can take advantage of it.

There's no real cure for this kind of attack unless you avoid using popular browsers such as Internet Explorer entirely and opt for Firefox Flock, Seamonkey and others mozilla-based browsers extended with an add-on called NoScript, developed by Giorgio Maone.

NoScript features unique Anti-XSS counter-measures, even against XSS Type 1 attacks targeted to whitelisted sites.

Whenever a non-trusted site tries to inject JavaScript code inside a trusted (whitelisted and JavaScript enabled) site, NoScript filters the malicious request neutralizing its dangerous load.

By default, its Anti-XSS protection filters all requests from untrusted origins to trusted destinations, considering trusted either "Allow"ed or "Temporary allow"ed sites. If you prefer "Temporarily allow"ed sites to be still considered as untrusted origins from the XSS point of view, you just need to set about:config noscript.xss.trustTemp preference to false.

NoScript's Anti-XSS filters have been deeply tested and proved their ability to defeat every known reflective XSS technique, but their power is a double-edged sword: sometime they may detect a weird looking but legitimate request as a "potential XSS attempt". This should almost never be a show stopper, since the filter most of the time doesn't prevent you from navigating the filtered page, but the aforementioned Unsafe reload command and the XSS Advanced Options are have been made easily accessible so you can work-around if you hit a false positive with side effects.

While Cross-Site Scripting (XSS) vulnerabilities need to be fixed by the web developers, users can finally do something to protect themselves: NoScript is the only effective defense available to "web-consumers", waiting for "web-providers" to clean up their mess.

See also the NoScript XSS FAQ, or read the excellent Cross Site Scripting Attacks: Xss Exploits and Defense book.

No comments: