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

# 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

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

# 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

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.

15 Responses to “Introducing ABE”

  1. #1 Sean says:

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

  2. #2 sirdarckcat says:

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

    Ah well, this is a good project, and Im very excited about it.

  3. #3 Brandon Sterne says:

    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?

  4. #4 Giorgio says:

    @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:

    function findRules(someURL) {
      let domain = someURL.domain;
      let scheme = someURL.scheme;
      let rules isValidDomain(domain)
        ? getChachedRules(scheme, domain)
           || loadFromNetwork(scheme, domain)
           || findRules(scheme + "://" + parentDomainOf(domain));
       : NULL;
      if (rules) setCachedRules(scheme, domain, rules);
      return rules;
    function loadAndCacheFromNetwork(scheme, domain) {
      let rules = httpLoad(scheme + "://" + domain + "/rules.abe");
      if (rules) {
        if(/^Location: .*$/i.test(rules)) {
          return handleCustomRedirect(scheme, domain, rules); // this will take care of DOS loops, if any
      return rules;

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


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

    1. User's custom rules.
    2. Site-provided rules (those coming from the site which publish its own property).
    3. 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.

  5. #5 botted says:

    Can ABE help filter JavaScript-based dropper style malware, which the shadowserver folks say is not well detected by anti-virus vendors’ products?

    (Website forum I listed discusses a tiny example of the issue; result of clicking on imagefap thumbnails seemed no more than nuisance, but could change of course)

  6. #6 Giorgio says:

    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.

  7. #7 tlu says:

    Very good work, Giorgio, as usual.

    What do you think about adding


    to user.js as a CSRF countermeasure?

  8. #8 Giorgio says:

    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.

  9. #9 hackademix.net » Ehy IE8, I Can Has Some Clickjacking Protection? says:

    [...] suggested as fix #1 in Michal Zalewski historical “UI Redressing” post and to ABE’s SUBdocument rules) offers an alternate options which, currently, works only in IE8 RC1. Funny how Microsoft can turn [...]

  10. #10 hackademix.net » IE8's "Clickjacking Protection" Exposed says:

    [...] 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 [...]

  11. #11 owaspscrubbr - Search your databases for stored cross-site scripting (XSS) attacks. | PenTestIT says:

    [...] Introducing ABE [...]

  12. #12 GµårÐïåñ says:

    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.

  13. #13 Tom T. says:

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

  14. #14 hackademix.net » Meet ABE says:

    [...] been quite a long development journey since my first announcement, made possible by NLNet’s foresight, and it required more than one month of beta testing: [...]

  15. #15 Seth Wisely says:

    Was there a bit of federalism on your mind when you coined the name?

    Have you considered creating a fox 3.5+ GUI manager for Security Policies?

    Though as number of security extensions in a profile increases so does the load. I sometimes pine for proxomitron.

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