Archive for the Google Category

On April the 1st (!) 2009 I had a phone call with Mickey Kim of Google. The Chromium development team was starting to design a browser extension API, and they wanted to know what kind of hooks were needed for FlashGot and NoScript to be ported on Chrome. I gave them detailed answers with references to related Mozilla technologies, and they promised to keep me updated with progresses.

Eight months later, Chrome extensions are here but NoScript is not among them yet, and people are asking why. The reason is very simple: Chrome is still lacking the required infrastructure for selective script disablement and object blocking.

Maybe Google plans to implement the missing stuff later, maybe they're still trying to figure out whether it can be done without enabling effective ad blocking, but in the meanwhile the pale AdBlock and FlashBlock imitations which have been hacked together by overwhelming popular demand, are forced to use a very fragile CSS-based hiding approach, ridiculously easy to circumvent.

Just install the most popular FlashBlock clone for Chrome and visit this page I put together in 3 minutes to see what I mean...


Sam Hasler came to the rescue:

The top rated FlashBlock clone for Chrome does block your example page.

Of course, it took another 3 minutes to fix "the top rated" as well ;-)

If you can see my Google Talk Badge on the right, either you're browsing with anything else than IE8/Chrome/Safari/Firefox+NoScript, or the issue we're talking about has already been fixed by Google. Edit 7 Dec 2009: the issue has been fixed, so I've removed my badge to prevent a spam flood.

Otherwise, you're getting an error page (hard to read, since it's embedded in a tiny frame) -- or a blank one if you're on Chrome -- because Google is sending down a X-Frame-Options HTTP header with value


, allowing only pages served from to embed this badge.

Now, Google playing the early adopter of bleeding edge security technologies like


or STS, both in its browser and in its web properties, is really great because it speeds up their acceptance hugely, making the whole web safer. But if the service you're offering is based on cross-site frames, you'd better keep them enabled ;-)

On a side note, users can easily disable NoScript's implementation of


, if needed, via about:config preferences: either globally (noscript.frameOptions.enabled) or per-embedding-site (noscript.frameOptions.parentWhitelist). Don't worry, ClearClick will still be watching your back...

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?)

Just googled for Vista TCP Limit on behalf of FlashGot user.
The first 500 results at least are all reported as malicious sites, including the top two, Softpedia and MSFN.
Luckily enough for P2P addicts, Firefox's Safe Browsing -- even if backed by Google's data -- doesn't seem to agree ;)

Update Sat Jan 31 2009 16:32:50 GMT+0100

Looks like it was a more general Google bug, fixed now.

Sooner or later you, dear NoScript user, may face this puzzle: you already allowed every single script source looking "legitimate" on a certain page, but the damn thing stubbornly refuses to work as it should. Then, in a moment of enlightenment, you dig inside your Untrusted menu, and there you find You put it there long ago because you don't like to be tracked, but now you cross your fingers and temporarily allow it... et voilà, the page starts behaving!

Now, you may ask why the hell a web site requires Google Analytics scripts to be enabled for providing its basic features, and you might be right: no reason for that. On the other hand, a growing number of web sites leverage Google Analytics for more than just tracking page views and navigation: they also try to collect finer grained usage data about some specific features of theirs. Therefore they call functions or reference objects from from their own "1st party" specific scripts, e.g. when you click a certain button: if is blocked by NoScript (or by AdBlock Plus, or by your hosts file, for the matter), the 1st party code referencing it will obviously fail and the button will stay dead. You can be hinted about Google Analytics being the culprit by opening Tools|Error Console and watching for errors like "urchinTracker is not defined" or "_gat is not defined”.

So far, all you could do about that was allowing But latest NoScript ( or above) implements a new feature, called Surrogate Scripts, which works around this problem out of the box and is customizable enough to cope with similar 3rd party script issues in the future. How does it work? Very simple: whenever an external script is blocked, NoScript checks if its URL matches a certain pattern, and if it does an alternate user-provided surrogate script gets executed instead, in the context of the loading page. There you can define surrogates for any required object or function.

There's no UI for this feature (yet?), but its intended audience is likely geeky enough not no need one.
You can specify as many URL/surrogate mappings as you want, by creating a couple of about:config preference entries under the noscript.surrogate root.
The built-in Google Analytics mapping can be regarded as a reference:

  • *
  • var _0=function(){};with(window)urchinTracker=_0,_gat={_getTracker:function(){return {__noSuchMethod__:_0}}}
    var _0=function(){};with(window)urchinTracker=_0,pageTracker={_setDomainName:_0,_trackPageview:_0,_initData:_0},_gat={_getTracker:function(){return window.pageTracker}}*

If you want to exempt some pages from this replacement (e.g. because they already provide a graceful fallback for missing external scripts), you can add an URL pattern to the preference, e.g. * * Script Surrogates can be disabled globally by setting noscript.surrogate.enabled to false.

Happy hacking :)


Jesse Andrew told me about some Google Analytics API not covered by the original surrogate, so rather than trying to find out every possible tracker method, present and future, I decided to catch them all by exploiting a nifty Mozilla JavaScript feature, i.e. __noSuchMethod__. Please get (latest development build) if you want to this more reliable approach right now.

Update 2

Since I've been asked by concerned non-geeks (especially those who can't read JavaScript code) what exactly the Google Analytics surrogate does, here's a plain English description: the Google Analytics surrogate script does NOTHING. It’s a dummy “catch all” replacement for the most common Google Analytics functions: it makes the calling pages happy, helping not to break sites, but doesn’t send nor receive anything to/from Google.

Update 3

NoScript now supports a second kind of script surrogates, called "Page-level surrogates": if the sources patterns start with the "@" character, the replacement scripts are executed before the matched page starts to be parsed and before any other script can run. This allows preemptive patching of the loading page, similarly to GreaseMonkey but in a more pervasive way, since GreaseMonkey's scripts can run only when the DOM is already parsed (i.e. after page scripts already run).

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