Archive for July, 2011

NoScript Awarded for Security InnovationToday I've been notified by Patrick Green, the Chair of the Dragon Research Group Advisory Council, about NoScript having been chosen as the recipient of their Security Innovation Grant.

This is a great honor and a spur to keep making the Web a safer place. I feel the urge to thank the committee for recognizing NoScript as a pioneering force in browser security, and the community of contributors, researchers, translators, beta testers, and loyal users who keep this project alive day after day.

The grant will fund the effort to merge the current two development lines, i.e. "traditional" NoScript for desktop environments and NSA (NoScript 3.0 alpha for Android, generously aided by the NLNet Foundation). More specifically, it will support the implementation of a desktop UI, more powerful than the streamlined smartphone optimized one already developed for NSA, but leveraging the same almost entirely rewritten multi-process back-end: this will allow an unified "NoScript Anywhere" package to be installed indifferently on PCs and mobile devices, sharing the same configuration and permissions everywhere via secure remote synchronization.

Thanks to this unexpected help from the Dragon Research Group, we can look with more confidence at the goal of releasing a NoScript Anywhere beta build for Android and desktop Firefox by September.

Update

The official announcement is online.

According to Mark Finkle, who comments Daniel Glazman's reply to Wladimir Palant (and the discussions goes back many hops yet)

[...] there are two classes of binary XPCOM components:

  1. XPCOM wrappers around 3rd-party binary libraries: We use this model for exposing external binary functionality into JavaScript so add-ons and applications can access the libraries. Using js-ctypes should provide a simple, non-breaking way to expose the libraries. You create a simple JavaScript wrapper in a JavaScript XPCOM component. We need more examples of using js-ctypes to do this, but it works.
  2. Pure binary XPCOM components built only using the Mozilla platform: Sometimes the functionality you want to expose is actually locked away in the Mozilla platform itself. Maybe there is no public nsIXxx interface or the existing interface has a [noscript] attribute on a property of method. This model shouldn’t be required anymore, in my opinion. Mozilla is pushing JavaScript based components and we should be exposing as much as possible to chrome JavaScript. I would encourage add-on developers to file bugs and lobby to expose binary-only parts of the Mozilla platform to chrome JavaScript.

I fully subscribe to Mark's opinion about the second category, but unfortunately this is not just as simple as removing the [noscript] flag from interesting APIs (and introducing some wrapper types to make it possible).

What about subclassing a platform component in JavaScript? Of course you cannot as long as its interface expose any [noscript] member, but you cannot either if it happens to be marked as thread safe. That's the case of the DNS Service, which can be called from any thread. I've considered wrapping it in order to satisfy a strict requirement of ABE's (intercepting HTTP requests after DNS resolution but before any data is sent to the web server) in a less hackish way than today, but this would currently require building a XPCOM binary for each supported native platform. That's a trouble I'd gladly spare myself, and Mozilla's making it unsustainable anyway. So, does Mark's statement imply that the relatively recent ban on multi-threaded JavaScript might be reconsidered? Is this even possible in this brave JSCompartment new world?

Last week a couple of interesting and novel Clickjacking techniques have been published:

  1. Cross-domain content extraction via framed view-source
  2. Double-clickjacking (or, as I prefer to call it, Rapid fire cross-site interaction)

Both involve a tiny amount of social engineering (#2 requires JavaScript, too), but as you can see they are totally feasible.

Needless to say, recent NoScript versions neutralize them no matter if JavaScript is enabled or not, thanks to specific enhancements in NoScript's unique anti-Clickjacking protection module, ClearClick.

ClearClick anti-Clickjacking on Android

NoScript 3.0a3 for Firefox Mobile is out, bringing three of the major "classic" NoScript features to your Android smartphones:

  1. Easy per-site active content permissions management.
  2. The first and most powerful anti-XSS (cross-site scripting) filter available in a web browser.
  3. ClearClick, the one and only effective client-side protection against Clickjackings available on the client side.

Still some road ahead for convergence between the desktop and the mobile versions, but we're already past the biggest challenges...

A huge thanks to the NLNet foundation, and to many individuals, institutions and companies using NoScript, for their generous support to this project.

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