The NoScript Misnomer(thehackerblog.com)
thehackerblog.com
The NoScript Misnomer
http://thehackerblog.com/the-noscript-misnomer-why-should-i-trust-vjs-zendcdn-net/
24 comments
I did the same, but with ublock origin in advanced mode and umatrix, which gives me even more control on what request goes where.
This is probably overkill for the average person, but after so many years of using noscript+requestpolicy I am used to sites being broken by default and having to fix them if needed, to me this is an acceptable tradeoff for the increased security.
The only exception to this rule for me is when I order something on a website, in that case I find it too risky to run with tight blocking (due to redirections to the payment site and so on) and just run a completely default firefox in its own vm that I snapshot before and revert to after.
This is probably overkill for the average person, but after so many years of using noscript+requestpolicy I am used to sites being broken by default and having to fix them if needed, to me this is an acceptable tradeoff for the increased security.
The only exception to this rule for me is when I order something on a website, in that case I find it too risky to run with tight blocking (due to redirections to the payment site and so on) and just run a completely default firefox in its own vm that I snapshot before and revert to after.
Why was this downvoted? I'm always interested in current perspectives on best practices in browser security. I don't know whether onosendai's description https://news.ycombinator.com/item?id=9795193 is correct, but, even if it isn't, a rebuttal would be more helpful (to me and to onosendai both) than a silent downvote.
NoScript's feature set goes way beyond just selectively blocking scripts based on domain, so nothing in the uBlock family is really a replacement for NoScript, just a replacement for NoScript's most basic feature.
> Regardless, I've replaced both extensions with uBlock Origin
What is difference between uBlock and uBlock Origin?
EDIT: From Google searches I have learned that uBlock Origin started as fork of uBlock, but maintained by the guys who started uBlock.
What is difference between uBlock and uBlock Origin?
EDIT: From Google searches I have learned that uBlock Origin started as fork of uBlock, but maintained by the guys who started uBlock.
Perhaps useful, a previous discussion: https://news.ycombinator.com/item?id=9718625
My approach was to start by combining SomeoneWhoCares' and MVPS' hosts files with `uniq`, which rendered such browser addons largely, though not entirely, unnecessary. The down side is you can only do that on machines where you have root access.
Hosts files only work for redirecting known bad actors down the memory hole. A noscript style blocker is needed to catch malicious js from new sources not tracked in a hosts database.
That's why I said "largely, but not entirely". I still use them.
Someone is already doing that.
https://hosts.neocities.org/
Warning: Hosts file too large. Could cause problems with Windows DNS Cache.
https://hosts.neocities.org/
Warning: Hosts file too large. Could cause problems with Windows DNS Cache.
Buying a stale entry on the NoScript whitelist for $10 is a cute trick, but the important point this post makes is that you basically can't trust NoScript to protect you from browser vulnerabilities. Many of the zillion scripts it effectively whitelists will themselves have DOM corruption flaws. Compared to the effort it takes to build a reliable drive-by browser exploit, evading NoScript is not a meaningful challenge.
> "you basically can't trust NoScript to protect you from browser vulnerabilities"
You make it sound like NoScript should not be trusted. In reality, nothing is secure but NoScript is one of the better security options (perhaps best?) for helping to prevent a specific set of attacks that use js to enable.
A flaw was found - and promptly fixed. You are (inadvertently I believe) leading people to drop NoScript and possibly go with something else. Another less mature security tool will have its own share of flaws - likely months or years until they will reach relatively similar ground as NoScript.
You make it sound like NoScript should not be trusted. In reality, nothing is secure but NoScript is one of the better security options (perhaps best?) for helping to prevent a specific set of attacks that use js to enable.
A flaw was found - and promptly fixed. You are (inadvertently I believe) leading people to drop NoScript and possibly go with something else. Another less mature security tool will have its own share of flaws - likely months or years until they will reach relatively similar ground as NoScript.
No, you've misread the story. They fixed the stale entry that allowed this guy to pay $10 to whitelist all his Javascript. But any flaw in any of the thousands of Javascript files on all the other default-whitelisted CDNs will also allow attackers to evade NoScript. The CDNs won't be evil. The authors of those Javascript files won't be evil. But attackers will mine them for flaws they can use to evade NoScript, and those flaws will be easy to find (especially compared to reliable browser vulnerabilities).
No, NoScript does not protect against JS browser vulnerabilities.
No, NoScript does not protect against JS browser vulnerabilities.
It's all relative. ~3/4 of the default whitelist is google, yahoo, mozilla, microsoft, cloudflare. While technically, your "thousands of javascript files" is true, in reality, it's making the problem sound bigger than it is.
Those 5 organizations have easier ways to attack you than rely a relatively little used extension to a relatively little used web browser. And attacking any of those 5 organizations is no easy feat.
Firefox + NoScript is still one of the best bang for the buck security improvements any ordinary user can make. Is it foolproof? heck no. Will it stop even a brainless script kiddie intent on hacking you? Not necessarily. But it will eliminate a number of drive by attacks.
Readers should keep converting their moms and dads and grandmas to Firefox + NoScript. Simple and great bang for the buck security.
Those 5 organizations have easier ways to attack you than rely a relatively little used extension to a relatively little used web browser. And attacking any of those 5 organizations is no easy feat.
Firefox + NoScript is still one of the best bang for the buck security improvements any ordinary user can make. Is it foolproof? heck no. Will it stop even a brainless script kiddie intent on hacking you? Not necessarily. But it will eliminate a number of drive by attacks.
Readers should keep converting their moms and dads and grandmas to Firefox + NoScript. Simple and great bang for the buck security.
You are still missing my point, which is frustrating, because I tried to make it clearer last comment. I am not saying Google will try to screw you. I am not even saying the author of the specific Javascript that provides an easy NoScript evasion will be trying to screw you. I am saying that it is not uncommon to find DOM corruption flaws in clientside JS libraries, and if those libraries are hosted on whitelisted CDNs, those flaws are all NoScript evasions.
Two things that may not be intuitively clear to every reader:
1. No way do all of those sites actually do full security audits for every .js file on their domain. (Google comes close.)
2. The specific kind of security flaw we're talking about is not necessarily "interesting" outside the context of NoScript. There are plenty of clientside DOM corruption bugs that don't even get documented, let alone fixed, because they can't easily be used to compromise a user session. But they will work fine for getting the right chunk of malicious JS delivered to end-users.
I'm not anti-NoScript. But don't kid yourself about its utility against browser JS vulns. Before you get your dad to install NoScript, make sure he's patched. Try to get him to switch to Chrome while you're at it.
Two things that may not be intuitively clear to every reader:
1. No way do all of those sites actually do full security audits for every .js file on their domain. (Google comes close.)
2. The specific kind of security flaw we're talking about is not necessarily "interesting" outside the context of NoScript. There are plenty of clientside DOM corruption bugs that don't even get documented, let alone fixed, because they can't easily be used to compromise a user session. But they will work fine for getting the right chunk of malicious JS delivered to end-users.
I'm not anti-NoScript. But don't kid yourself about its utility against browser JS vulns. Before you get your dad to install NoScript, make sure he's patched. Try to get him to switch to Chrome while you're at it.
> No, NoScript does not protect against JS browser vulnerabilities.
Of course it does, it's just not perfect.
Of course it does, it's just not perfect.
No, it really does not. It prohibits an exploit hosted on an unknown site from running.
That is quite different from protecting against JS browser vulnerabilities.
Now, if NoScript added JS sandboxing of some advanced variety employing heuristics such that it detected attempts to exploit vulnerabilities and blocked that code (whilst avoiding solving the halting problem!), then I'd consider a weaker form of the statement, such as "NoScript protects against many JS browser vulnerabilities", as true. But AFAIK, it doesn't do anything like that.
It doesn't even employ signature based techniques that could also protect against some vulnerabilities.
That is quite different from protecting against JS browser vulnerabilities.
Now, if NoScript added JS sandboxing of some advanced variety employing heuristics such that it detected attempts to exploit vulnerabilities and blocked that code (whilst avoiding solving the halting problem!), then I'd consider a weaker form of the statement, such as "NoScript protects against many JS browser vulnerabilities", as true. But AFAIK, it doesn't do anything like that.
It doesn't even employ signature based techniques that could also protect against some vulnerabilities.
Actually I just remove all of the default whitelist stuff when I first install it. Problem solved.
The whitelist did surprise me last time, though. I was baffled why gmail was working without me having to permanently allow it. Then I discovered the whitelist. Woah. What a dumb idea.
The whitelist did surprise me last time, though. I was baffled why gmail was working without me having to permanently allow it. Then I discovered the whitelist. Woah. What a dumb idea.
NoScript doesn't have a public source control repository, which makes it hard to follow what changed between releases. A while ago I made an automatically updated GitHub repository that contains all public releases.
https://github.com/avian2/noscript
For example, this seems to be the change that was pushed as a response to this discovery:
https://github.com/avian2/noscript/commit/398ae6eadd2f40c8b7...
https://github.com/avian2/noscript
For example, this seems to be the change that was pushed as a response to this discovery:
https://github.com/avian2/noscript/commit/398ae6eadd2f40c8b7...
It's a typo, the actual URL is vjs.zencdn.net. No wonder the domain was available.
The URL in the thread he shows is zendcdn though:
https://forums.informaction.com/viewtopic.php?f=10&t=17066
https://forums.informaction.com/viewtopic.php?f=10&t=17066
This is consistent with it being a typo. Typo's just in the forum post now.
Wait, so a domain typoed in the forums was added to the NoScript default whitelist without even being checked?
Oh dear.
Oh dear.
something something "move fast and break things(TM)" something something
That should have been the takeaway of the story, it's certainly the most alarming part. I'd certainly assume there'd be a thorough vetting process.
Wow... That is definitely alarming and should be reported...
Edit:
I reported it on the same thread since it's still active.
Edit: Someone else reported it, it seems.
Edit:
I reported it on the same thread since it's still active.
Edit: Someone else reported it, it seems.
This is the cost of the "hats off" quick response time to complaints.
The article itself mentions that a patch was pushed within hours of contacting the author. Not much vetting can be done in such short time.
The article itself mentions that a patch was pushed within hours of contacting the author. Not much vetting can be done in such short time.
I think NoScript works best as an additional defence line and not as a primary protection mechanism. As such, I would of course still install all regular security updates. It does reduce my attack surface, though, even if it won't stand against dedicated attacks. At the moment it benefits from its rare use (compared to browser users in general) and if it became more widespread and targeted by mainstream attacks, I'm optimistic that the whitelist issue would sort itself out over time (by iteratively removing vulnerable or untrustworthy sites).
Btw., like a few others have noted for theirs, my whitelist does not contain those entries in question. It might be because my installation is relatively old and they weren't pushed retroactively.
Btw., like a few others have noted for theirs, my whitelist does not contain those entries in question. It might be because my installation is relatively old and they weren't pushed retroactively.
Having installed it today I believe the whitelist only affects fresh installations.
If you are on Windows, an additional layer of security might be to install Sandboxie (http://sandboxie.com) and run Firefox from within a dedicated sandbox. Additional brownie points for editing the file/folder access. (making confidential folders inaccessible/write-only)
I'm not sure I agree that trusting subdomains "greatly expands the default trust surface". That's part of the premise of the domain hierarchy: the owner of a domain owns all the subdomains. If you don't trust the policy by which they grant subdomain control to others, then you don't trust the domain. This is the same policy that all browsers use; it might be surprising to folks unfamiliar with URLs, but the article's tone suggests that it's crazy and weird, which definitely isn't the case.
Wow, a domain for sale that's in the whitelist of an addon as popular as NoScript is pretty surprising to me. I immediately assumed it was a CDN by Zend, which seemed like a reasonably trustworthy domain.
Strange considering the general opinion about whitelisting in the original forum thread.
>Giorgio doesn't generally add CDNs to the default whitelist. I'm not sure why he added googleapis.com, except that google.com is already on the default whitelist (so people can use GMail to get support), and googleapis.com is controlled by Google anyway.
My whitelist did not contain this domain, possibly because updates don't change the whitelist retroactively. Which is a good thing if it is part of a policy to never update a users whitelist without them knowing.
Until I see a real audit that looks at bypassing noscript code, I will continue using and promoting noscript as a great tool for safe browsing. No one can deny that a large majority of web exploits use javascript to launch, even when the exploit is in another media or protocol like MS Office or Adobe flash.
Noscript is powerful but it was also never aimed at the general public. In my opinion the general public can benefit from it but only as a shield against unwanted website loading from unknown domains. Because anyone who is not very experienced in the web and able to tie domains to website features will simply use the "allow this page temporarily" feature.
Which in my opinion is fine, it's better protection than not having noscript. But it's not the way noscript was designed to be used.
>Giorgio doesn't generally add CDNs to the default whitelist. I'm not sure why he added googleapis.com, except that google.com is already on the default whitelist (so people can use GMail to get support), and googleapis.com is controlled by Google anyway.
My whitelist did not contain this domain, possibly because updates don't change the whitelist retroactively. Which is a good thing if it is part of a policy to never update a users whitelist without them knowing.
Until I see a real audit that looks at bypassing noscript code, I will continue using and promoting noscript as a great tool for safe browsing. No one can deny that a large majority of web exploits use javascript to launch, even when the exploit is in another media or protocol like MS Office or Adobe flash.
Noscript is powerful but it was also never aimed at the general public. In my opinion the general public can benefit from it but only as a shield against unwanted website loading from unknown domains. Because anyone who is not very experienced in the web and able to tie domains to website features will simply use the "allow this page temporarily" feature.
Which in my opinion is fine, it's better protection than not having noscript. But it's not the way noscript was designed to be used.
Could you please elaborate on what is the preferable alternative to temporarily allowing a page? You often do not know which one of the blocked scripts provides the functionality you are looking for. So you unblock them one by one, I guess? But then, when you unblock the offending script the damage is done.
Obviously, not the parent, but one doesn't need to enable things like newrelic, scorecardresearch, xignite, adroll, etc. in order for a website to function (if so, it's not worth it). I think the basic rule is not to allow any scripting from any domain that isn't directly related to the main domain one is on. Things like ytimg will have to be enabled in order to use youtube, for example, while googleadservices and googletagservices will not.
All right, yes, I do that. I thought the OP was alluding to something more sophisticated :)
Sounds like a legitimate concern but my install of NoScript on Firefox (Ubuntu) which hasn't been customized in any way, shows only a bunch of local ('about:') pages in the "Whitelist" section and nothing else:
http://i.imgur.com/10bBvEq.png
http://i.imgur.com/10bBvEq.png
I'm surprised NoScript actually contains a whitelist, I didn't expect it to.
I personally switched to Policeman (https://addons.mozilla.org/en-US/firefox/addon/policeman/) a while ago, and there it's pretty clear that you can remove the built-in rule set.
I actually like it better than uMatrix: policeman shows you the full url of the blocked resource that you can inspect before allowing, and cross-domain request are very easy to follow.
The only thing I wished is per-domain control of most modern browser extensions, like, for example: disable CSS animations everywhere except when I allow it to. Likewise for <audio>, <media>, GL, and whatever useless feature I don't need 99.99% of the time.
uMatrix has already per-domain boolean control of "agent spoofing" and related settings, it would be awesome if the above would be included there.
NoScript was a bit more forward thinking in that regard: you can disable media/GL globally except for whitelisted sites, but then again without cross-domain control you end-up whitelisting everything.
I personally switched to Policeman (https://addons.mozilla.org/en-US/firefox/addon/policeman/) a while ago, and there it's pretty clear that you can remove the built-in rule set.
I actually like it better than uMatrix: policeman shows you the full url of the blocked resource that you can inspect before allowing, and cross-domain request are very easy to follow.
The only thing I wished is per-domain control of most modern browser extensions, like, for example: disable CSS animations everywhere except when I allow it to. Likewise for <audio>, <media>, GL, and whatever useless feature I don't need 99.99% of the time.
uMatrix has already per-domain boolean control of "agent spoofing" and related settings, it would be awesome if the above would be included there.
NoScript was a bit more forward thinking in that regard: you can disable media/GL globally except for whitelisted sites, but then again without cross-domain control you end-up whitelisting everything.
To my understanding the white list had to be enabled though? I haven't used NoScript in ages but I thought that was what the white list was for?
As for the claim of any subdomain on any website it depends on your settings. Again I haven't used it in a while, but I do know that it was definitely highly configurable.
As for the claim of any subdomain on any website it depends on your settings. Again I haven't used it in a while, but I do know that it was definitely highly configurable.
You're right, it's right under Settings -> General, the very first tab. If that's not obvious then I don't know what is; obviously a tool like NoScript has to be configured and this is the first place anyone would normally go after the FAQ.
Just for the sake of checking, I installed NoScript from their website (not from Mozilla Addons or whatever) and indeed there is a white list, sad it doesn't tell you this, I think the very least they could do is tell you the fact they've added a default whitelist set, and maybe a description explaining why each domain / subdomain has been added.
Edit:
Didn't finish my thought but: It's not too hard to remove links you don't trust from the list since it's not so big, I actually have to say I find the majority of URL's on the list to be quite helpful, especially when trying to figure out how to safelist hotmail with all the numerous domains they use.
Edit:
Didn't finish my thought but: It's not too hard to remove links you don't trust from the list since it's not so big, I actually have to say I find the majority of URL's on the list to be quite helpful, especially when trying to figure out how to safelist hotmail with all the numerous domains they use.
treating noscript (or adblock, or ublock) as security seems misguided. None of them are audited in any real way, or even designed to be security tools. They're nuisance blockers. If they make your web browsing experience slightly less annoying, they're doing their job. Expecting security from them is only going to lower your guard to actual potential threats.
It seems that there should be some kind of automatic sanity check for whitelisted domains. That is, the domain should be registered and should resolve to something. It would also probably make sense to throw up a warning to the NoScript developers if the domain registration ever changes from what was previously approved.
It should probably only whitelist HTTPS as well.
Whats the point of NoScript if its not going to stop tracking from large corps like Google?
I thought that was the reason you installed NoScript?
I thought that was the reason you installed NoScript?
This article was a little startle to me - I never really thought to use NoScript as a security measure for myself. I use it to make the web 'quieter': no more pop-ups, pop-acrosses, popovers, pop-from-wherevers, plus a few other obnoxious behaviours are beaten into submission as well.
Stopping javascript isn't going to stop tracking anyway - the big players still track who's loading their button images, for example.
Stopping javascript isn't going to stop tracking anyway - the big players still track who's loading their button images, for example.
I use Privacy Badger by EFF for blocking third-party cookies(https://www.eff.org/privacybadge). It works incredibly well but does have a whitelist which includes lot of CDNs (https://github.com/EFForg/privacybadgerchrome/blob/master/do...) to prevent websites from breaking.
No. NoScript makes browsing faster, disables lots of annoyances and (to some extent) increases security - not just by blocking JS scripts, but also by providing great tools against stuff like clickjacking.
Maybe it fights some tracking as a side effect, but that's not the reason you install it, because it's not made for that and therefore is not very effective.
Maybe it fights some tracking as a side effect, but that's not the reason you install it, because it's not made for that and therefore is not very effective.
I don't think NoScript should have any whitelist entries by default, since the whole idea behind it is to let the user determine what to allow.
Also, CDNs are quite problematic since they are often hosting many different scripts of which you only want to allow some. A finer-grained path/subdomain matching would be ideal here - you could allow * .example.com, example.com/*, or example.com/script.js.
Also, CDNs are quite problematic since they are often hosting many different scripts of which you only want to allow some. A finer-grained path/subdomain matching would be ideal here - you could allow * .example.com, example.com/*, or example.com/script.js.
It has to have a default whitelist to expand beyond the userbase of hardcore tech people, so that when Kim Komando endorses it, people don't find that their Facebook, Google, and Gmail are suddenly broken.
[deleted]
Yeah yeah, and not only that I allow scripts from various CDNs all the time. I call bullshit on anyone who claims they don't do the same. It's still worth running for no other reason than reducing the overall resources my browser uses and extending the time required between restarts.
I think author using fake image
http://who.is/whois/zendcdn.net
Domain had registered on June 12, 2015
http://who.is/whois/zendcdn.net
Domain had registered on June 12, 2015
Isn't the simple solution to not use the whitelist?
Yes, but you would need to remember to empty the default whitelist before you start using the extension and start whitelisting the sites you trust.
I'm using YesScript (and Greasemonkey) to 'fix bad-behaving' sites. NoScript is to intrusive imho.
Is anyone else curious what he'd have found if he'd continued and actually done the planned testing.
Where did you get that whitelist from? My allowed sites only list the dozen or so I have added.
while noscript is awesome it doesnt mean you can turn your brain off while browsing:)
Having your 'brain turned on' while browsing wouldn't really change the efficacy of this exploit.
A site is on the default whitelist of the addon that can contain a malicious payload. Any site on the internet could therefor have a link to this payload. Granted, I'm not sure what sort of malicious JS payloads there are, other than crashing a browser, that doesn't involve some XSS.
A site is on the default whitelist of the addon that can contain a malicious payload. Any site on the internet could therefor have a link to this payload. Granted, I'm not sure what sort of malicious JS payloads there are, other than crashing a browser, that doesn't involve some XSS.
If you browse with NoScript in default-deny mode, you're probably also the type to use RequestPolicy which would prevent irrelevant sites from running a script off vjs.zendcdn.net
NoScript isn't a comprehensive security/privacy suite. It's just a crucial component.
NoScript isn't a comprehensive security/privacy suite. It's just a crucial component.
RequestPolicy won't save you if the link is to a subdomain of vjs.zendcdn.net which is whitelisted, but also the site you're visiting.
Right, if you get tricked into visiting the site then first-party scripts can run. But with XSS protection intact and RequestPolicy preventing any third-party access, the scope of possible attacks is pretty narrow.
Regardless, I've replaced both extensions with uBlock Origin. While UB in default deny mode is not as fine grained as NS, it does the job and doesn't compromise on default whitelists at the expense of a little breakage (gorhill is very adamant on this point).