Closed Thorin-Oakenpants closed 6 years ago
uMatrix - NoScript Related: https://github.com/gorhill/uMatrix/issues/297 NoScript info in italian.
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
https://noscript.net/faq#qa7_1
A lot of this info is old. AFAIK clickjacking is nigh impossible now?
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.
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)
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.
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.
56743 .. warning! 17 years old :grin: - bit of a moot ticket for uM users => * * frame block
OK, this is good: http://vojtechruzicka.com/preventing-clickjacking/
@Thorin-Oakenpants very nice, thanks!
FYI: what does uM have that NS doesn't? rhetorical question
add ability to block web workers on a per-site basis
FYI: note, I can't link to the individual review/reply (its on AMO's NS reviews page), so here's a cropped 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)
I believe the scenario he has in mind is:
(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.
:+1: Malvertising could be more appropriate.
An example of such "annoying stuff" could be file-hosting sites like that old one, rapidshare.
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
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?
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.
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)
Decentraleyes does this, but that still doesn't stop the JS from executing
Sorry, by that I meant if the user lets it thru
The XSS tests are gone.
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.
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
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.
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
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
So what is the final answer - is there any additional benefit in using NS when one uses uMatrix or not?
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).
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
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.
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.
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.
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 :)
Both google + mozilla are waging a war against non-secure
The wolf is guarding the sheep :)
related post & subsequent replies: Wilders
new wiki page for uMatrix based on the comment by @theWalkingDuck. Thanks @theWalkingDuck
^^ 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
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
.
Testing also with * myrouter * block
and then visiting https://myrouter - the request is not blocked.
^^@anchev because you have 1st party allowed.
@ 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?
^^@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
@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
.
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
@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
My bad. I had other rules which allowed resources from 'myrouter'. Everything works as expected.
@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.
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.
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