[owasp-intrinsic-security] Introducing ABE (with almostdefinitive syntax specs)

Giorgio Maone giorgio.maone at gmail.com
Sat Dec 20 13:03:00 EST 2008


Even when Origin gets widely adopted, ABE wouldn't be obsolete:

   1. Implementations seem oriented to send Origin for cross-site POST only,
   see https://bugzilla.mozilla.org/show_bug.cgi?id=446344
   2. ABE's "Sandbox" action can be reliably and conveniently enforced only
   by a client-side NoScript-like device
   3. As Arshan hinted, nobody vetoes reusing ABE's rules (partially, given
   the limitations above) in a server-only framework, rather than rewriting
   custom code over and over again.

--
Giorgio

On Sat, Dec 20, 2008 at 5:40 PM, Arshan Dabirsiaghi <
arshan.dabirsiaghi at aspectsecurity.com> wrote:

>   I'm pretty excited about this project. For the uninitiated, it's
> basically a way that you can, as a site owner, implement your own same
> origin policy regarding mixed content and entry points. There's still lots
> of work to be done though, and some of it will be annoying. We need
> rulepacks for Gmail, Facebook, and other very popular apps that gives us
> security, but doesn't prevent legitimate application content from working
> and doesn't prevent unusual-but-allowed user behavior like bookmarking and
> hotlinking from working.
>
> I've already heard feedback that the Origin header will allow the server to
> programatically enforce these rules. My answer to that is twofold; first is
> that we definitely need an interim solution as the Origin header won't be
> reliably present in 99% of users' browsers for 5 years at the minimum, and
> who knows what might happen between now and then - the browsers may still
> allow you to turn it off. I mean, realistically, an Origin header is still a
> leak of private data, even though the querystring data may not be exposed.
>
> The second is, even if we could magically turn on Origin everywhere, we
> would still need to develop the rule framework we see in ABE. Hopefully this
> will encourage security-aware application architects into making more
> consolidated, easy to describe apps.
>
> Maintaining the rulesets seems to be the hard part - without community
> support we'll never be able to keep up with the latest rules from all the
> popular Web 2.0 sites. This means Giorgio has to work extra hard on the
> auto-update and auto-learning process. It's conceivable that the rules could
> change every day. Do we deliver new updates every day?
>
> Arshan
>  ------------------------------
>  *From:* owasp-intrinsic-security-bounces at lists.owasp.org on behalf of
> Giorgio Maone
> *Sent:* Sat 12/20/2008 10:48 AM
> *To:* Bil Corry
> *Cc:* owasp-intrinsic-security at lists.owasp.org
> *Subject:* Re: [owasp-intrinsic-security] Introducing ABE (with
> almostdefinitive syntax specs)
>
> "Logout" is new, and so is "Sandbox" (i.e. allow only static HTML).
>
> Server-side 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 rule file itself containing just the
> "Location: URL" line as its own content). Redirections are allowed only
> towards the same domain or a subdomain, though.
> This can 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.
>
> >When there's a violation, will ABE prompt the user to give them an
> opportunity to allow the request temporarily or permanently?
> > I'm imagining a scenario >where a site originally didn't allow something,
> but a feature is added and now wants to allow it.
>
> Yes, and that's also how the "auto-learning" mode will work. You  (as an
> user) mark a certain site (e.g. https://mail.google.com) as a "web
> application", and this creates automatically a restrictive rule like:
>
> Site https://mail.google.com
> Allow from SELF
> Deny
>
> Then you can add exceptions on demand when something breaks.
> Of course if the site supports ABE on its own and you didn't set more
> restrictive custom rules for it (which would take priority), then site
> itself can tweak the rules according to its evolving needs, provided that
> rules are reloaded on each browser session. I'd also force a rule cache
> purge when user clears its browser cache or its cookies for that site, just
> to match the common expectation that clearing cookies and cache may fix a
> site broken by server-side changes.
>
> --
> Giorgio
>
>
>
> On Sat, Dec 20, 2008 at 2:57 PM, Bil Corry <bil at corry.biz> wrote:
>
>> Giorgio Maone wrote on 12/20/2008 5:02 AM:
>> > http://hackademix.net/2008/12/20/introducing-abe/
>> >
>> > Comments are welcome
>>
>> When there's a violation, will ABE prompt the user to give them an
>> opportunity to allow the request temporarily or permanently?  I'm imagining
>> a scenario where a site originally didn't allow something, but a feature is
>> added and now wants to allow it.  Everyone who has the older rules will now
>> hit a security violation, so to keep it as automatic as possible, either the
>> user would have to override the security error (which could be challenging
>> for the average user, do they allow a violation of security?  Or not?), or
>> the site would have to provide new rules and ABE would have to discover and
>> use the new rules.  Maybe ABE checks for new rules first before popping up
>> the security dialog box?  Just curious how you see that working.
>>
>> Thinking about the virus checking software on my laptop, what frustrates
>> me is something won't work and then I have to dig around inside its settings
>> to figure out how to allow it.  It's tempting at times to just turn it off
>> rather than spending the time to figure it out.  My concern for the average
>> ABE user is if sites do not work properly, and if there's an abundance of
>> security dialog boxes that they don't know the answer to, they may opt to
>> just turn it off.  But maybe your target audience isn't computer novices?
>>  If it is, then I think careful consideration is needed to make ABE as
>> helpful and useful to them as possible.  They will not understand
>> firewall-style rules :)
>>
>>
>> - Bil
>>
>> _______________________________________________
>> owasp-intrinsic-security mailing list
>> owasp-intrinsic-security at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-intrinsic-security
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-intrinsic-security/attachments/20081220/3ee338d8/attachment.html 


More information about the owasp-intrinsic-security mailing list