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

Giorgio Maone giorgio.maone at gmail.com
Tue Nov 4 10:47:15 EST 2008

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
– and many other security enhancements, including a
*limited form of protection against Cross-Site Request
*: 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               - glob expression
#    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
Deny ALL
Accept GET from ALL
Accept POST, SUBDOC from SELF, 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
Logout ALL
Accept ALL from *.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-intrinsic-security/attachments/20081104/066b2b64/attachment-0001.html 

More information about the owasp-intrinsic-security mailing list