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

Bil Corry bil at corry.biz
Sat Dec 20 14:12:34 EST 2008


Arshan Dabirsiaghi wrote on 12/20/2008 10:40 AM: 
> 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.

And beyond Origin, there's also CSP (Content Security Policy) which Giorgio mentioned in an earlier thread:

	http://people.mozilla.org/~bsterne/content-security-policy/

If you have an interest, there's been some discussion about it on the mozilla.dev.security list:

	http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/b2525aac8bda30cd/fe91d742ab324499

The difference between CSP and ABE comes down mostly to a site-centric solution (CSP) versus a user-centric solution (ABE).  It'll be great once we have CSP, ABE and the Origin header implemented in browsers and websites.  The big challenge then will be education; we're still struggling to get sites to use the Secure and HTTPOnly flags on cookies...


> 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?

For sites that provide their own ruleset, then it sounds like the changes will be picked up on the next session (or the user can clear their cache and get them immediately).

For sites that don't provide their own ruleset, then regardless if you create your own (manually or learned) or import a community-provided one, if it breaks something (triggers ABE), then ABE will have to prompt the user to allow/deny an exception, and offer to "learn" to it permanently.

This is where it becomes tricky.  Say the user doesn't allow an action, makes their choice permanent, but then later wants to allow it.  The average user is probably not going to be savvy enough to edit the raw rules; having a GUI/Wizard that helps fix that issue is important.  Something like "show me all the rules for this site" then be able to add/modify/delete them using a GUI.

Even trickier, precedence of rules.  From the spec, it sounds like the most restrictive rules are in effect.  So if the user has some rules and the server has some rules, then ABE must blend them together, always choosing the most restrictive of them.  Now add in a community set also.  Is it a separate set, so now ABE has to blend from three sources?  Or upon importing the community set of the rules, does ABE do a one-time blend with the user rules and store that?  I'm thinking of a scenario where the user allows something, but the community rules do not, and since the community rules are more restrictive, they win.  The user might be unhappy that suddenly the community rules have "broken" the site in question.  Or perhaps on import, ABE asks the user to resolve conflicts.



- Bil



More information about the owasp-intrinsic-security mailing list