ABE - Application Boundaries Enforcer

Warning foreword

This documentation refers to an ancient NoScript version (5.x AKA "NoScript Classic"), and it's kept here for the historical records.

NoScript 10.x and above doesn't ship with the ABE module anymore, because at the time NoScript has been rewritten almost from scratch to support Firefox 57 "Quantum", the WebExtensions API it was forced into, modeled on Chrome's extensions API, couldn't support it at all. Since then, Firefox's own extension API got better, therefore ABE might come back in one form or another some day, but it's still impossible to implement on Chrome/Chromium, and the situation is going to be even worse with Manifest V3.

What's ABE?

The NoScript browser extension improves web client security by applying a Default Deny policy to JavaScript, Java, Flash and other active content and providing users with an one-click interface to easily whitelist sites they trust for active content execution. It also implements the most effective Cross-Site Scripting (XSS) filters available on the client side, covering Type-0 and Type-1 XSS attacks; ClearClick, the only specific browser countermeasure currently available against ClickJacking/UI redressing attacks, and many other security enhancements, including a limited form of protection against Cross-Site Request Forgery (CSRF) attacks: POST requests from non-whitelisted (unknown or untrusted) sites are stripped out of their payload and turned into idempotent GET requests.

Many of the threats NoScript is currently capable of handling, such as XSS, CSRF or ClickJacking, have one common evil root: lack of proper isolation at the web application level. Since the web has not been originally conceived as an application platform, it misses some key features required for ensuring application security. Actually, it cannot even define what a “web application” is, or declare its boundaries especially if they span across multiple domains, a scenario becoming more common and common in these “mashups” and “social media” days.

The idea behind the Application Boundaries Enforcer (ABE) module is hardening the web application oriented protections already provided by NoScript, by delivering a firewall-like component running inside the browser. This "firewall" is specialized in defining and guarding the boundaries of each sensitive web application relevant to the user (e.g. webmail, online banking and so on), according to policies defined either by the user himself, or by the web developer/administrator, or by a trusted 3^rd party.

ABE rules, whose syntax is defined in this specification (pdf), are quite simple and intuitive, especially if you are familiar with firewall policies:

# This one defines normal application behavior, allowing hyperlinking
# but not cross-site POST requests altering app status
# Additionally, pages can be embedded as subdocuments only by documents from
# the same domain (this prevents ClickJacking/UI redressing attacks)
Site *.somesite.com
Accept POST SUB from SELF https://secure.somesite.com
Accept GET
Deny

# This one guards logout, which is foolish enough to accept GET and
# therefore we need to guard against trivial CSRF (e.g. )
Site www.somesite.com/logout
Accept GET POST from SELF
Deny

# This one guards the local network, like LocalRodeo
# LOCAL is a placeholder which matches all the LAN 
# subnets (possibly configurable) and localhost
Site LOCAL
Accept from LOCAL
Deny

# This one strips off any authentication data
# (Auth and Cookie headers) from requests outside the
# application domains, like RequestRodeo
Site *.webapp.net
Accept ALL from *.webapp.net
Anonymize

# This one allows Facebook scripts and objects to be included only
# from Facebook pages
Site .facebook.com .fbcdn.net
Accept from .facebook.com .fbcdn.net
Deny INCLUSION(SCRIPT, OBJ, SUBDOC)

Living inside the browser, the ABE component can take advantage of its privileged placement for enforcing web application boundaries, because it always knows the real origin of each HTTP request, rather than a possibly missing or forged (even for privacy reasons) HTTP Referer header, and can learn from user’s feedback.

A preliminary ABE implementation is provided with NoScript 1.9.3.6 and above, and local rulesets can be configured from NoScript Options|Advanced|ABE. Rules for the most popular web applications will be made downloadable and/or available via automatic updates for opt-in subscribers, and UI front-ends will be provided to edit them manually or through a transparent auto-learning process, while browsing. Additionally, web developers or administrators can declare policies for their own web applications: if user enabled the Allow sites to push their own rulesets option, ABE will honor them, unless they conflict with more restrictive user-defined rules.
As soon as browser support for the Origin HTTP header becomes widespread and reliable, an external version of ABE might be developed as a filtering proxy.