Archive for the IE Category

GoodScriptThe investors who are generously funding it, but want to stay anonymous for now, just authorized me to unveil a few details about the revolutionary project which I’ve been feverishly working on during the past months. What we’re talking about is not merely a next-generation NoScript. No, we’re talking about the ultimate security tool, nothing less, code named GoodScript.

GoodScript’s key feature is the ability to detect and block malicious JavaScript and other active content before it can harm your web browser, while all the “good” code is automatically allowed to run untouched.

“Nothing new”, you say, “my antivirus has claimed to do that for a long time”. Not quite. Your antivirus compares the code with a database of signatures, and whatever matches is flagged as malicious. What about new code, whose signature has not been added yet? “Heuristic detection” you say. But you must keep in mind that heuristic detection on dynamic languages like JavaScript, which may be heavily obfuscated and offer many ways to do the same thing, is very difficult: it almost surely require to interpret the script in advance inside a sandbox (which might itself be evaded or exploited), and is extremely slow, heavily hurting performance which is the holy grail of modern browsers.

Enters GoodScript. GoodScript does not hurt performance, because it doesn’t need the code to be interpreted. It doesn’t even need the code to be downloaded: actually, if GoodScript detects malice, the evil code is left on its server, far from your browser.

How does this wonder work? First, the bad news: GoodScript works on IE9 only. Why? Because IE9 is the fastest browser around, with everything hardware-accelerated. Hardware acceleration is crucial to GoodScript. Its secret sauce is “Relativistic Workers“, a special kind of Web Workers (HTML5 voodoo) which get hardware-accelerated by IE9. By using Relativistic Workers, GoodScript’s code can run at relativistic speed (near to the speed of light). Thanks to this breakthrough in code speed, we could implement GoodScript’s “PrecogEngine” component, which leverages relativistic effects to temporarily travel in the near future and watch the effects of the potentially malicious code before it could even been downloaded from the web. The great thing about this approach is that it’s not limited to traditional exploits causing immediate effects on your system, such as the attempt of writing on your filesystem or to install a keylogger, but it can detect more elusive signs of malicious intent, e.g. that some hours later your online bank account is gonna be annihilated by a wire transfer to Russia, after a successful XSS attack managed to steal your credentials.

A big thanks to Microsoft: without their commitment to making IE9 fully hardware-accelerated, our exclusive PrecogEngine (the only client-side technology capable of preventing Thought Exploit) wouldn’t have been possible: GoodScript would still be a naive dream and we would be stuck with whitelists, XSS filters and other boring stuff.

Let’s hope Google and Mozilla catch up soon with hardware acceleration, even though a Firefox version would also require working around incompatibilities with this new feature they just announced :(

Michael Coates just announced that X-Frame-Option will be finally available on Firefox starting with the next minor update, 3.6.9.

This is great news, because it puts vanilla Firefox on par with IE and Chrome regarding this server-side defense, which security-aware web authors (like the guys at Google, and possibly the AMO team now) can use, by modifying the way their pages are served, in order to protect their web sites against frame-based Clickjacking.

I said “vanilla”, because Firefox with NoScript has been supporting X-Frame-Options since the day after it had been announced with much fanfare by Microsoft, i.e. Jan the 29th 2009 (more than 1 year and half, now). Mostly as a point of pride, actually, than out of a true necessity, since the existent NoScript’s ClearClick module already provided a more complete and effective protection against all kinds of Clickjacking (either frame-based or plugin-based), independently from the good will and security awareness of server-side implementers.

It’s worth to mention that in many situations, like on web properties which provide some kinds of frame-based APIs, or support external apps and “widgets”, X-Frame-Options is hard or impossible to be configured properly, because it would break the business model of the site itself. Facebook is a glaring example of this kind of sites, vulnerable to Clickjacking, where X-Frame-Options would fall short. Needless to say, NoScript’s ClearClick does protect against Clickjacking everywhere, no matter if web site owners could not, or choose not, to implement X-Frame-Options (or just didn’t know about it!).

To be fair, there’s an upcoming Firefox 4 technology which can better help web developers protecting their web sites against this and other web application security issues, even in complex scenarios like Facebook’s: it is Content Security Policy (CSP). I’d really love it to get popular enough among security-aware developers, and possibly be standardized across browser implementations.

On the other hand, as long as you don’t trust every web site out there to always do the right thing security-wise, NoScript will be your friend :)

As you probably know, the details about the paradoxical behavior of the Internet Explorer XSS Filter, introducing XSS vulnerabilities of its own on otherwise immune web sites, which we hinted at some months ago, have been revealed by Edoardo “Sirdarckcat” Vela and David “thornmaker” Lindsay recently at the Black Hat Europe conference, in Barcelona (on a side note, looks like Sirdarckcat enjoyed his stay there so much that he decided to remotely hack a certain volcano…)

I’ve been quite disappointed by the preamble of their paper, which calls IE8’s XSS filter a new type of defense and a somewhat novel approach (before bashing it), when we all know that NoScript came first. Sirdarckcat personally apologized, blaming Lindsay for this and other “pro-big-players” bias, such as the decision of omitting, from the comparative table in their slides, Sirdarckcat’s opinion about NoScript’s being the safest among the in-browser filters and the hardest to bypass.

Notwithstanding, the technical core of this research is very worth reading, if you’re interested in XSS attack and defense techniques.

After the Black Hat debacle got echoes in the press, David Ross, the main XSS Filter engineer at Microsoft, published a Guidance on Internet Explorer XSS Filter document on the Microsoft Security Response Center website, announcing a not better specified “patch” coming in June (mmm, two whole months? need some help?) and making two interesting statements:

In the case of the Internet Explorer XSS Filter, researchers found scenarios that are generally applicable across XSS filtering technologies in all currently shipping browsers with this technology built-in.

This essentially means just two, IE8 and Chrome… but wait, Chrome doesn’t ship with its XSS Auditor enabled anymore because it was dog slow!
Hence the final recommendation by Ross…

Overall we maintain that it’s important to use a browser with an XSS Filter

… can really mean one thing only: Microsoft maintains that it’s important to use Firefox with NoScript :)

Update Jul 29 2010

This “feature”, eventually publicized by Sirdardckcat and Thornmaker, allowed Microsoft to win the BlackHat 2010 Pwnie award for the “Most Epic FAIL”:)


Internet Explorer 8’s famous XSS filter can be exploited to perform successful XSS attacks against web sites which would be otherwise safe. In other words, XSS “protection” is helping XSS attackers, oh the irony.

Well, this is not exactly news among security researchers, but those aware of the details (including Microsoft of course, Eduardo “Sirdarckcat” Vela and myself) have kept a low profile so far. Check, for instance, slide #17 in my OWASP presentation (alternate link), given two weeks ago.

However, after Microsoft left it unfixed for many months, someone apparently decided to whisper this dirty little secret in Dan Goodin (The Register)’s ear.

To Microsoft’s credit, this problem has no quick fix: in fact, it’s way worse than a simple implementation bug. Its root is a flawed design choice: when a potential XSS attack is detected, IE 8 modifies the response (the content of the target page) in order to neuter the malicious code. This is, incidentally, the only significant departure from NoScript’s approach, which modifies the request (the data sent by the client) instead, and is therefore immune.

Anyway, here’s the juice: IE 8’s response-changing mechanism can be easily exploited to turn a normally innocuous fragment of the victim page into a XSS injection. The attacker just needs a certain degree of control on the content of the web site to be injected: social networks, forums, wikis and even Google Apps are good prey. To be fair, Google Apps are not vulnerable anymore, since Google’s properties wisely choose to deploy the

X-XSS-Protection: 0

header, which is the “safety switch” disabling IE 8’s XSS protection.

So, web site owners’ dilemma is, opt out or not opt out?
For browser users, there should be no dilemma at all ;-)

When Microsoft unveiled its IE 8’s “XSS filters”, almost one year ago, we could notice how, despite their impressive resemblance to NoScript’s anti-XSS protection, they were quite limited in comparison.

One of the limitations was their ability to mitigate a subset of reflective (AKA type 1) XSS vulnerabilities only, leaving them totally useless against DOM-based (AKA type 0) XSS attacks which, instead, are effectively defeated by NoScript.

Today I noticed via sla.ckers.org that such a DOM-based XSS attack is currently possible against Paypal and Ebay, no less, allowing the attacker to steal authentication info and other sensitive data, or even perform financial transactions on the behalf of the victim.

Even more interesting, modern browsers* except IE properly encode request URLs before sending them on the wire, but exploitation of this specific Paypal vulnerability requires the “double quotes” character to pass through with no encoding: therefore, while the vast majority of XSS exploits are cross-browser, this one affects exclusively IE**. Embrace and XSStend?

  1. * Latest versions of Firefox, Safari, Opera and Chrome.
  2. ** Variants could affect any browser, since IE’s encoding bug is generally not required for DOM-based XSS. Firefox users can protect themselves by using NoScript, even in the permissive and not recommended “Allow Scripts Globally” mode.

Bad Behavior has blocked 7073 access attempts in the last 7 days.