"Save Link Target As" bypasses ABE

Bug reports and enhancement requests
Post Reply
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

"Save Link Target As" bypasses ABE

Post by barbaz »

If you right-click on a link to an address ABE is configured to Deny and select "Save Link Target As", the link target downloads anyway. This is not an issue with ABE rules because just following the link normally triggers ABE as expected.
Is this intentional?
*Always* check the changelogs BEFORE updating that important software!
Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20100101 Firefox/17.0
access2godzilla
Senior Member
Posts: 109
Joined: Sun May 20, 2012 5:09 pm

Re: "Save Link Target As" bypasses ABE

Post by access2godzilla »

ABE is meant to control requests on a particular webpage, so it is probably not meaningful to have ABE block the "Save link target as" action.
Are you trying to use it as some web page blocker?
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:25.0) Gecko/20100101 Firefox/25.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: "Save Link Target As" bypasses ABE

Post by barbaz »

I'm using the NAT Pinning Rule which is supposed to block *all* outbound HTTP traffic to certain ports.

Also, this means that ABE has no control over the Mozilla Archive Format add-on which I think uses this action internally.
*Always* check the changelogs BEFORE updating that important software!
Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20100101 Firefox/17.0
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: "Save Link Target As" bypasses ABE

Post by Thrawn »

Probably the request is being sent from chrome://, so it may or may not be subject to ABE. In this case, it looks like not.

It's normal for other addons to be able to bypass NoScript, since they have equal privileges.
======
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:26.0) Gecko/20100101 Firefox/26.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: "Save Link Target As" bypasses ABE

Post by barbaz »

Thrawn wrote:It's normal for other addons to be able to bypass NoScript, since they have equal privileges.
Really? SimpleBlock, which is basically just a http-on-modify-request observer, does *not* seem to be bypass-able short of editing the config...
It's not ideal to have to duplicate some of my ABE rules to another addon to get a proper sense of security.
*Always* check the changelogs BEFORE updating that important software!
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: "Save Link Target As" bypasses ABE

Post by Thrawn »

Well, requests from other addons *might* go through ABE, but since they have equal privileges, there are always ways that they can bypass it.

Perhaps SimpleBlock hooks into more places than ABE does, since ABE was only designed to defeat websites, not chrome code.

But technically I suppose someone might be fooled into launching a CSRF attack against themselves by using 'Save Target As' on a malicious link, so if Giorgio can see an easy way to handle this, it's probably worth doing.
======
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:26.0) Gecko/20100101 Firefox/26.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: "Save Link Target As" bypasses ABE

Post by barbaz »

Thrawn wrote:Well, requests from other addons *might* go through ABE, but since they have equal privileges, there are always ways that they can bypass it.
Yes but I'm assuming we're not dealing with malicious addons here.
Thrawn wrote:Perhaps SimpleBlock hooks into more places than ABE does, since ABE was only designed to defeat websites, not chrome code.
SimpleBlock doesn't do anything complicated ;)
It's just listening to all HTTP requests and indiscriminately aborting those whose URL matches any specified pattern.
Thrawn wrote:But technically I suppose someone might be fooled into launching a CSRF attack against themselves by using 'Save Target As' on a malicious link, so if Giorgio can see an easy way to handle this, it's probably worth doing.
Well, then it sounds like this is probably going to depend on how hard it is for Giorgio to make NoScript additionally listen on http-on-modify-request (or http-on-opening-request when available?).
And thinking about this more, it might be useful also to extend that ability to other features, such as plugin content blocking and XSS filter, so that "Save Link Target As" doesn't result in exploits bypassing NoScript and usage of addons like Mozilla Archive Format doesn't result in untrusted plugin content running on my local machine without my knowledge.
*Always* check the changelogs BEFORE updating that important software!
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23
User avatar
Giorgio Maone
Site Admin
Posts: 9454
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: "Save Link Target As" bypasses ABE

Post by Giorgio Maone »

barbaz wrote: Well, then it sounds like this is probably going to depend on how hard it is for Giorgio to make NoScript additionally listen on http-on-modify-request (or http-on-opening-request when available?).
It's not complicated, quite the opposite: NoScript listens for anything, but tries hard to filter out internal browser requests (such as update pings, RSS feeds retrievals and so on) in order not to break the browser. Internal browser requests are quite difficult to discriminate internally, and extension-generated requests are technically indistinguishable from internal browser requests.
In other words, it's not merely a technical issue, but a compromise between compatibility and security which assumes exploiting chrome-generated requests requires so much user interaction to be impractical if compared with much lower hanging fruits which NoScript guards against.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: "Save Link Target As" bypasses ABE

Post by Thrawn »

OK then.

I wonder whether it would be worth introducing a special keyword to tell ABE to filter even internal requests? Eg ALL with an exclamation mark:

Code: Select all

Site bank.com
Accept from SELF++
Deny from ALL!
Barbaz, if possible, would this interest you?
======
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:26.0) Gecko/20100101 Firefox/26.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: "Save Link Target As" bypasses ABE

Post by barbaz »

Giorgio Maone wrote:Internal browser requests are quite difficult to discriminate internally, and extension-generated requests are technically indistinguishable from internal browser requests.
Oh... I didn't realize that these requests weren't seen as originating from the webpage.
Thrawn wrote:OK then.

I wonder whether it would be worth introducing a special keyword to tell ABE to filter even internal requests? Eg ALL with an exclamation mark:

Code: Select all

Site bank.com
Accept from SELF++
Deny from ALL!
Barbaz, if possible, would this interest you?
Absolutely. I like this idea and would definitely use such a keyword. Would give a more fine-grained global control over HTTP requests, and maximize the effectiveness of stuff like the NAT Pinning Rule.
Could it be useful even for the builtin SYSTEM rule, or are these requests coming from LOCAL (meaning "chrome:" here?) anyway?
EDIT Stupid question, of course the requests are coming from LOCAL if they're indistinguishable from requests made by the browser. Never mind.
*Always* check the changelogs BEFORE updating that important software!
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: "Save Link Target As" bypasses ABE

Post by Thrawn »

barbaz wrote: Oh... I didn't realize that these requests weren't seen as originating from the webpage.
Yes, they originate from chrome:// URLs.
Could it be useful even for the builtin SYSTEM rule, or are these requests coming from LOCAL (meaning "chrome:" here?) anyway?
EDIT Stupid question, of course the requests are coming from LOCAL if they're indistinguishable from requests made by the browser. Never mind.
No, they're not coming from LOCAL. LOCAL means local addresses; http://192.168.0.1 etc. The internal chrome: protocol is something else entirely.

However, as mentioned above, attempting to block requests from chrome: is not reliable. It may be good as a nuisance blocker, or for getting an idea of what your browser is doing, but a malicious addon could get around it (eg by removing NoScript's hooks).
======
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:26.0) Gecko/20100101 Firefox/26.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: "Save Link Target As" bypasses ABE

Post by barbaz »

Just found
about:config -> noscript.ABE.skipBrowserRequests

Sounds related... What does that pref control?
*Always* check the changelogs BEFORE updating that important software!
Mozilla/5.0 (X11; Linux i686; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26a1
Post Reply