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

Giorgio Maone giorgio.maone at gmail.com
Sun Dec 21 08:34:56 EST 2008


Sorry for these forwards, I'm consistently having issues with "Reply" vs
"Reply all" because I'm not very familiar with GMail.

---------- Forwarded message ----------
From: Giorgio Maone <giorgio.maone at gmail.com>
Date: Sun, Dec 21, 2008 at 11:49 AM
Subject: Re: [owasp-intrinsic-security] Fwd: Introducing ABE (with
almostdefinitive syntax specs)
To: Bil Corry <bil at corry.biz>


I get your point.
Here I need to handle two opposite expectations: NoScript "power users"
generally expect to be safer *despite* the stupid things a website may do to
lower their security (this is a significant shift from the previously
accepted wisdom, about XSS for instance, i.e. if the website is buggy
there's nothing user can do). A website owner which deploys specific
countermeasures like ABE, on the other hand, may think in good faith that
his efforts are more than enough to ensure security and that he deserves
blind trust from his users.

Of course, for ABE being worth for both these actors, we should find a
middle ground.
An approach would be delaying conflict resolution to the first situation
where the outcome of an user rule is most restrictive than a newly
downloaded (not examined yet) site rule. At that point, ABE would tell user
something like

A SUBDOC request from http://xxx.yy is violating a rule of yours, but the
site http://somesite.com says it should be allowed.
[Show/Edit the conflicting rules...] [Keep enforcing my rule] [Prefer site's
rule]

This way user can see what's going on and choose to keep trusting his own
rule over site's (possibly tweaking it, if he's capable of) or to trust the
site because site developers know better.
--
Giorgio



On Sun, Dec 21, 2008 at 5:33 AM, Bil Corry <bil at corry.biz> wrote:

> 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?
>
> User
> --------------------
> Site *.somesite.com
> Accept POST from SELF
> Accept GET
> Deny
>
> Site
> --------------------
> Site *.somesite.com
> Accept POST, SUBDOC from SELF, https://secure.somesite.com
> Accept GET
> Deny
>
>
> 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
>
>
> _______________________________________________
> 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/20081221/0ead1667/attachment.html 


More information about the owasp-intrinsic-security mailing list