Archive for the IE Category

Thanks to IE8’s touted Clickjacking protection which will work on those pages whose authors decide to adopt the new proprietary X-FRAME-OPTIONS header (now cross-browser), the buzz about this topic has been raising again. Unluckily, Clickjacking (or more precisely, talking about IE8’s mitigations, “frame-based UI Redressing”) is not well understood enough yet for the “technical” press to spare us some frankly embarrassing articles:

And so on…
Even Heise Security fell in this trap, sigh. The mood of most of these “reports” is, more or less,

Look ma, there’s this Clickjacking PoC which works in Chrome and Firefox, but is defeated in IE8, which has Clickjacking ProtectionTM. Did you see? IE is the most secure browser of the pack, OMGROTFLMAO!!!

Now, I know the ones to really blame and bash here are this so called “security firm” looking for (and finding) free advertisement by exploiting the security buzzword of the day, and the “security researcher” Aditya K. Sood. But why did nobody of these journalists and bloggers try to verify Secniche’s claims (and orthography)?

Clickjacking is a malicious software form that can seemingly take control of the links that an Internet browser displays for various Web pages. Once that takes place, and once a user tries to lick (sic!) on that link, the user is taken to a site that is unintended. In some cases, the user may be able to recognize this immediately; in other cases, the user may be totally unaware of what took place.Once an infected ad has been loaded into your browser, your clipboard (where you copy and paste text) becomes overwritten with a URL.

A vulnerability across a variety of browsers and platforms, a clickjacking takes the form of embedded code or script that can execute without the user’s knowledge, such as clicking on a button that appears to perform another functionThe exploit may also take over your browser and visit links without you knowing.

A clickjacked page tricks a user into performing undesired actions by clicking on a concealed link. On a clickjacked page, the attackers show a set of dummy buttons, then load another page over it in a transparent layer. The user thinks he is clicking the visible buttons, while he/she is actually performing actions on the hidden page.

The hidden page may be an authentic page, and therefore the attackers can trick users into performing actions which the users never intended to do and there is no way of tracing such actions later, as the user was genuinely authenticated on the other page.

Well, by these standards (and grammar and syntax), hereby I disclose my sensational “Clickjacking PoC” which works everywhere, even against IE8 RC1:

Clickjack The Target ( : (

Even better, mine is just 188 characters long, i.e. 1/3 of the one by Secniche:

<a href=""
onclick="location='';return false"
>Clickjack The Target ( : (</a>

Unfortunately, like I told Heise guys (who honestly rectified their article):

that’s not Clickjacking by any stretch of imagination, and hardly malicious: you just get on a “surprise” destination, but nothing more since it can’t do any of the cross-site evils (e.g. bypassing CSRF protection) of the real thing.

Or, quoting Michał Zalewski’s answer to Mr. Sood on BugTraq:

1) It is by now well-understood that because of the inherent and broadly depended on properties of HTML, every sufficiently featured browser is and likely will remain susceptible to the behavior known as clickjacking. A more thorough analysis, also covering Chrome, is provided here:

2) To my best knowledge, the proof of concept provided in your post, where a same-origin <div> follows a mouse pointer, is not a valid demonstration of the issue at hand.

Nor is mine, of course: LickJacking, maybe ;)

Talking about rectifications, Security Watch’s apology of Microsoft’s take on Clickjacking protection, while defending X-FRAME-OPTIONS against the general skepticism from security experts, emphatically warned twice that “NoScript won’t protect you”. Larry Seltzer’s premise, “JavaScript is not required for the attack” was obviously correct, but unfortunately for him (and fortunately for Firefox users), NoScript doesn’t rely on script blocking to defeat the attack. He had apparently never heard about ClearClick, the specific anti-Clickjacking protection provided by NoScript, which is extremely effective even if JavaScript is enabled (or the attack is scriptless). Ironically, ClearClick is also the only available implementation of Michał Zalewski’s “favorite solution”, which his article even tries to explain.

However, as soon as I managed to tell him about his mistake (after working around the unbelievable suckiness of PCMag’s spam filters, which coughed on any sentence of medium complexity and even on the word “google”), Larry demonstrated solid deontology. He honestly admitted to have been misled by an ancient post by RSnake, which actually reported that older NoScript versions could be circumvented by some Clickjacking setups, while more recent (ClearClick enabled) versions are effectively protected. Larry, I did appreciate that, and I’m sorry I couldn’t post not even a simple “thanks” as a comment on your Security Watch blog (danx? th3nx? 10x?)

As I promised in my previous posts about so called IE8’s “Clickjacking protection”, some hours ago I released the NoScript development build, featuring experimental but complete compatibility with the X-FRAME-OPTIONS header support introduced by IE8 and unveiled yesterday by Eric Lawrence on the IE Blog.

As I said previously,

this is just a cross-browser compatibility effort: neither Firefox nor NoScript really need this feature. Traditional JavaScript-based frame busting works fine in Firefox, giving it the same degree of (modest) “protection” as IE8. NoScript users, on the other hand, are already fully protected, because ClearClick is the one and only countermeasure which works against any type of Clickjacking (frame or embed based), no matter if web sites cooperate or not.

However I also said this is nice to have. I had already imagined a functionally similar declarative solution, the SUB pseudo-method of ABE rules, and HTTP-based restrictions can actually be easier to deploy in some scenarios (e.g. using a Web Application Firewall).

More important, not every IT manager will have a chance of reading the reasons I exposed so far, explaining why IE8 has no more “Clickjacking protection” than its competitors. Our typical decision maker will just read a bullet list including “Clickjacking protection”, will find that no other browser dares such a claim and will base his choice (also) on that misleading comparison.

So let’s add this bullet, even if it does nothing against Clickjacking that “alternative browsers” couldn’t already do with traditional frame busting.

The following screenshot shows the original IE8 implementation as can be tested on my demo page:

X-IFRAME-OPTIONS demo in IE8 screenshot

And this is X-IFRAME-OPTIONS in action on Firefox (kindly provided by NoScript for now, but already in the works as a built-in):

X-IFRAME-OPTIONS demo in Firefox screenshot

But now that we’ve got “bullet parity”, let’s put the marketspeak aside and keep enjoying the only Clickjacking protection that really works “out of the box”: your friendly neighborhood ClearClick :)

Yesterday I published a blind analysis of the so called “Clickjacking protection” included in IE8 RC1. “Blind” because, hype aside, there was no technical documentation available, even if the feature was targeted to web developers who — in order to protect their users — should modify the way their pages are served.

After a while, Microsoft’s David Ross sent me an email confirming that my wild guesses about IE8’s approach, its scope and its limitations were indeed correct. The only information obviously missing from my “prophetic” description was the real name of the “X-I-Do-Not-Want-To-Be-Framed-Across-Domains” HTTP header to be sent before the sensible pages, and today this little mystery has been finally unveiled by Eric Lawrence on the IE Blog:

Web developers can send a HTTP response header named X-FRAME-OPTIONS with HTML pages to restrict how the page may be framed. If the X-FRAME-OPTIONS value contains the token DENY, IE8 will prevent the page from rendering if it will be contained within a frame. If the value contains the token SAMEORIGIN, IE will block rendering only if the origin of the top level-browsing-context is different than the origin of the content containing the X-FRAME-OPTIONS directive. For instance, if contains a DENY directive, that page will not render in a subframe, no matter where the parent frame is located. In contrast, if the X-FRAME-OPTIONS directive contains the SAMEORIGIN token, the page may be framed by any page from the exact origin.

As I had anticipated, IE8’s “clickjacking protection” is just an alternate scriptless way to perform frame busting, a well known and simple technique to prevent a page from being “framed” in another page and therefore becoming an easy UI Redressing target. Microsoft had to follow its own special path because the traditional JavaScript implementation can be easily circumvented on IE, e.g. by loading the targeted page inside an <IFRAME SECURITY=restricted> element. But the other major browsers are equally “protected” (if we can call “browser protection” something relying on the good will and education of web authors) by “standard” frame busting. Therefore, slogans like “the first browser to counter this type of threat” (James Pratt, Microsoft senior product manager) were marketspeak at its best. Furthermore, this approach is useless against Clickjacking in its original “historical” meaning, i.e. those attacks involving Flash applets and other kinds of plugin embeddings which led Robert “RSnake” Hansen and Jeremiah Grossman to invent the successful buzzword.

However in my post I had also written that having such a scriptless alternative as a cross-browser option would be nice:

I do believe that a declarative approach to control subdocument requests is an excellent idea: otherwise I wouldn’t have included the SUB pseudo-method in ABE Rules Specification (pdf). Moreover, as soon as I’ve got some less blurry info (David Ross, I know you’re listening, why don’t you drop me a line?), I’ll be happy to immediately implement a compatible feature in NoScript and lobby Mozilla for inclusion in Firefox 3.1.

David kindly answered

I think this would be fantastic and it’s a great place to start building some bridges.

I agree, in facts I’ve filed an enhancement request for Firefox, and I’m already working to release a NoScript development build featuring X-FRAME-OPTIONS support: that’s relatively easy, since I can hook in the work I’m already doing for the ABE module. (Update 2009-29-01: I just released NoScript development build, featuring full experimental X-FRAME-OPTIONS compatibility support).
It’s worth noticing, though, that this is just a cross-browser compatibility effort: neither Firefox nor NoScript really need this feature. Traditional JavaScript-based frame busting works fine in Firefox, giving it the same degree of (modest) “protection” as IE8. NoScript users, on the other hand, are already fully protected, because ClearClick is the one and only countermeasure which works against any type of Clickjacking (frame or embed based), no matter if web sites cooperate or not.

Speaking of NoScript, I’ve got a small but important correction to the otherwise excellent article Robert McMillan wrote for PC World (IDG News) yesterday:

Because clickjacking requires scripting, the attack doesn’t work when NoScript is enabled.

This statement is wrong twice:

  1. Clickjacking does not require scripting: JavaScript might make the attacker’s life easier, but it’s not indispensable to throw an attack.
  2. NoScript does not need scripting to be disabled in order to protect its users against Clickjacking: its exclusive ClearClick anti-Clickjacking technology works independently from script blocking.

That’s why NoScript can be recommended to anyone, even to grandma who’s not inclined to block JavaScript: albeit I do not encourage using NoScript’s “Allow Scripts Globally” command because the default deny policy is your best first-line defense, many additional protection features such as Anti-XSS filters and ClearClick still remain active even when JavaScript is enabled, providing the safest web experience available in any browser.

Microsoft released Internet Explorer 8 RC1 yesterday with the usual big fanfare, and one of its main marketing punchlines is its “exclusive” clickjacking protection:

Microsoft Adds Clickjacking Protection to IE8 RC1

One major security update to block Web attacks known as “clickjacking” that the company said makes IE8 the only Web browser to offer such protection.
The security feature that thwarts clickjacking in IE8 RC1 allows Web-site content owners to put a tag in a page header that will help detect and prevent clickjacking. If a site that uses the IE8 tag detects clickjacking, it will give Web users an error screen letting them know that the content host has chosen not to allow that content, and gives them the option to open the content in a new window that is protected from the attack.
(PC World)

Microsoft IE8 Hits RC1 Milestone, Stops Clickjacking

RC1 also includes protection against “Clickjacking,” a ploy to get users to click on account buttons while covering the actual site being clicked on using a frame – the first browser available to counter this type of threat, Pratt said.
(PC Magazine)

Microsoft Goes After Clickjacking in IE8

While offering few technical details of its methods for stopping clickjacking, Microsoft appears to have not only tried to address the browser-based issues, but also sought out the help of Web site owners to make IE8 less vulnerable to the attacks.
Now, it will remain to be seen whether or not the features offered in the IE8 RC browser have an effect in preventing clickjacking attacks, but you have to give the guys in Redmond credit.
(Security Watch)

Hype aside, forgiving Microsoft’s habit of forgetting precursors of their “first and unique” technologies, what can we infer from the “few technical details”?

At this moment, Tue Jan 27 2009 15:20:49 GMT+0100, searching for Clickjacking on the Microsoft Developer Network I can find just 1 result, i.e. the Internet Explorer 8 Release Candidate Now Available IEBlog’s post, and it doesn’t give away any more juice:

We’ve worked closely with people in the security community to enable consumer-ready clickjacking protection. Sites can now protect themselves and their users from clickjacking attacks “out of the box,” without impacting compatibility or requiring browser add-ons.

Putting all these pieces together, IE8’s clickjacking countermeasure seems to be a “tag” (or a HTTP header, or both) which “web content owners” must attach to the page(s) of theirs to be protected.
So it’s not about users protecting themselves: “Sites can now protect themselves and their users”.
Ooops, we knew sites could already “protect themselves and their users” last week, last year or even one decade ago, and in a more or less browser-independent way too. That’s called frame busting, and it’s done with a simple JavaScript one-liner. Therefore my guess, documentation pending, is that IE8 “invented” scriptless frame busting. All the browser vendors have been discussing something like this even before the Clickjacking bubble, and it’s actually useful because:

  1. JavaScript-based frame busting is not always reliable, especially on IE (it works fine in Firefox 3, though).
  2. JavaScript-based frame busting does not work, quite obviously, if JavaScript is disabled for whatever reason, unless you’re using NoScript.
  3. JavaScript-based frame busting can be easily circumvented on IE by loading the targeted page inside an <IFRAME SECURITY=restricted> element. Ironically, yet another Microsoft non-standard extension to HTML, with security purposes this time, makes IE the only contemporary browser where “standard” frame busting is useless by design.

To sum up, there’s always been a well known and accepted server-side protection option which works everywhere except in IE. As far as we know, the newly proposed anti-Clickjacking tag or header (much like the “X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes” suggested as fix #1 in Michal Zalewski’s famous “UI Redressing” post and to ABE’s SUBdocument rules) offers an alternate option which, currently, works only in IE8 RC1. Funny how Microsoft can turn a weakness unique to their browser in yet another non-standardized feature to embrace and extend HTTP overnight! :)
But if a web site owner is skilled and careful enough to implement our brand new header (which again, while I’m writing these lines, is apparently undocumented), he will surely deploy the simple and understood JavaScript frame busting one-liner too, and every browser is equally protected.

Furthermore, the press choose the “Clickjacking” buzzword over the proper “UI Redressing” definition, probably to amplify its hype effect. But historically, the term “Clickjacking” has been invented to designate a Flash-based (or more in general embedding-based), not necessarily cross-domain attack. Does this “anti-Clickjacking” feature actually work against the “original” Clickjacking concept? Nothing suggests it does yet, but we’ll see… 2009-01-28 Update: now we for sure know IE8 RC1 offers no protection against plugin-based Clickjacking, as expected.

However, I do believe that a declarative approach to control subdocument requests is an excellent idea: otherwise I wouldn’t have included the SUB pseudo-method in ABE Rules Specification (pdf). Moreover, as soon as I’ve got some less blurry info (David Ross, I know you’re listening, why don’t you drop me a line?), I’ll be happy to immediately implement a compatible feature in NoScript and lobby Mozilla for inclusion in Firefox 3.1.

That said, the bad news for IE enthusiasts is that they’ve got no magic “out of the box” protection, despite the press releases I quoted. True, it doesn’t require any “browser add-on” (don’t you love how they managed again to avoid mentioning NoScript?), but it comes with an even more strict requirement: all the sites to be protected must already have adopted a new proprietary hack, i.e. something no end-user can verify, let alone enforce (so long for the “consumer-ready” label).
We’ve been preaching about XSS holes and other web programming errors for years, but developers still fall in the same pitfalls over and over again: if the guys in Redmond really believed that web security could be fixed server-side by just educating web authors, why did they eventually bother adopting those client-side anti-XSS filters which NoScript pioneered?

On the other hand, ClearClick protects you against any type of Clickjacking automatically, as soon as you install the NoScript add-on, with no need for web authors to learn and cooperate. ClearClick keeps working even if you allow JavaScript globally and/or disable all the other NoScript protection features, so you’ve got no excuse to dismiss it. Any reason yet not to switch to safer browsing?


Microsoft’s David Ross sent me an email confirming that my “preemptive” analysis about IE8’s approach, intents and limitations was correct. A blog post by Eric Lawrence is on its way, explaining the technical details as an an “authoritative” source, but I guess the only information still missing is the real name of the header :)
About my stated intention of implementing a compatible feature in NoScript and lobbying Mozilla to do the same, he wrote

I think this would be fantastic and it’s a great place to start building some bridges.

I think so too.

Update 2 (2009-01-28)

Mistery unveiled: the header is “X-FRAME-OPTIONS: DENY” (I still prefer “X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes”, but whatever). Now that I’ve got “less blurry details”, NoScript’s compatibility feature is on its way, and I hope Firefox’s is too.

Yesterday and today we’ve got a blizzard of web browser security updates:

Microsoft zealots are taking this as an argument to argue that all browsers are equally insecure, and therefore there’s no reason to switch (from IE) for security purposes (an advice which, on the other hand, starts spreading even on mainstream media).
This is quite a debatable statement, if you think about it.
IE’s vulnerability, being a zero day, is actively exploited in the wild by thousands of compromised web sites and puts several millions of users worldwide at risk, while both Firefox’s and Opera’s are still embargoed.
Firefox will be automatically updated for its users before bad guys can analyze and exploit the patched vulnerabilities. That’s effective patching. Opera is in a slightly worse shape, since its update mechanism is not fully automated (it requires user to manually download and install the new version). Microsoft already failed this time, because the vulnerability has been already known and exploited for more than one week.
Right, zero day situations can happen to any software product, and Opera and Firefox might face a similar shitstorm tomorrow. But, even so, there are some interesting differences:

  1. Patching policies: Microsoft implements a predictable monthly patching cycle. This is probably good for corporate IT departments, which can carefully plan the so called “black Tuesday” to minimize their troubles, but it’s also good for evildoers and security attention-bitches, who can carefully plan their exploits or disclosures to maximize their impact. Zero day critical vulnerabilities in three different Microsoft products have been disclosed immediately after last “black Tuesday”: is this really a coincidence?
    Firefox and Opera, on the other hand, issue security updates whenever they’re ready and tested.
  2. Agility: as everybody knows, Internet Explorer is tightly coupled with the underlying Windows OS platform, and this makes both mitigation and fixing more difficult. In this case, for instance, the suggested work-around required not just hardening the browser itself by blocking scripts and plugins, but also disabling a system-wide data access component (OLEDB): this affected not just surfing the web, with many sites inaccessible or malfunctioning, but also most Windows applications relying upon databases.
  3. Viable ad-interim mitigation: even if a browser vulnerability doesn’t involve system-wide components, mitigation until a patch is available almost always requires disabling JavaScript and/or plugin content (the latter is often used to circumvent security features like Vista’s DEP). On IE, such a work-around is hardly acceptable, since “Security Zones”, the mechanism available to selectively change the security level of certain pages, is very obtrusive and almost unusable (yes, way worse than UAC). Opera is friendlier, thanks to its “Site Preferences” which let user quickly change site permissions for JavaScript, Java, Flash and so on. Of course, only a minority of Opera users actually configure a default-deny policy, to selectively allow active content on trusted sites only. However, even those savvy users are suddenly out of luck, if they grant permissions to a site which is vulnerable to XSS: an attacker could circumvent script and plugin blocking by injecting his malicious code there, where it’s allowed to run. But if you use Firefox and you install NoScript, you get a safe default-deny policy configured out of the box and your trusted whitelist is effectively enforced notwithstanding site flaws, thanks to Anti-XSS Protection: JavaScript and other active content will run only where you want it to run.

To summarize: all the browsers can have vulnerabilities and equally need timely patching, but not all the users are equally vulnerable.

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