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

Arshan Dabirsiaghi arshan.dabirsiaghi at aspectsecurity.com
Sat Dec 20 11:40:04 EST 2008

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?


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 <https://mail.google.com/> ) as a "web application", and this creates automatically a restrictive rule like:

Site https://mail.google.com <https://mail.google.com/> 
Allow from SELF

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.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-intrinsic-security/attachments/20081220/1a5c1c39/attachment-0001.html 

More information about the owasp-intrinsic-security mailing list