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

Giorgio Maone giorgio.maone at gmail.com
Sat Dec 20 10:48:44 EST 2008


"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/7a388b82/attachment.html 


More information about the owasp-intrinsic-security mailing list