[owasp-intrinsic-security] Application Boundaries Enforcer (ABE) -Call for Input

Arshan Dabirsiaghi arshan.dabirsiaghi at aspectsecurity.com
Tue Nov 4 11:27:17 EST 2008

Unfortunately, we could not get to properly discuss ABE in the working group session. There was lots of discussion on short term problems and solutions. In the long term, we agreed ABE (or at least the idea of ABE if not the exact term) was the long term solution for many of our problems. We are hoping that a Firefox implementation will catch on eventually lead to standardization. However, for it to become a standard we need a well-thought out, defensible set of ideas.
I encourage everyone on the list to look at the idea of ABE and provide not only input on the syntax, but on the rules and types of rules you'd like to see. 
I will give this proper time on the flight back from Portugal and provide my input.


From: owasp-intrinsic-security-bounces at lists.owasp.org on behalf of Giorgio Maone
Sent: Tue 11/4/2008 10:47 AM
To: owasp-intrinsic-security at lists.owasp.org
Subject: [owasp-intrinsic-security] Application Boundaries Enforcer (ABE) -Call for Input

Hello everybody,

as I announced some time ago, I'm starting this NoScript sub-project, using the existent NoScript's request interception/blocking infrastructure to build a sort of in-browser web firewall to define and enforce web application boundaries.

I would appreciate some input from this group regarding the general concept and the syntax of the rules.

This is a draft description of the ABE concept:

The NoScript browser extension is meant to increase 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 first and still most effective Cross-Site Scripting (XSS) filters <http://noscript.net/features#xss>  available on the client side, covering Type-0 and Type-1 XSS attacks; ClearClick <http://noscript.net/faq#clearclick>  - the one and only specific protection currently available against ClickJacking/UI redressing <http://hackademix.net/2008/10/08/hello-clearclick-goodbye-clickjacking/>  attacks - and many other security enhancements, including a limited form of protection against Cross-Site Request Forgery <http://en.wikipedia.org/wiki/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 planned 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. her webmail, her online banking and so on), according to policies defined either by the user herself, or by the web developer/administrator, or by a trusted 3rd party.

ABE will be configurable through simple rules like the following:

# General Syntax:
# Destination Resource
# Action1 Predicate1, Predicate2, ... [from Resource1, Resource2, ...]
# Action2 Predicate3, Predicate4, ... [from Resource1, Resource2, ...]
# Omitting the "from" clause implies "from ALL"
# Tokens:
# 1. Action (applied in thi:
#    Deny   - blocks the request, possibly giving feedback if top-level
#    Logout - strips Authorization and Cookie headers from request
#    Accept - lets the request pass as it is
# 2. Predicate (of requests to be denied/logged out/accepted):
#    GET, POST, HEAD... - HTTP methods
#    SUB                - subdocument inclusion
#    ALL                - wildcard for all the "predicates"
# 3. Resource (origin or of requests to be denied/logged out/accepted):
#     ALL                           - Any resource
#    ^https?://some\.site\.com\/.* - regular expression
#    *.some.site.com <http://some.site.com/>                - glob expression
#    www.some.site.com <http://www.some.site.com/>              - domain literal
#    LOCAL                           - configurable local network
#    SELF                           - strict domain match   
# Examples:
# 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)
Destination *.somesite.com <http://somesite.com/> 
Deny ALL
Accept GET from ALL
Accept POST, SUBDOC from SELF, https://secure.somesite.com <https://secure.somesite.com/> 

# This one guards logout, which is foolish enough to accept GET and
# therefore we need to guard against trivial CSRF (e.g. <img>)
Destination www.somesite.com/logout
Deny ALL
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
Destination LOCAL
Deny ALL
Accept ALL from LOCAL

# This one strips off any authentication data
# (Auth and Cookie headers) from requests outside the
# application domains, like RequestRodeo

Destination *.webapp.net <http://webapp.net/> 
Logout ALL
Accept ALL from *.webapp.net <http://webapp.net/> 

An in-browser component like ABE enjoys an advantaged position for enforcing web application boundaries, because it always knowns the real origin of each HTTP request, rather than a possibly missing or forged (even for privacy reasons) HTTP referrer header, and can learn from user's feedback. 

Rules for the most popular web application 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 an auto-learning process. 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. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-intrinsic-security/attachments/20081104/9898d94c/attachment.html 

More information about the owasp-intrinsic-security mailing list