Making sure I understand...

Discussions about the Application Boundaries Enforcer (ABE) module
barbaz
Senior Member
Posts: 9268
Joined: Sat Aug 03, 2013 5:45 pm

Re: Making sure I understand...

Post by barbaz » Fri Jun 27, 2014 4:33 am

Sorry to jump in this discussion so late but a couple of (crazy?) thoughts:
1) What about using 'Target' as an alias for Site? How does that compare in terms of intuitiveness to 'Request'?

Code: Select all

Target .analytics-si.te
Accept from .friend1.com .friend2.com
Deny

Target .bank.com
Accept from SELF+
Deny

# backwards
Target .foo.net
Accept from .advertising-si.te
Deny

2) If "Request" is added as an alias for Site, could you please also allow it to be shortened to 'Req'?
*Always* check the changelogs BEFORE updating that important software!
Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 (PaleMoon)

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Making sure I understand...

Post by Thrawn » Fri Jun 27, 2014 10:22 am

barbaz wrote:1) What about using 'Target' as an alias for Site? How does that compare in terms of intuitiveness to 'Request'?

Well, it's probably similar, but IMHO, 'Request' has the advantage of actually describing what ABE is controlling: HTTP requests. And to say that you "request xxx" is valid grammar.

Any advantage of 'Target'?

2) If "Request" is added as an alias for Site, could you please also allow it to be shortened to 'Req'?

That's easy; it would be:

Code: Select all

grammar ABE;

options {
   language=JavaScript;
   output=AST;
}

tokens {
  T_ACTION;
  T_METHODS;
}

ruleset   : rule* EOF ;
rule      : subject predicate+ -> subject predicate+ ;
predicate : action methods? origin? -> T_ACTION action T_METHODS methods? origin? ;
methods   : (method+ | ALL) ;
method    : (HTTPVERB | SUB | inclusion) ;
inclusion : INC (LPAR (INC_TYPE COMMA)* INC_TYPE? RPAR)? ;
origin    : T_FROM oresources ;
subject   : T_SITE resources ;
oresources: (oresource+ | ALL) ;
resources : (resource+ | ALL) ;
oresource: resource | 'SELF' | 'SELF+' | 'SELF++' ;
resource  : REGEXP | GLOB | URI | LOCATION ;
action    : A_DENY | A_LOGOUT | A_SANDBOX  | A_ACCEPT ;

T_SITE    : 'Site' | 'Req' 'uest'? ;
T_FROM    : ('f' | 'F') 'rom' ;
A_DENY    : 'Deny' ;
A_LOGOUT  : 'Logout' | 'Anon' 'ymize'? ;
A_SANDBOX : 'Sandbox' ;
A_ACCEPT  : 'Accept' ;

fragment URI_START : 'a'..'z' | '0'..'9' ;
fragment URI_PART  : 'a'..'z' | 'A'..'Z' | '0'..'9' | '_' | '-' | '.' |
        '[' | ']' | ':' | '/' | '@' | '~' | ';' | ',' |
        '?' | '&' | '=' | '%' | '#' ;
LOCATION  : 'LOCAL' ;
URI       : URI_START URI_PART+ ;
GLOB      : (URI_START | '*' | '.') (URI_PART | '*')* ;
REGEXP    : '^' ~'\n'+ ;

ALL       : 'ALL' ;
SUB       : 'SUB' ;
INC       : 'INC' 'LUSION'? ;
INC_TYPE   : 'OTHER' | 'SCRIPT' | 'IMAGE' | 'CSS' | 'OBJ' | 'SUBDOC' | 'XBL' | 'PING' | 'XHR' | 'OBJSUB' | 'DTD' | 'FONT' | 'MEDIA' ;
HTTPVERB  : 'A'..'Z' 'A'..'Z'+ ;

COMMA     : ',' ;
LPAR      : '(' ;
RPAR      : ')' ;

WS        :  (' '|'\r'|'\t'|'\u000C'|'\n') {$channel=HIDDEN;} ;
COMMENT : '#' ~'\n'* {$channel=HIDDEN;} ;


By the way, logs in the Browser Console will still show 'Site' due to ABE.js line 735 (ABERule.prototype.toString). Which is probably fine; the same thing happens with 'Anon' and 'Logout' collapsing into 'Anonymize'.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0

barbaz
Senior Member
Posts: 9268
Joined: Sat Aug 03, 2013 5:45 pm

Re: Making sure I understand...

Post by barbaz » Fri Jun 27, 2014 3:49 pm

Thrawn wrote:Any advantage of 'Target'?

'Target' very clearly gives the sense of something that requests will be directed to; IOW, it's hard to take 'Target' as meaning request source. People throw things at a "real" target (the target doesn't throw things at people :shock: ), just like HTTP requests are being sent to, not from, the Site.
'Request' doesn't convey that quite as strongly.
Just IMO. YMMV.

Thrawn wrote:
2) If "Request" is added as an alias for Site, could you please also allow it to be shortened to 'Req'?

That's easy; it would be:
[...]

Thanks.
*Always* check the changelogs BEFORE updating that important software!
Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 (PaleMoon)

User avatar
Giorgio Maone
Site Admin
Posts: 8735
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Making sure I understand...

Post by Giorgio Maone » Fri Jun 27, 2014 4:17 pm

What about Destination (as opposite to "Origin" which is already a web security accepted term, and specifically related to the "From" clause)?
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0

barbaz
Senior Member
Posts: 9268
Joined: Sat Aug 03, 2013 5:45 pm

Re: Making sure I understand...

Post by barbaz » Fri Jun 27, 2014 4:35 pm

Giorgio Maone wrote:What about Destination (as opposite to "Origin" which is already a web security accepted term, and specifically related to the "From" clause)?

Yes, that too makes it hard to misunderstand & thus generate backwards ABE rules.
The main disadvantage of 'Destination' is as you said earlier it's really long. I suppose it could be (optionally) shortened to something like 'Dest'...
*Always* check the changelogs BEFORE updating that important software!
Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 (PaleMoon)

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Making sure I understand...

Post by Thrawn » Sat Jun 28, 2014 10:43 am

'Dest' 'ination'? sounds good to me :).
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (Symbian/3; Series60/5.3 NokiaN8-00/111.030.0609; Profile/MIDP-2.1 Configuration/CLDC-1.1 ) AppleWebKit/533.4 (KHTML, like Gecko) NokiaBrowser/7.4.2.6 Mobile Safari/533.4 3gpp-gba

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Making sure I understand...

Post by Thrawn » Mon Jun 30, 2014 12:51 am

The most important thing, it seems to me, is to get people out of the mindset of script-blocking, where you restrict the privileges of a potentially-hostile site, and get them into the ABE mindset, restricting access to a potentially-sensitive site.

Even 'Access' might be a suitable keyword.

Code: Select all

Access bank.com
Accept from trusted.net
Deny


Or 'Protect' - although that is really only descriptive when using ABE in its original fashion of CSRF protection. Still, maybe that would make people think.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0

barbaz
Senior Member
Posts: 9268
Joined: Sat Aug 03, 2013 5:45 pm

Re: Making sure I understand...

Post by barbaz » Tue Jul 01, 2014 3:51 am

Thrawn wrote:Or 'Protect' - although that is really only descriptive when using ABE in its original fashion of CSRF protection. Still, maybe that would make people think.

no, "Access" is better because that's *exactly* what ABE is guarding when it's used as an anti CSRF tool - IOW, ABE rules for anti CSRF are basically defining what is legitimate "access" to a sensitive site. "Protect" is not intuitive to me for any use case because you're not accepting/blocking protection from origin sites.

for comparison, correct and backwards ABE rules with Access instead of Site

Code: Select all

Access .analyticsdom.ain
Accept from .friendlysi.te
Deny

# backwards
Access .friendlysi.te
Accept from .analyticsdom.ain
Deny
*Always* check the changelogs BEFORE updating that important software!
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:30.0) Gecko/20100101 Firefox/30.0 SeaMonkey/2.27a2

forecehh
Posts: 18
Joined: Thu Jul 25, 2013 5:10 pm

Re: Making sure I understand...

Post by forecehh » Thu Jul 03, 2014 10:44 am

i dont read whole topic,just some last post
i would like to see rule like this more understanding to me

Code: Select all

at .analyticsdom.ain
Just Accept .friendlysi.te
Deny


or

Code: Select all

on .analyticsdom.ain
Just Accept .friendlysi.te
Deny
Mozilla/5.0 (Windows NT 6.3; rv:29.0) Gecko/20100101 Firefox/29.0

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Making sure I understand...

Post by Thrawn » Thu Jul 03, 2014 10:32 pm

Hmm. Syntax like that sounds (to me) very prone to the original problem of people reading it backwards...
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Making sure I understand...

Post by Thrawn » Tue Nov 10, 2015 1:31 am

Bump.

There have been several suggestions of aliases for 'Site' that may be more intuitive for newcomers to ABE. From what I've briefly tested, it would just be a tiny change to the grammar file and recompilation.

Personally I favor either 'Req(uest)' or 'Access'.
'Dest(ination)' could work too.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0

Phil

Re: Making sure I understand...

Post by Phil » Sat Nov 14, 2015 1:29 am

In short: My preferred option would be:

Code: Select all

Access to ajax.googleapis.com
Allow from mysite.com

In long...

I agree that the original "Site" is extremely prone to being misinterpreted.

I think "Request" is good, but I think "Request to" would be even better, as it provides an explicit "to" and "from" which really reinforces the direction:

Code: Select all

Request to ajax.googleapis.com
Allow from mysite.com

To elaborate: there's been a lot of talk about which terms best imply sending or receiving; but resorting to implication seems crazy when we can simply add the word "to" and make it explicit (as well as fitting perfectly with the "from" in the lines which follow).

"Access" also seems good. I can't quite decide if it's better than "Request" (the latter has the advantage of being an obvious keyword for people with technical knowledge, and slightly more specific in terms of what it really means). However I would again suggest that "Access to" is a considerable improvement upon just "Access", and in this form I think it's my preferred option:

Code: Select all

Access to ajax.googleapis.com
Allow from mysite.com

"Resource" was briefly debated, and I must agree with Thrawn who pointed out that this term is precisely what is used in the documentation!

A rule looks like this:

Site <resource>

A <resource> is typically an URI pattern (literal, glob or regexp) designing a request destination (site), or a wildcard token such as ALL or SELF.

If it's appropriate for the documentation, I can't understand why it wouldn't be considered for the rule syntax. (If it's not appropriate for the rules, the documentation should be changed.)

As such, "Resource" seems reasonable to me. It's probably not as good as "Request to" or "Access to"; however, if it were not possible to have the " to" suffix, I think "Resource" is perhaps on a par with "Request" and "Access" as a single-word option?

Code: Select all

Resource ajax.googleapis.com
Allow from mysite.com

I think that some of the other suggested aliases remain confusing and prone to misinterpretation by users who do not already understand that it is a request model.

In that context, I think "On" and "At" are exactly as ambiguous as "Site".

"Target" would be very nearly as ambiguous as "Site". People can just as easily think "This rule is targetting mysite.com" for the former, as they can think "This rule is for site mysite.com" for the latter.

I think "Destination" is simply confusing if you don't understand that you're referring to a Request. It's not an intuitive replacement at all. "Source" was also suggested. I think the fact that both "Source" and "Destination" have been proposed as labels for the same thing is indicative of just how confusing this can be, and why maximum clarity should be the goal. I therefore think neither "Source" nor "Destination" are good options.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0

Phil

Re: Making sure I understand...

Post by Phil » Sat Nov 14, 2015 1:38 am

Gah. My apologies for the "Allow" / "Accept" problem in my previous post. I keep doing that, and I can't edit the post to fix it.

Changing it to "Accept" does make me question my preferred option, though. We "allow access" but we "accept requests", so with that in mind I think I actually prefer:

Code: Select all

Request to ajax.googleapis.com
Accept from mysite.com
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0

Phil

Re: Making sure I understand...

Post by Phil » Sat Nov 14, 2015 1:54 am

One more note: I did consider whether "Request for <resource>" was an even more readable variant of "Request to <resource>", but I concluded that it would introduce (once more) an ambiguity problem for the reader, because as an English phrase "Request for site.com" could be interpreted as "Request [i]on behalf of[i] site.com", whereas I believe that no such misinterpretation is possible with the "Request to" approach. I therefore think "Request to" is the most unambiguous option.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0

barbaz
Senior Member
Posts: 9268
Joined: Sat Aug 03, 2013 5:45 pm

Re: Making sure I understand...

Post by barbaz » Sat Nov 14, 2015 6:43 pm

@Phil: I like your idea but I think it maybe better for the keyword to be something like "RequestTo" (without a space).
And to reiterate, +1 because this one could still alias as "Req" to save advanced users a small amount of typing. :mrgreen:
*Always* check the changelogs BEFORE updating that important software!
-

Post Reply