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

Bil Corry bil at corry.biz
Sat Dec 20 23:33:47 EST 2008

Giorgio Maone wrote on 12/20/2008 6:34 PM: 
> Precedence, as drafted in the spec, decreases from the top to the bottom,
> both inside each rule and in the ruleset as a whole. Whatever matches first
> wins, therefore the suggestion to put the most specific rules on the top
> (e.g. Allow from SELF),  to give them precedence, and most general rules
> (e.g. Deny ALL) on the bottom, to catch the remainders. The visual
> feedback-driven UI will always modify the topmost matching rule, if any, or
> will produce a topmost rule.
> Then, when rules from different sources are merged, they're structured this
> way:
>    1. User's custom rules, highest precedence.
>    2. Site-provided rules (those coming from the site which publish its own
>    property), middle precedence.
>    3. Community" rules (those downloaded from a centralized authority),
>    lowest precedence--

Just so I'm clear, how would these two rule sets be merged?

Site *.somesite.com
Accept POST from SELF
Accept GET

Site *.somesite.com
Accept POST, SUBDOC from SELF, https://secure.somesite.com
Accept GET

If I'm following you correctly, the user's more restrictive rules would take precedence and SUBDOC wouldn't be allowed, nor POST/SUBDOC from secure.somesite.com.  So the user would discover the issue when they do a POST from secure.somesite.com, as ABE would complain at that time.

I'm wondering if it would make sense to ask the user if they want to allow the more relaxed rules when first doing the merge.  Presumably the site will know best which rules are needed to protect their site yet allow it to function properly.

- Bil

More information about the owasp-intrinsic-security mailing list