arkenfox / user.js

Firefox privacy, security and anti-tracking: a comprehensive user.js template for configuration and hardening
MIT License
10.28k stars 519 forks source link

Q: What does NS have (or will have) that uBo+uM don't #319

Closed Thorin-Oakenpants closed 6 years ago

Thorin-Oakenpants commented 6 years ago

Question: I still do not fully understand what NS offers that uBo+uM don't.

People have suggested (eg reddit, and here) that you can use NS in global allow mode but leave those four items above as active. Personally I never got an XSS warning from NS (maybe one a year), and the new WebExt version (not sure where they are at) I do not really want to touch with a barge pole (yet, if ever)

Aren't these things in uBo/uM - if not, why not?

@gorhill @Atavic excuse my ignorance, ELI5

Atavic commented 6 years ago

uMatrix - NoScript Related: https://github.com/gorhill/uMatrix/issues/297 NoScript info in italian.

Thorin-Oakenpants commented 6 years ago

XSS

To answer earthlng's q in the other thread - https://noscript.net/features#xss & also https://noscript.net/faq#qa4_1 . This is obviously the legacy version. I tend to just use XSS as a term to cover all third party scripts and I control it by default denying 3rd parties in uBo etc, and with uM.

In all my years of NS (which always got the requests first before uBo etc), I have only ever had a couple of warnings for this XSS

ClearClicking

https://noscript.net/faq#qa7_1

ABE

https://noscript.net/faq#qa8_1

Thorin-Oakenpants commented 6 years ago

A lot of this info is old. AFAIK clickjacking is nigh impossible now?

claustromaniac commented 6 years ago

I think you don't have to worry much about clickjacking if you deny third-party frames (and/or javascript, of course).

EDIT: IIRC it was also tackled at browser-level at some point. Now I just have to remember where I read that...

EDIT 2: Well, yes and no. What I read was about the X-Frame-Options HTTP header which has been around for about 8 years (according to Wikipedia). Firefox did adopt this header, but it's only a server-side solution.

Thorin-Oakenpants commented 6 years ago

EDIT: IIRC it was also tackled at browser-level at some point

Yeah, I remember reading a couple of bugzillas that covered this. As for denying 3rd party iframes - that's just the first level of defence .. some sites you may need to allow those which means you are at risk (you cannot trust any site is my motto - its not IF but WHEN they get hacked)

theWalkingDuck commented 6 years ago

Sorry, I haven't used Noscript for a long time but are there any Noscripts ABE rules which can not be handled using uMatrix ?

for example the following is the default, may be the only and mostly used, ABE rule in Noscript.

# Noscript
# Prevent Internet sites from requesting LAN resources.

Site LOCAL
Accept from LOCAL
Deny

We can rewrite it easily in the uMatrix way:

[Source]              * -> any external resource 
[Destination] 127.0.0.1 -> which tries to access the localhost or local resources
[Content]             * -> whatever the request or the requested content is ..
[action]          block -> should be BLOCKED
# uMatrix
# Prevent Internet sites from requesting LAN resources.

* 127.0.0.1 * block
* localhost * block    
* [::1]     * block       // block access to ipv6 localhost
* 192.168   * block       // block access to LAN 192.168.x.x

The best practice is to use a separate browser for accessing local resources or using a temporary allow if needed ... but for those who need it permanently

# uMatrix
# Accept from LOCAL

127.0.0.1 127.0.0.1 * allow
localhost localhost * allow
[::1]     [::1]     * allow
192.168   192.168   * allow

btw, don't forget to remove the matrix-off: localhost true rule.

gorhill commented 6 years ago

don't forget to remove the matrix-off: localhost true rule

I have no idea why I added this built-in rule. I will remove it.

Atavic commented 6 years ago

Look for types of XSS here. OWASP has many info about it, mainly server-side. Look at this PDF on page 24 for info about ABE Rules.

Atavic commented 6 years ago

Also here for OWASP info.

Thorin-Oakenpants commented 6 years ago

56743 .. warning! 17 years old :grin: - bit of a moot ticket for uM users => * * frame block

Thorin-Oakenpants commented 6 years ago

OK, this is good: http://vojtechruzicka.com/preventing-clickjacking/

claustromaniac commented 6 years ago

@Thorin-Oakenpants very nice, thanks!

Thorin-Oakenpants commented 6 years ago

FYI: what does uM have that NS doesn't? rhetorical question

add ability to block web workers on a per-site basis

Thorin-Oakenpants commented 6 years ago

FYI: note, I can't link to the individual review/reply (its on AMO's NS reviews page), so here's a cropped screenie

screenie

HOWEVER, if you're after security, you cannot rely on uMatrix over NoScript. For instance, even if you're blocking scripts with uMatrix on a site you don't trust, it can execute JavaScript by exploiting cross-site request vulnerabilities on a site you trust. This is prevented by NoScript's anti-XSS filter.

I still fail to see what NS's so called anti-XSS offers that uMatrix (with all 3p blocked by default) doesn't. It is some special XSS type attack detection to block sh*t even when you allow it by default (I have no idea what NS's defaults are, but I would assume little breakage and not in a hard mode)

gorhill commented 6 years ago

I believe the scenario he has in mind is:

  1. site X is suffering from an XSS vulnerability
  2. victim allows script execution on site X
  3. an attacker knows about this vulnerability
  4. attacker controls site Y
  5. victim visits site Y
  6. attacker sends victim to vulnerable site X along with a malicious js payload which will be injected somehow by triggering the vulnerability
  7. malicious javascript payload can then observe all what victim does on site X, including stealing victim's credentials if any

(in step 5-6, the victim could be simply given a specially crafted URL by the attacker, or by an innocent intermediate -- see https://excess-xss.com/).

So the way I understand, this requires to examine 3rd-party POST requests for main document (like when submitting a form).

I have collated cases regarding how blindly allowing 3rd-party frames is a security issue: https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-Benefits-of-blocking-3rd-party-iframe-tags#malware-protection. By no mean complete, these are just all cases for which I confirmed blocking 3rd-party frames would have foiled the attack (there is a case in there I emailed the author to confirm whether the attack was iframe-based, this was not clear from the article). There are more cases reported in the media I left out which required that 3rd-party scripts be blocked (that wasn't the topic of the wiki page).

The fact that he describes the blocking of 3rd-party scripts/frames as "disabl[ing] annoying stuff" means he is trying to belittle uMatrix -- there is no way to sensibly describe malvertising as "annoying" -- I don't think he is helping himself by describing the real actual ongoing threat of malvertising (again see list of actual cases above) as merely "annoying".

Now what I long for is such a list of real, actual documented cases where specifically only NoScript's XSS would have protected its users. Whatever threat someone wants to be protected against, an important factor is for users to be able to assess the likelihood of it happening. Surely such a list of actual, real documented cases would be the best way to convince users of how the importance of the feature relative to other threats (3rd-party frames, scripts, etc.)

On my side, I will read more about all this and see what could be sensibly added to uMatrix.

Atavic commented 6 years ago

:+1: Malvertising could be more appropriate.

An example of such "annoying stuff" could be file-hosting sites like that old one, rapidshare.

Thorin-Oakenpants commented 6 years ago

From this thread: https://www.ghacks.net/2017/12/30/noscript-webextension-update-improves-user-interface/#comment-4325925

surrogate scripts ...

Essentially mirroring a library, or a modified version of a given library (e.g. mootools, or jquery). uBlock used to have this.

Decentraleyes does this, but that still doesn't stop the JS from executing


Now what I long for is such a list of real, actual documented cases where specifically only NoScript's XSS would have protected its users

As per Atavic's link, the last couple of comments from @berrythesoftwarecodeprogrammar (they're at the end) - https://github.com/gorhill/uMatrix/issues/297

The two XSS examples are hopefully still up and running, and maybe someone can work out what they are doing that NS picks up on and blocks

overdodactyl commented 6 years ago

Essentially mirroring a library, or a modified version of a given library (e.g. mootools, or jquery).

Decentraleyes does this, but that still doesn't stop the JS from executing

For what it's worth, Decentreleyes does have the option to block scripts when the necessary CDN resource aren't available.

Ultimately, you can make Decentraleyes block requests for any missing CDN resources, too. GitHub page

In settings, there's the option to "Block requests for missing resources - Cancel intercepted request if the required resource is not locally available."

uBlock used to have this.

As far as I'm aware, uBO still uses some local, neutered versions of some commons scripts, doesn't it?

gorhill commented 6 years ago

uBO used to have an experimental feature called "local mirroring" a long time ago. In the end I canned it, this is best left to a dedicated extension.

The current neutered scripts feature is really just scriplets served through redirection to local data: URIs, and it apply only to blocked requests, never to non-blocked requests.

overdodactyl commented 6 years ago

Thanks for the clarification @gorhill! I wasn't aware of the local mirroring feature

If you don't mind the follow up question, do you use Decentraleyes + uBO via the method mentioned on the Decentraleyes wiki page then? (set up noop rules, then enable the block requests for missing resources option)

Thorin-Oakenpants commented 6 years ago

Decentraleyes does this, but that still doesn't stop the JS from executing

Sorry, by that I meant if the user lets it thru

Atavic commented 6 years ago

The XSS tests are gone.

gorhill commented 6 years ago

do you use Decentraleyes + uBO via the method mentioned on the Decentraleyes wiki page then?

I currently use uMatrix and Decentraleyes, no other extension. I didn't read the wiki, I understand how it works. Personally I do not unblock any specific domain except to unbreak sites, and in that case I am happy whenever Decentraleyes catches something.

overdodactyl commented 6 years ago

Makes sense, thanks for the help!

I currently use uMatrix and Decentraleyes, no other extension

Was that a recent switch? I thought I had seen you mention only using uBO in the past

gorhill commented 6 years ago

Was that a recent switch?

I switched when I started to work more on it lately -- it helps to use what you work on to see what needs most attention. It has its advantages, like the quick overview of what goes on in a web page, the lower overhead. The overhead can be lowered in uBO too though when disabling generic cosmetic filtering. For now I am in my uMatrix phase.

overdodactyl commented 6 years ago

Good to know, thanks!

I haven't used uMatrix in a while, but I might have to venture back and give that a try for a little while

Thorin-Oakenpants commented 6 years ago

I'll just throw this in here: https://www.schneier.com/blog/archives/2018/01/detecting_adblo.html - I haven't read the paper or even found out what this adblocker ext in chrome is yet. The numbers are interesting - 30% of top 10K alexa sites use anti-adblocking (and of these 90% have no visible reactions to adblockers). These are staggering numbers - 30% .. holy cow

Edit: https://arstechnica.com/science/2018/01/academic-researchers-fire-latest-shots-in-ad-blocking-arms-race/ < more detailed

An alternative approach they tried was somewhat more precise. Since they could identify the condition that was being tested for, they could modify the variables used by the site so that the condition would always evaluate as if an adblocker was not present. This only requires a browser extension. And, in the 15 websites it was tested on, it worked every time. (emphasis mine)

Worked every time! Cool. But I don't even want to connect to these 3rd party scripts. I'm intirgued but default-deny is working well for me. I never see an anti-adblcoker message TBH

ghost commented 6 years ago

So what is the final answer - is there any additional benefit in using NS when one uses uMatrix or not?

Atavic commented 6 years ago

You can use both.

ghost commented 6 years ago

I know I can. The question is what benefit adds NS if I have uMatrix where I have disabled scripts (and where I can enable them selectively).

Thorin-Oakenpants commented 6 years ago

I'm still working on it :)

I haven't looked at the ABE stuff, and even the XSS claims are elusive to prove

AFAICT, if you're a savvy internet user, I doubt it offers anything except possible conflicts and overhead. My gut feeling is that any reward would be outweighed by this. Assumption: users would need to be using uM (& uBO) in some hardened config

ghost commented 6 years ago

Yes, I was asking with that assumption :)

My gut feeling is that because Firefox has no way to enable/disable JS per website (like Chromium) uBO and uM should be a mandatory part of it. Perhaps even the Tor project should adopt these 2 instead of NS.

Thorin-Oakenpants commented 6 years ago

I do not know why TBB (Tor is something else) used NS. The legacy extension didn't have (and still doesn't) anything near the ease of use, and granular control of uBO / uM. Not to mention the ability to block types of elements (images/css/xhr/large media, cookies, etc). NS-legacy is effectively just concerned with JS. I say "ease" because NS could allow per site granular control (but not via a simple effective grid).

The new NS (i.e Web Extension) I haven't followed too closely cuz reasons - it has I believe morphed into doing that (per domain control) by re-inventing what uM/uBO always had. I guess like any new interface and new features, it will take time to mature (lets face it, the first offering was a really shitty beta) and for users to come to grips with it's UI etc. And lets not forget that Mozilla has bent over backwards for NS, and it's still not ready(? wasn't a month ago). I wonder how the TBB guys feel about it - however, I feel that TBB will not introduce change for change's sake (let's just assume that both extensions do the job required), but that if they were, then NOW would be the time to do it .. i.e ESR60.. because NS-legacy->NS-webext is a massive change anyway. Any argument over confusing users if no argument.

At the VERY least, TBB should include uBO just for the adblocking, IMO.

ghost commented 6 years ago

I agree with everything you say.

Perhaps the only objection which TBB authors may have against uBO/uM is the 3rd party lists which require connections to specific hosts and that itself may create a traceable browsing pattern. Of course a user who is aware of that could probably turn off automatic list updates and update them manually in a dedicated TBB identity, then restart and continue browsing with another identity.

I am further questioning even the benefit of using HTTPS Everywhere. Apart from its function to block all unencrypted requests it seems uM with its forbidding of mixed content already does the rest. But of course that is not directly related to the topic of this issue.

Thorin-Oakenpants commented 6 years ago

connections to specific hosts

I didn't think of that. Imagine a Polish person subscribing to polish lists.

the benefit of using HTTPS Everywhere

The uptake of HTTPS is escalating (whether that be the number of sites eg in the top100000000 or the % of traffic which is easier to influence given the big players). The beauty of HTTPS-E is that it allows complex rules, rather than say an extension which simply tries HTTP->HTTPS.

It does no harm to keep it for another year or so. I dug out some FF telemetry figures a short while ago - I think from memory that a year ago it was 30-40% and now its 60-70% (whatever the metric was), and as I said its escalating. Both google + mozilla are waging a war against non-secure, and then there's EFF's Lets Encrypt. Just give it a little longer :)

ghost commented 6 years ago

Both google + mozilla are waging a war against non-secure

The wolf is guarding the sheep :)

Thorin-Oakenpants commented 6 years ago

related post & subsequent replies: Wilders

earthlng commented 6 years ago

new wiki page for uMatrix based on the comment by @theWalkingDuck. Thanks @theWalkingDuck

crssi commented 6 years ago

^^ Cool. Note that localhost is not only 127.0.0.1, but 127.0.0.1/8, so anything from 127.0.0.0 to 127.255.255.255.

Saying that might be more trough if * 127.0.0.1 * block would be * 127 * block and if 127.0.0.1 127.0.0.1 * allow would be 127 127 * allow

EDIT: 127.0.0.0/24 is wrong, 127.0.0.0/8 is correct

ghost commented 6 years ago

I use a custom TLD for my locally developed sites and I have been trying to figure how to block requests to that particular TLD but a rule like * customtld * block seems to have no effect when testing with some.customtld.

ghost commented 6 years ago

Testing also with * myrouter * block and then visiting https://myrouter - the request is not blocked.

crssi commented 6 years ago

^^@anchev because you have 1st party allowed.

crssi commented 6 years ago

@ anyone What puzzles me is, if some JS on a page I am visiting starts XHR to LAN: what is the source? The visited page/server or my browser/computer?

ghost commented 6 years ago

^^@anchev because you have 1st party allowed.

Even if I remove the lines:

* 1st-party * allow
* 1st-party frame allow

I can still access https://myrouter. How come?

The visited page/server or my browser/computer?

https://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#origin-and-base-url

gorhill commented 6 years ago

@anchev I can't reproduce your issue. When I remove * 1st-party * allow, my access to the router is wholly blocked with * 192.168 * block.

earthlng commented 6 years ago

Note that localhost is not only 127.0.0.1, but 127.0.0.1/24, so anything from 127.0.0.1 to 127.0.0.255.

thanks @crssi. https://en.wikipedia.org/wiki/Localhost says:

IPv4 network standards reserve the entire 127.0.0.0/8 address block for loopback purposes. That means any packet sent to any of those addresses (127.0.0.1 through 127.255.255.255) is looped back.

so I changed it to * 127 * block

crssi commented 6 years ago

@earthlng yes, I have seen mistake (too early in the morning) and corrected the original post, just minutes before your post ;)

but if you would really like completeness, here it is:

localhost
0
10
100.100
100.101
100.102
100.103
100.104
100.105
100.106
100.107
100.108
100.109
100.110
100.111
100.112
100.113
100.114
100.115
100.116
100.117
100.118
100.119
100.120
100.121
100.122
100.123
100.124
100.125
100.126
100.127
100.64
100.65
100.66
100.67
100.68
100.69
100.70
100.71
100.72
100.73
100.74
100.75
100.76
100.77
100.78
100.79
100.80
100.81
100.82
100.83
100.84
100.85
100.86
100.87
100.88
100.89
100.90
100.91
100.92
100.93
100.94
100.95
100.96
100.97
100.98
100.99
127
169.254
172.16
172.17
172.18
172.19
172.20
172.21
172.22
172.23
172.24
172.25
172.26
172.27
172.28
172.29
172.30
172.31
192.0.0
192.168
198.18
198.19
255.255.255.255
[::1]
[fc00::]
[fd00::]
[fe80::]
[fe80::1%lo0]
[ff02::1]
[ff02::2]

With this you will completely cover home and enterprise users. ;)

But IPv6 range is very big, from fc00:: to fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff. I don't believe anyone would even try to do a "scan" over that range.

I am using those in uM:

[::1] [::1] * allow
[fc00::] [fc00::] * allow
[fd00::] [fd00::] * allow
[fe80::] [fe80::] * allow
[fe80::1%lo0] [fe80::1%lo0] * allow
[ff02::1] [ff02::1] * allow
[ff02::2] [ff02::2] * allow
* [::1] * block
* [fc00::] * block
* [fd00::] * block
* [fe80::] * block
* [fe80::1%lo0] * block
* [ff02::1] * block
* [ff02::2] * block
* 0 * block
* 10 * block
* 100.100 * block
* 100.101 * block
* 100.102 * block
* 100.103 * block
* 100.104 * block
* 100.105 * block
* 100.106 * block
* 100.107 * block
* 100.108 * block
* 100.109 * block
* 100.110 * block
* 100.111 * block
* 100.112 * block
* 100.113 * block
* 100.114 * block
* 100.115 * block
* 100.116 * block
* 100.117 * block
* 100.118 * block
* 100.119 * block
* 100.120 * block
* 100.121 * block
* 100.122 * block
* 100.123 * block
* 100.124 * block
* 100.125 * block
* 100.126 * block
* 100.127 * block
* 100.64 * block
* 100.65 * block
* 100.66 * block
* 100.67 * block
* 100.68 * block
* 100.69 * block
* 100.70 * block
* 100.71 * block
* 100.72 * block
* 100.73 * block
* 100.74 * block
* 100.75 * block
* 100.76 * block
* 100.77 * block
* 100.78 * block
* 100.79 * block
* 100.80 * block
* 100.81 * block
* 100.82 * block
* 100.83 * block
* 100.84 * block
* 100.85 * block
* 100.86 * block
* 100.87 * block
* 100.88 * block
* 100.89 * block
* 100.90 * block
* 100.91 * block
* 100.92 * block
* 100.93 * block
* 100.94 * block
* 100.95 * block
* 100.96 * block
* 100.97 * block
* 100.98 * block
* 100.99 * block
* 127 * block
* 169.254 * block
* 172.16 * block
* 172.17 * block
* 172.18 * block
* 172.19 * block
* 172.20 * block
* 172.21 * block
* 172.22 * block
* 172.23 * block
* 172.24 * block
* 172.25 * block
* 172.26 * block
* 172.27 * block
* 172.28 * block
* 172.29 * block
* 172.30 * block
* 172.31 * block
* 192.0.0 * block
* 192.168 * block
* 198.18 * block
* 198.19 * block
* 255.255.255.255 * block
* localhost * block
10 10 * allow
100.100 100.100 * allow
100.101 100.101 * allow
100.102 100.102 * allow
100.103 100.103 * allow
100.104 100.104 * allow
100.105 100.105 * allow
100.106 100.106 * allow
100.107 100.107 * allow
100.108 100.108 * allow
100.109 100.109 * allow
100.110 100.110 * allow
100.111 100.111 * allow
100.112 100.112 * allow
100.113 100.113 * allow
100.114 100.114 * allow
100.115 100.115 * allow
100.116 100.116 * allow
100.117 100.117 * allow
100.118 100.118 * allow
100.119 100.119 * allow
100.120 100.120 * allow
100.121 100.121 * allow
100.122 100.122 * allow
100.123 100.123 * allow
100.124 100.124 * allow
100.125 100.125 * allow
100.126 100.126 * allow
100.127 100.127 * allow
100.64 100.64 * allow
100.65 100.65 * allow
100.66 100.66 * allow
100.67 100.67 * allow
100.68 100.68 * allow
100.69 100.69 * allow
100.70 100.70 * allow
100.71 100.71 * allow
100.72 100.72 * allow
100.73 100.73 * allow
100.74 100.74 * allow
100.75 100.75 * allow
100.76 100.76 * allow
100.77 100.77 * allow
100.78 100.78 * allow
100.79 100.79 * allow
100.80 100.80 * allow
100.81 100.81 * allow
100.82 100.82 * allow
100.83 100.83 * allow
100.84 100.84 * allow
100.85 100.85 * allow
100.86 100.86 * allow
100.87 100.87 * allow
100.88 100.88 * allow
100.89 100.89 * allow
100.90 100.90 * allow
100.91 100.91 * allow
100.92 100.92 * allow
100.93 100.93 * allow
100.94 100.94 * allow
100.95 100.95 * allow
100.96 100.96 * allow
100.97 100.97 * allow
100.98 100.98 * allow
100.99 100.99 * allow
127 127 * allow
169.254 169.254 * allow
172.16 172.16 * allow
172.17 172.17 * allow
172.18 172.18 * allow
172.19 172.19 * allow
172.20 172.20 * allow
172.21 172.21 * allow
172.22 172.22 * allow
172.23 172.23 * allow
172.24 172.24 * allow
172.25 172.25 * allow
172.26 172.26 * allow
172.27 172.27 * allow
172.28 172.28 * allow
172.29 172.29 * allow
172.30 172.30 * allow
172.31 172.31 * allow
192.0.0 192.0.0 * allow
192.168 192.168 * allow
198.18 198.18 * allow
198.19 198.19 * allow
localhost localhost * allow
ghost commented 6 years ago

My bad. I had other rules which allowed resources from 'myrouter'. Everything works as expected.

ghost commented 6 years ago

@crssi - you should probably suggest to @gorhill to make it built in as a single click option for all local resources (IP4 and IP6) rather than adding it to a list manually.

ghost commented 6 years ago

I have been banned from my very first time I tried to submit an issue (still don't know why). It was years ago. But I registered other accounts and submitted issues :D

So we have an anti-ban strategy lol.