Archive for the Google Category

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

During the past few days I've been repeatedly asked the same question:

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

    IE's security settingsOpen 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

    Safari's security settingsApple'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 something1). 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 ( 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.

Mike Perry's Automated HTTPS Cookie Hijacking just made Slashdot's front page, so I decided to spend some time nesting a countermeasure inside NoScript's request intercepting guts.

The original idea comes from an email conversation I had with pdp just after his GMail account had been compromised: he suggested to mark every cookie with the "Secure" attribute, causing the browser to send it exclusively over HTTPS connections.
Later he detailed this concept as a feature of his yet to be developed BrowserSecurify plugin:

Secure cookies: The feature will prevent the browser from sending cookies over unecrypted channels, once activated. This feature will mark insecure cookies as always secure. This effectively means that you login into GMail and continue browsing Google over unencrypted channel not being afraid of leaking sensitive data which can be used to compromise your GMail account.

NoScript's new feature, called Forced Secure Cookies is slightly different, less obtrusive and non-interactive.
In facts, NoScript just intercepts the "Set-Cookie" headers which are being sent over encrypted connections and are not flagged as "Secure" yet, adding the missing attribute on the fly before the cookie is stored.
This way, only those cookies actually created in the context of an encrypted transaction are forcibly switched to "Secure", and therefore sites having lower security requirements and needing insecure cookies to work as a non-sensitive persistence mechanism are less likely to break.
Obviously those sites creating session-identifier cookies over insecure channels and recycling them after secure authentication won't be helped by this implementation, but it's apparently not the case of GMail, for instance.
However, should that prove itself to be such a common pattern to be worth protecting, a check on HTTP/HTTPS switching could be added to erase any previously set domain cookie.

Forced Secure Cookies, like Anti-XSS Filters, are designed to work independently from your trusted whitelist; in other words, it does not care about JavaScript and plugins permissions and will be effective even if you "allow script globally" (not recommended, as usual).
Are you're in the mood for beta testing? Please grab latest NoScript development build and drop me a line if it appears to summon any black hole swallowing your planet.

Since I spent a relevant portion of my past two days answering email messages similar to the following, I decided to post a catch-all answer here.

Hi Giorgio,

I just read Google's introduction to its Chrome browser.
I was so impressed with its security features that I may even switch from Firefox to Chrome. (I didn't think that was even possible when I first heard of Chrome.)
Would you consider adapting your NoScript add-on to it?
I tried out Chrome and loved it, but the absence of NoScript was immediately apparent!


Hi Seth,

I've been playing with Chrome since it's been available, and I cannot say I'm impressed with its security.
I do like its speed, but Fx 3.1 builds with TraceMonkey enabled are already faster.
I really love its taskmanager: opening a random MySpace page and watching CPU and RAM consumption skyrocketing blamed precisely on the Flash plugin (70MB Flash, 28MB the page itself versus 11MB for an empty tab) is kind of cool, even if it comes with the cost of redundant resource allocation (if it was Firefox, crowds would be screaming "memory hog").
On the other hand, there's nothing apparently novel in its security approach, and it doesn't address any in-browser security problem, such as XSS or CSRF, at all.

The worst part, though, is that Chrome is not nearly as extensible as Firefox: cynical people may suspect this is to prevent something like AdBlock Plus or NoScript itself to be ported, biting advertisement bottom lines.
This is such a bummer that Google had to issue a late announcement about an extension API, but if it's gonna be like Opera's widgets (as I strongly suspect) it won't help.

BTW, one of Chrome's most hyped features, stability due to the claim you might crash one tab but not the whole browser, fully justifies the "beta" tag:
Chrome Crash


As you probably have heard, security expert Petko D. Petkov (pdp), founder of GNUCITIZEN, had his GMail account violated and raided.
He told me he did not believe it had been a classic man in the middle attack, as many of us speculated during the past days, and interviewed by Dan Goodin he blamed XSS:

In an email exchange, Petkov said he suspected his Gmail account was accessed through a cross-site scripting (XSS) flaw.

Perhaps, but that doesn't make sense to us. XSS exploits typically allow you to enter restricted parts of a website without the benefit of a password. Whoever broke into Petkov's account was able to archive an entire email spool into an mbox file. Without knowing his password, the attackers most likely would have had to archive all 2GB message by message.

It makes sense to me, though (even if I still bet on a MITM, since GMail has been secured against cookie leakages side-tracking HTTPS only very recently): if you combine any XSS vulnerability with the very handy automatic password completion offered by modern browsers, stealing credentials becomes absolutely trivial.

However, if Petko is right, a certain comment of his about NoScript, posted under an article about GMail attacks (!) almost one year ago, sounds totally ironic now ;)

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