During the past weeks I've started a new project called ABE, sponsored by the NLnet Foundation and meant to provide CSRF countermeasures configurable on the client side, the server side or both.

As you probably know, 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 developing a firewall-like component running inside the browser. It will be 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 3rd party.

ABE rules, whose syntax is defined in this specification (pdf), are quite simple and intuitive, especially if you ever looked at a firewall policy file:

# 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. via <img>)
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
Logout

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.
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 administrator will be able to declare policies for their own web applications: 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.

An initial implementation will be released during the 1st quarter of 2009 as a NoScript module.
I already collected precious feedback from security researchers like Arshan "Anti-Samy" Dabirsiaghi, Ivan Ristic of ModSecurity fame, Sirdarckcat and others.
More opinions and suggestions about rules design and features are very welcome.

This entry was posted on Saturday, December 20th, 2008 at 2:27 am and is filed under CSRF, Clickjacking, XSS, Mozilla, Security, NoScript. You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.

15 Responses to “Introducing ABE”

Good work, Giorgio. This looks like it would really help out a user looking to protect themselves from these types of attacks, and would work really well as addition to NoScript.

Allowing developers to create their own ABE rules to be downloaded on how requests to their site are made seems rather redundant to me, much like JavaScript form validation is to server-side validation. Many of these rules controlling requests from other sites can be done server-side to protect users, rather than relying on a third-party's implementation and enforcement of the rules. It would also create a scenario where a site's ABE rules would have to be downloaded before serving up a request to that site, but hey IE does it (malware protection).

What I think is the cherry of the cake is..
Sandbox – sends the requests as it is, but disables JavaScript and other active content (e.g. plugin embeddings) in the landing page.

I know that can be abused, but come on.. thats sort of an implementation of HTML5 sandboxed iframes! without the dangerous stuff.. And if it gets mixed with noscript correctly, we dont have to fear of iframe-breaker-breakers (aka, if our host doesnt want to be iframed, it wont).

Great stuff, Giorgio. Do you have any thoughts on how the policies will be transmitted from server to client? Your examples are illustrative, but in the first example policy you have wildcard notation for the target site, while in the second example policy you use a URL. Do you envision pre-flight requests for the policy to be made, a la Access-Control?

@Brandon Sterne:
yes, this example and the attached spec are about syntax and capabilities only.
We're having some discussion in the OWASP Intrinsic Web Security Group about other details, like ruleset download, conflicts and persistence. It's happening on the list, even though I preferred it to happen here in the open, but I'll post intermediate results weekly, if possible.
My current orientations:

Site-provided rules

Site-provided rules will be fetched once per browser session per site (scheme://domain) at most from a rules.abe file indentified with an algorithm like this:

As you can see, resources served via https:// require their rules, if any, to be served with the same protocol.
Redirects are supported both implicitly, via HTTP "Location" header, and explicitly, via a simple custom mechanism to allow scriptless (and server configuration-less) implementation (the ruleset file itself containing just the "Location: URL" line as its own content). Redirections are allowed only towards the same domain or a subdomain, though. Redirections are meant to help deploying all the rules just once (both for secured and non-secured subdomains) on the same secured subdomain if the topmost domain has not a valid certificate.

Priority

Priority decreases from the top to the bottom, both inside each rule and in the ruleset as a whole. Whatever matches first wins, therefore the suggestion to put the most specific rules on the top (e.g. Allow from SELF), to give them precedence, and most general rules (e.g. Deny ALL) on the bottom, to catch the remainders. The visual feedback-driven UI will always modify the topmost matching rule, if any, or will produce a topmost rule.

Merging

Rules from different sources are kept in 3 different "pools":

User's custom rules.

Site-provided rules (those coming from the site which publish its own property).

Community" rules (those downloaded from a centralized authority)

Each rule is given a timestamp, by diffing with the previous ruleset from the same origin.

Conflict resolution

When rules from different origins match current request with different outcomes (e.g. an user rule says "DENY" but a site rule says "ALLOW" for the same resource), ABE will tell user something like

A SUBDOC request from http://xxx.yy is violating a rule of yours, but the site http://somesite.com says it should be allowed.
[Show/Edit the conflicting rules...] [Keep enforcing my rule] [Prefer site's rule]

This way user can see what's going on and choose to keep trusting his own rule over site's (possibly tweaking it, if he's capable of) or to trust the site because site developers know better.

@botted:
Current NoScript in its default configuration (without ABE) is enough to easily defeat JavaScript-based malware.
Notice that script files aren't even requested by Firefox if blocked by NoScript, therefore an external firewall shouldn't complain (opposite to what suggested by one poster on that thread) unless the detected sample is inlined in an HTML file.

@tlu:
dom.disable_cookie_* is not a CSRF countermeasure at all.
It might mitigate some XSS attacks (those which specifically try to log session cookie on a remote server by reading document.cookie), but would break lots of web sites and would not prevent session-riding attacks, which just need you to be logged in: this means a good part of XSS attacks and the totality of the CSRF ones.

[...] support: that’s relatively easy, since I can hook in the work I’m already doing for the ABE module. It’s worth noticing, though, that this is just a cross-browser compatibility effort: neither [...]

Giorgio, can I make this post a sticky on the forum for NoScript. I believe it will reduce the repeated requests for having true-site-specific blocking/allowing feature requests. This tells them its in the works and should reduce the forum load. Let me know and I will prepare and post a summary and link to this.

@Giorgio: When do you hope to have a dummy-friendly addition to the NoScript FAQ? That would also be good to link to in the support forum -- perhaps in GµårÐïåñ's proposed sticky?

Minor feat req: Is there any possibility to allow "preview comment" here for the benefit of poor typist like myself? :)

@GµårÐïåñ: If you are going to do a forum sticky, perhaps you could also draft the FAQ addition in plain language accessible to novice-to-average users, and help take that load off Giorgio? This would reduce the need for individual forum questions even more. Thanks.