“Obama is young, handsome, and suntanned too.”

Silvio Berlusconi during today’s official Russia-Italy press conference in Moscow

In other news, I’m about to release first official NoScript version with Fennec support, so please wait a few hours before bombing Italy.

You’ve done the right thing :)

• OWASP Presentation (video)
• White Paper
• Effective CSS-based Clickjacking techniques by Sirdarckcat

Regarding protection, if you’re a Firefox/NoScript user you should already know about ClearClick. If you’re not, I feel a bit sorry for you.

History will tell that George W. Bush has been a great, very great President of the United States

Silvio Berlusconi, Italian Prime Minister, Columbus Day 2008

George, please, in November take Silvio with you.
Many thanks.

The most specific and ambitious is called ClearClick: whenever you click or otherwise interact, through your mouse or your keyboard, with an embedded element which is partially obstructed, transparent or otherwise disguised, NoScript prevents the interaction from completing and reveals you the real thing in “clear”. At that point you can evaluate if the click target was actually the intended one, and decide if keeping it locked or unlock it for free interaction. This comes quite handy now that more dangerous usages of clickjacking are being disclosed, such as enabling your microphone or your webcam behind your back to spy you through the interwebs.

As you already know if you read my first clickjacking article, an old and benign clickjacking example is NoScript’s “Install Now” orange button, which overlays the green one on addons.mozilla.org to work-around the installation security warning. If you click it with ClearClick enabled, now you get warned about something sneaky going on.

I do not need to change my button yet, because NoScript 1.8.2.1 ships with ClearClick enabled on untrusted (non whitelisted) parent pages only, while the whitelist status of the embedding is irrelevant. This gives a good balance between effectiveness and usability, since the attacker in a clickjacking attack is always the parent. If you want to get the warning on noscript.net and on the other sites you trust, you need to flag the second checkbox on NoScript Options|Plugins|ClearClick protection on pages… [x] untrusted [x] trusted. I recommend to flag it anyway and report any usability issue, because this feature so far seems quiet and unobtrusive enough to justify my temptation of enabling everywhere (trusted + untrusted) by default on next stable release, but it must get a lot of testing from you first.

Other clickjacking-related features included in this release are:

1. Opaque embedded objects: plugin content and frames are forcibly made opaque and get styled with “overflow: auto” (i.e. get scrollbars if their inner size exceed their viewport) on untrusted pages.
2. Frame Break Emulation: if a framed page which is not allowed to run JavaScript contains a “frame busting” script similar to <script>if (top != self) top.location = location</script>, the intention of the page author is honored by NoScript, i.e. the page replaces the topmost document. You can control this feature toggling the noscript.emulateFrameBreak about:config preference.
3. Some usability and effectiveness improvements in frame management, making the Forbid IFRAMEs option more suitable for general usage.

I hope to find some time during this week to write another post, diving through the technical details behind my ClearClick implementation: a fairy tale about a very simple and hopeful idea (unconventional <canvas> usage) fighting against an army of quirks and mundane details. In the meanwhile, many thanks to Sirdarckcat, RSnake, Michal Zalewski and Matt Mastracci for discussion, testing and inspiration.

Specifically, since 1.8.1.7 (released past Friday), embedded objects of any kind are forcibly made opaque if placed on a non-whitelisted page, giving user a clear view on what he’s about to click.
A further protection layer, automatically disabling any user interaction with partially obstructed documents (similar in concept to Zalewski’s preferred proposal), will go in a stable release by the end of this week, but current development builds are already safe and good enough for general consumption, so I recommend upgrading now (update) is available in NoScript 1.8.2 and above.

Starting this fresh development line, rather than sitting on the serendipity of old NoScript features being able to prevent known forms of clickjacking, proved to be a very wise thing to do.
In facts, both RSnake and Ronald during the last two days found frame blocking work-arounds. RSnake in particular, being a NoScript user himself, has been so kind to do responsible disclosure, giving me also a lot of constructive feedback about the alternate mitigation ideas I was developing.

I must be grateful to Ronald as well, because he — even if in a less cooperative way — underlined a conceptual weakness in IFRAME blocking (since OBJECTs can behave just like IFRAMEs, they should be blocked according to the very same criteria), but I have to rectify this statement from his public disclosure post:

The latest version of NoScript allows it’s users to block iframes in order to protect themselves from “Clickjacking”.

NoScript has been capable of blocking IFRAMEs for a long time: this feature had been introduced mainly to make Gareth Heyes happy, more than one year ago. As often observed with NoScript, an old feature happens to be effective against new threats.
Unfortunately, bugs happen too and IFRAME blocking not being applied to all the frame-like elements is what I do consider a bug. This one will be fixed in the automatic stable update you’re going to receive in a few days, but in the meanwhile is already fixed; you can enjoy the new specific clickjacking protection, no matter if you block frames or not, by simply upgrading to NoScript 1.8.1.8 or above.

Update Oct 2^nd, afternoon

The frame/object bug has already been fixed in 1.8.1.9, one more reason to upgrade.

Update Oct 7^th

NoScript 1.8.2 is finally out, featuring the brand new exclusive ClickClear technology against Clickjacking. Upgrade now!

Is there anything that users of IE, Chrome and other browsers (who cannot use NoScript) can do to protect themselves from clickjacking?

If you read my previous post about it, you already know that currently the only way to protect yourself is disabling JavaScript, plugins/ActiveX and IFRAMEs.
NoScript is the most elegant and usable solution to do it for browsers based on Mozilla technology (like Firefox), because it gives you a quick one-click way to enable the missing technologies on sites you trust and remembers your choices in a whitelist, becoming almost unnoticeable after some “training” about your surfing habits.

Unfortunately, this is not as easy, bearable or even feasible if you use a browser not supported by NoScript (other than Linx or Elinks).
Let’s see what you can do with IE, Safari, Chrome and Opera:

• Internet Explorer

  Open Internet Options|Security, select the “Internet” zone and set the “Security level for this zone” control to “High”.
  Bad news: there’s no apparent way to disable IFRAMEs in IE: you can just disable “Launching programs and files in IFRAME”, which is definitely not enough to prevent clickjacking.
  Furthermore, while Microsoft’s “Internet Zones” can allow individual sites for scripting or active content, their usability is extremely poor if compared to NoScript, requiring several clicks and typing to build a whitelist. So, to recap: MSIE can’t be secured 100% against clickjacking, and the protection you can get comes with a big usability cost.

• Safari

  Apple’s browser has a central place to disable active content in its Preferences|Security tab.
  Bad news here are two: there’s no mean to enable features selectively (per site), and IFRAMEs cannot be disabled in any apparent way (Mac users, please let me know if I’m missing something¹). Therefore Safari can’t be secured 100% against clickjacking, and the protection you can get comes with an enormous usability cost.

• Chrome

  If you’re a Chrome user, you’re really out of luck: the only apparent way to disable active content is starting the browser with the following command line:

  chrome.exe -disable-javascript -disable-java -disable-plugins
  

  Of course, you cannot enable back any of these features until you restart your browser with different command line arguments. Even worse, there’s no “-disable-iframe” option. So Chrome can’t be secured 100% against clickjacking, and the protection you can get comes with the worst usability cost.

• Opera

  Opera has the best built-in security user interface among browsers, very similar to NoScript’s concepts: you can set restrictive defaults if you want, and relax some restrictions on selected sites you trust, using Site Preferences and Quick Preferences. It’s just slightly less usable than NoScript, and it can be configured to prevent clickjacking: you need to disable everything you can see in Preferences|Advanced|Content, then enter opera:config in your address bar, click the “Extensions” handle and uncheck the “IFrames” line.

Final note: current NoScript development versions (1.8.1.7 and above) provide protection against IFRAME-based clickjacking even without disabling IFRAMEs. This is a further usability/security advantage over any other solution, and it’s being tested by Sirdarckcat (a pioneer of malicious CSS overlays) with a final stable released planned for the end of this week. Therefore, if you can choose, your best usability+security choice is still Firefox+NoScript.

Update

If you did not yet, you should upgrade to NoScript 1.8.2.1 or above, for the reasons explained here.

Looks like Clickjacking is the web-security buzzword of the week (month?), since Robert “RSnake” Hansen and Jeremiah Grossman decided to cancel their OWASP talk, drawing an aura of mystery around the whole issue and its magnitudo.

Nevertheless some info and speculations have been percolating, and even if the precise details of the attacks proposed by those two researchers are still embargoed, especially because of the serious and not necessarily obvious implications worrying Adobe, a certain awareness about the general technique and the possible countermeasures does circulate now. In Jeremiah’s and RSnake’s words:

Think of any button on any Web site, internal or external, that you can get to appear between the browser walls, wire transfers on banks, Digg buttons, CPC advertising banners, Netflix queue, etc. The list is virtually endless and these are relatively harmless examples. Next, consider that an attack can invisibly hover these buttons below the users’ mouse, so that when they click on something they visually see, they actually are clicking on something the attacker wants them to. […]
Say you have a home wireless router that you had authenticated prior to going to a [malicious] web site. [The web site] could place a tag under your mouse that frames in a single button an order to the router to, for example, delete all firewall rules.

In other words, the attack is thrown by a malicious web page embedding objects, possibly from a different site, such as framed documents or plugin content (Flash, Silverlight, Java…) which may lead to unwanted results if clicked by the current user (e.g. a “Delete all messages” button in your webmail or an advertisement banner in a click fraud scheme). Using DHTML, and especially CSS, the attacker can disguise or hide the click target in several ways which go completely undetected by the user, who’s easily tricked into clicking it in a more or less blind way.

JavaScript increases the effectiveness of these attacks hugely, because it can make our invisible target constantly follow the mouse pointer, intercepting user’s first click with no failure. We can however imagine a few less effective but still feasible scriptless scenarios, e.g. covering the whole window with hidden duplicates of the target or overlaying an attractive element of the page, likely to be clicked (e.g. a game or a porn image link), with a transparent target instance.
Nevertheless, as RSnake puts it,

[…] the best defense against clickjacking attacks is to use Firefox with the NoScript add-on installed. Users running that combination will be safe, said Hansen, against “a very good chunk of the issues, 99.99 percent at this point.”

That’s true because attacking from an untrusted page not allowed to run JavaScript is highly impractical, but also because NoScript by default prevents Java, Silverlight and especially Flash content, which seem so far the most dangerous clickjacking targets, from being embedded on non-whitelisted pages.

But what about that damned 0.01%? That’s given by framed documents, most notably IFRAMEs. For a live and benign example of what you can do with IFRAME-based clickjacking, look at NoScript’s “install now!” widget, which gets dynamically overlayed by the addons.mozilla.org install page: they’re positioned so that if you click on the orange button you automatically install from AMO, skipping the security notification bar you would get on any other site. This “clickjacking” of mine has been there for a long time (since AMO V3, IIRC), and it heavily relies on JavaScript.

But even if an IFRAME-based attack was carefully crafted to work without JavaScript, NoScript would still provide effective protection, scoring a perfect 100% by RSnake’s standards. You just need to enable the Plugins|Forbid <IFRAME> option, and cross-site IFRAMEs will be blocked by default on untrusted pages: they will need a confirmation to be activated, therefore “blind clicks” become impossible. Zone 365 and Hardware Forums created a short video tutorial about this setting. If you want to be protected even against unlikely attacks thrown from a trusted site included in your whitelist, check Plugins|Apply these restriction to trusted sites as well: embedded objects (plugin content and frames) get blocked on every site, but you can enable any of them on the fly by clicking on its placeholder.

A final recommendation is reading this Michal Zalewski’s contribution, which covers the IFRAME case only but is very generous with mitigation proposals, both for web developers and browser vendors: by the way, his browser fix proposal #4 is almost identical to current NoScript’s Forbid <IFRAME> option, and simpler variants of proposal #3 are being explored as default features in NoScript development builds since version 1.8.1.7.

Also released this week:

• NoScript 1.8.1.5, featuring several HTTPS effectiveness enhancements
• FlashGot 1.1.1.6, improving FlashGot Media compatibility with non-Flash streaming movies.