Archive for the ABE Category

ABE Quantum is the combination of Contextual Policies, one of the most requested features in NoScript's history, and LAN protection, an important "Classic" defense lost in the 2017 Quantum migration.

After years of waiting and months of hard work, this good stuff (which I personally missed a lot, too) is finally in the hands of all NoScript 11.3 users*, thanks to the precious support by the NLNet Foundation and the Next Generation Internet programme (more specifically the NGI0 PET fund).

The "ABE Quantum" nickname comes, of course, from the Application Boundary Enforcer module of NoScript Classic, which both Contextual Policies and LAN protection are in a sense a "modernized" descendant of, sacrificing some of the extreme flexibility of the original's firewall-inspired policy definition language in order to provide a simpler, more accessible and more intuitive user experience directly integrated in NoScript's main CUSTOM UI.

ABE Quantum Screenshot

Contextual Policies

Contextual policies let you assign different permissions (or "enable different capabilities", in NoScript's parlance) to a certain site depending on its context, i.e. which is the top level site (the address currently shown in the navigation bar).

For instance, you might want to enable scripts from twitter.com only if you're visiting maone.net - intrigued by Maone's awesome embedded tweet feed ;) - but not elsewhere, because you don't like Twitter to track you everywhere you go:

  1. While on maone.net, open NoScript's popup and select CUSTOM as the policy for twitter.com. You'll see a new drop down box, initially set to ANY SITE.
  2. Remove all the capabilities (e.g. script) you don't want Twitter to use on ANY SITE (notice that when CUSTOM is selected first time, the capabilities from the previously selected preset get copied, so if it was DEFAULT you can probably leave them that way).
  3. Then select ...maone.net from the drop down, and switch script, fetch and frame (the capabilities outlined in red, meaning they're are needed by twitter.com) on.

You're done: scripts from twitter.com are allowed to run only when the main site displayed is maone.net.
You can repeat this on any website (including twitter.com itself) where you want Twitter scripts and subdocuments to work normally.
If you change your mind, you can reset some or all the contextual policies you previously set in the CUSTOM permissions deck, either on from the popup (only for the current context) or from the Options>Per-site permissions panel, where all the context sites you had configured plus the ANY SITE default are listed in the Enable these capabilities when top page matches... dropdown.

LAN Protection

Simply put, the LAN capability lets documents coming from the public Internet (AKA World Area Network / WAN) to link / send requests to hosts inside your Local Area Network (LAN), which is pretty what they can do now, allowing so called cross-zone CSRF/XSS attacks.
By keeping it disabled (the factory setting in the DEFAULT and UNTRUSTED presets), you're replicating this feature from "Classic" NoScript, without the hassle of going through ABE's firewall-like rules when you need to set an exception, which now is just a matter of checking the LAN capability box.

The Contextual Policies & LAN Protection (ABE Quantum) project was funded through the NGI0 PET Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology under grant agreement No 825310.

* already available in auto-update from AMO, still waiting for review at the Chrome Store while writing this post.

Universal XSS 0day in Adobe Flash controlled users' Web accounts:

As useful as sandboxes are in restricting potentially buggy code to a small part of the operating system, they do nothing to minimize the damage that can be done by attacks that exploit universal XSS flaws, researchers said.

I was already preaching this four years ago: the more our assets move "in the cloud", the less traditional security measures, meant to protecting just your local system, suffice.

The battlefield is the web now, and there's no coming back...

I'm pleased to announce the availability of NoScript 3.0a8 for mobile devices. Tested on Firefox for Android, it should work on Maemo too.

This is the first feature-complete mobile version of NoScript. In other words, it provides all the major security features of its desktop counterpart which make sense on a mobile device:
NoScript for Mobile Options

Important usability-oriented features -- such as Script Surrogates or the ability to emulate JavaScript-only navigation on sites where scripting is blocked -- have been ported as well, and other have been developed from scratch. For instance, on first run NoScript offers new users the ability to choose its default configuration among 4 presets which may be changed later:

  1. Easy Blacklist (you pick untrusted sites where JavaScript and plugins must be blocked)
  2. Click To Play (plugin a and audiovisual content is blocked until you click a placeholder)
  3. Classic Whitelist (you pick trusted sites where JavaScript and plugins can run, similar to the default NoScript 2.x setup)
  4. Full Protection (like "Classic Whitelist", but all the embedded content is blocked until you click, even on trusted sites)

Furthermore, while the in-page permission UI has been greatly simplified and optimized for touchscreen consumption, NoScript for Mobile In-Page Permissions UI the underlying engine has been redesigned to allow deep per-site customization at the single permission level (e.g. making Flash permanently work by default on site X but not on site Y, even if JavaScript is allowed on both, or causing restrictions on a certain embedded object to depend on its parent page's address). These fine grained permissions will be configured through a new desktop UI (under development, slated for inclusion in the first cross-device NoScript 3 beta) and synchronized safely via Firefox Sync across all the PCs, tablets and smartphones where NoScript is installed.

Talking about synchronization, you can already share your NoScript settings among your mobile devices (just check the "Enable Remote Sync" option), but you'll need to wait for the aforementioned cross-device beta to include your PC in the synchronization pool.

Last but not least, NoScript 3 doesn't require a browser restart on installation and updates, which means that hot fixes for new security threats can be deployed in a more effective, timely and convenient way.

And here we are: NoScript users can now bring to their smartphones and tablets the same secure browsing experience they enjoy on the desktop.

It's not been easy, and there's still a lot of work ahead to merge into the desktop version the many under the hood enhancements that this full rewrite of NoScript's internals brought us as a welcome side effect, but this is probably the most important milestone in NoScript development since the XSS filter invention. So let's celebrate and thank from the bottom of our heart the people who made it possible: the NLNet foundation which believed in this project since the beginning, and all those individuals, institutions and companies relying on and contributing back to NoScript.

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?

NoScript 2.0.4 has been released yesterday, with some bug fixes and one main addition: strict X-Content-Type-Options: nosniff enforcement.

NoScript, for a long time, had already being enforcing content type checks on cross-site Javascript and CSS includes, and recent Firefox versions introduced similar built-in mitigations, albeit limited to stylesheets, in order to mitigate CSS-based data theft.

Nevertheless, X-Content-Type-Options offers a nice opportunity to further hardening, by allowing web sites to opt-in for the strictest checks, on more file types and also same-domain, in a theoretically compatible way.

A side effect of this addition is that Firefox 4 + NoScript now scores 14/16 on Browserscope's Security Test, in "Allow Scripts Globally" mode (i.e., without blocking any JavaScript or active content)!
Browserscope Security Test
For those who don't know it, Browserscope is a project which aims at profiling and comparing browser capabilities, with a special eye for security features.

By comparison, only Google Chrome boasts a higher score of 15/16, because it supports both the HTTP Origin Header and the HTML 5 Sandbox Attribute, which are not implemented yet by Firefox nor by NoScript. For the curious, "vanilla" Firefox 4 nightlies stop at 11/15 (even if you're going to read 12/15 because of a XSS test bug), Firefox 3.6.12 + NoScript is at 13/15, while disabling NoScript makes it fall down to 9/16 (reported as 10/16 because of the aforementioned bug).

However, a fair comparison would need to cover also Content Security Policies, a very powerful and flexible security technology developed by Mozilla (test should be added soon, it seems) and countermeasures for cross-zone CSRF attacks (e.g. against routers), which are currently provided by NoScript and, partially, by Opera (Mozilla is working on something, too)*. If and when these features get tested, Firefox 4 + NoScript will lead at 16/18, followed by Chrome at 15/18.

That said, I'd really love to see Origin and Sandbox implemented natively by Firefox, for a perfect 18/18. Which is, I guess, the real raison d'être of Browserscope: getting good stuff implemented everywhere by the power of childish envy ;)

* I won't advocate including tests for other non-blocking security features provided by NoScript, such as ClearClick anti-Clickjacking, because they're not suitable for web-based automation.

Update 2010-11-13

Firefox 4 + NoScript scores 15/17 now!

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