Links to ABE-restricted sites are Filtered

[reggie14]

Sorry if my subject title isn't very accurate. I'm new to Noscript, and I'm still trying to get a handle on all the terms (plus I'm not completely sure how some of the features, like ABE, work).

I'm probably pushing my noscript settings to the completely paranoid range, but I've been using ABE a lot to try to block scripts so they can only run on the website they originated from. For example, I have an ABE rule saying:

Code: Select all

Site facebook.com *.facebook.com fbcdn.net *.fbcdn.net
Accept from facebook.com *.facebook.com
Deny

Maybe I'm completely off the mark, but my reason for doing this is so that some malicious website down the line doesn't figure out how to run some of facebook script that would, e.g., make everything on my Facebook account public. Maybe that shouldn't be a concern, and if that's the case I'd like to hear it, but I'm still a little confused about how ABE works, and I'd like to know why I'm running into the problem I'm having.

I've noticed that setting that ABE rule above has the nasty side effect of not being able to click on links to Facebook.com. For example, if I do a google search for facebook, and click on the result, I get the following error/filter message:

Code: Select all

[ABE] <facebook.com *.facebook.com fbcdn.net *.fbcdn.net> Deny on {GET http://www.facebook.com/ <<< http://www.google.com/search?q=facebook&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a, http://www.google.com/search?q=facebook&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a}
USER rule:
Site facebook.com *.facebook.com fbcdn.net *.fbcdn.net
Accept from facebook.com *.facebook.com
Deny

So, apparently ABE seems to be blocking any traffic to facebook unless it comes from facebook, and doesn't just block facebook scripts from running on other sites.

But, its pretty annoying to not be able to click on links to facebook. So I tried adding a universal "Accept Get" to my facebook rule, leaving me with:

Code: Select all

Site facebook.com *.facebook.com fbcdn.net *.fbcdn.net
Accept from facebook.com *.facebook.com
Accept Get
Deny

Now for better or worse I can click on links to Facebook from anywhere. But, have I watered-down the rule so that it doesn't even make sense anymore? I'm inclined to say yes, but maybe there's still some sort of benefit there.

[al_9x]

There is a SUB pseudo method to apply an action only to sub-requests, but it seems to affect only frame requests. Giorgio, is this by design? It would be useful to have something that applies to all sub-requests. Fx does differentiate root and sub requests for cookie 3rd partiness determination, a root request, replacing the document is treated as 1st party, whereas a sub request may be a 3rd party. So there should be enough information.

[Giorgio Maone]

There is a SUB pseudo method to apply an action only to sub-requests, but it seems to affect only frame requests. Giorgio, is this by design?

Yes it is, since ABE's design goal is preventing CSRF and therefore a difference between a top-level document load and a subrequest make not much sense (the SUB pseudo-method was included as an early anti-clickjacking measure, before X-Frame-Options and ClearClick).

So there should be enough information.

Yes there is. Maybe I could add an "INCLUSION[(type1[, type2, ...])]" pseudo method, which would allow rules like

Code: Select all

Site .facebook.com .fbcdnet
# notice the .domain.tld syntax above, a shortcut for *.domain.tld domain.tld courtesy of al_9x :)
Accept from .facebook.com
Deny INCLUSION

which are very weak for the anti-CSRF original use case, but serve the broader "web firewall" de-facto use case.

[al_9x]

Yes there is. Maybe I could add an "INCLUSION[(type1[, type2, ...])]" pseudo method

Are the types the way the resource is referenced (frame, img, object, script, css, ...)? or mime-types? or might both be useful?

Isn't SUB in a way, subset of INCLUSION? Perhaps a single more expressive SUB would work.

[Giorgio Maone]

Yes there is. Maybe I could add an "INCLUSION[(type1[, type2, ...])]" pseudo method

Are the types the way the resource is referenced (frame, img, object, script, css, ...)? or mime-types? or might both be useful?

mime-types are not feasible at the stage when ABE runs (i.e. before the request hits the network), because no "Content-type" response header has been received or even solicited yet.
The only implementable thing (by parasitizing the information obtained by content policy) is the way the request has been initiated (i.e. img, css, script, object, object subrequest, frame, XBL, XHR...).

Isn't SUB in a way, subset of INCLUSION?

Yes, currently it's like INCLUSION(frame, object)

Perhaps a single more expressive SUB would work.

I couldn't figure out how to handle backward compatibility, though.

[al_9x]

Got it. Should prove useful.

[al_9x]

Giorgio,

A while back I asked for an option to block 3rd party sub-requests to blacklisted domains. If you implement INCLUSION, ABE will be close to being able to express that. The only thing missing are resource tokens for builtin NoScript (pseudo)lists (Whitelisted, Blacklisted, Unlisted, and possibly custom lists). With those something like this would be possible:

Code: Select all

Site LIST(BLACKLIST)
Accept from SELF
Deny INCLUSION

another feature that might be useful, complement set operator (not) for resource tokens

Code: Select all

Site LIST(BLACKLIST)
Deny INCLUSION from NOT SELF

Code: Select all

Site NOT LIST(WHITELIST)
....

and another, SELF could use expansion to refer to 2nd level domains

Code: Select all

Site LIST(BLACKLIST)
Deny INCLUSION from NOT SELF(2ND_LEVEL_DOMAIN)

[Giorgio Maone]

A while back I asked for an option to block 3rd party sub-requests to blacklisted domains. If you implement INCLUSION, ABE will be close to being able to express that. The only thing missing are resource tokens for builtin NoScript (pseudo)lists (Whitelisted, Blacklisted, Unlisted, and possibly custom lists). With those something like this would be possible:

Code: Select all

Site LIST(BLACKLIST)
Accept from SELF
Deny INCLUSION

Maybe this could be expressed by "matcher references", which could be either set programmatically (by NoScript in our case), or assigned in a ruleset, like

Code: Select all

$MY_SITES=*.domain1.tld .domain2.tld
# $NOSCRIPT_TRUSTED and $NOSCRIPT_UNTRUSTED are programmatically injected by NoScript

Site $MY_SITES
Accept from $NOSCRIPT_TRUSTED
Deny

another feature that might be useful, complement set operator (not) for resource tokens

Code: Select all

Site LIST(BLACKLIST)
Deny INCLUSION from NOT SELF

Not sure, the rule above can be expressed as

Code: Select all

Site $NOSCRIPT_UNTRUSTED
Allow INCLUSION from SELF
Deny INCLUSION

and another, SELF could use expansion to refer to 2nd level domains

Code: Select all

Site LIST(BLACKLIST)
Deny INCLUSION from NOT SELF(2ND_LEVEL_DOMAIN)

Simpler, using a "+" suffix to mean domain+subdomains rather than prepath mathcing, and "++" to mean "2nd level domain and subdomains":

Code: Select all

Site $NOSCRIPT_UNTRUSTED
Allow INCLUSION from SELF++
Deny INCLUSION

[al_9x]

Maybe this could be expressed by "matcher references", which could be either set programmatically (by NoScript in our case), or assigned in a ruleset, like

Code: Select all

$MY_SITES=*.domain1.tld .domain2.tld
# $NOSCRIPT_TRUSTED and $NOSCRIPT_UNTRUSTED are programmatically injected by NoScript

Site $MY_SITES
Accept from $NOSCRIPT_TRUSTED
Deny

This seems to get the job done, but what about the "unknown" pseudo-list?

Not sure, the rule above can be expressed as

true,

Deny from NOT $set1
=
Accept from $set1
Deny

and

Site NOT $set1
Deny from $set2
=
Site $set1
Accept from $set2

Site ALL
Deny from $set2

so a complement operator is syntactic sugar, but especially in the second case seems useful

Simpler, using a "+" suffix to mean domain+subdomains rather than prepath mathcing, and "++" to mean "2nd level domain and subdomains":

yes, that's better

[Giorgio Maone]

INCLUSION(), SELF+ and SELF++ have been implemented in NoScript 1.9.9.77

[al_9x]

INCLUSION(), SELF+ and SELF++ have been implemented in NoScript 1.9.9.77

Tried

Code: Select all

Site .facebook.com .fbcdn.net
Accept from .facebook.com .fbcdn.net
Deny INC

seems to be working, but on imdb pages I am getting abe notification about facebook like iframes which are already blocked by NS (no facebook subrequests should be generated). This is new in .77, in .76 a similar rule (without the inc) was not triggered.

Are sets ("matcher references") still planed?

[al_9x]

am getting abe notification about facebook like iframes which are already blocked by NS (no facebook subrequests should be generated). This is new in .77, in .76 a similar rule (without the inc) was not triggered.

If you have trouble reproducing this (it doesn't seem to always happen), allow iframes, reload, you get a legitimate abe alert. Then block iframes, reload again and you should still get the alert.

[Giorgio Maone]

Then block iframes, reload again and you should still get the alert.

This may be a history/cache artifact. I.e. if a frame is already present in the page structure, when you reload it's not always treated as a frame request, but as a reload request from within the already present subdocument. Is this the only way to reproduce?

[al_9x]

Then block iframes, reload again and you should still get the alert.

This may be a history/cache artifact. I.e. if a frame is already present in the page structure, when you reload it's not always treated as a frame request, but as a reload request from within the already present subdocument. Is this the only way to reproduce?

If I clear cache (and everything) after blocking iframes, before the reload, still get the abe alert. After a browser restart it seems to be ok.

[al_9x]

I double checked and it's not new in .77, happens in .76 too. It's not a big problem since one doesn't generally toggle forbid iframes, so I am more curious than anything, why would it still happen after a cache clear, when about:cache reports no memory or disk entries.