How would I get Mozilla to warn me when a script is loaded without Subresource Integrity? I'd like to avoid being caught unawares by this type of security hole, especially if it lets third parties execute code in my browser without any controls.
Protecting sites from Cryptojacking with CSP and SRI
61–70 of 85 posts
Re: Protecting sites from Cryptojacking with CSP and SRI
#62Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, Access-Control-Allow-Origin... How many hacks like these will we need before people stop to rethink the fundamental security model underpinning the Web? It's clearly crumbling.
We are clearly in the Antivirus level of protection (blacklists) to maintain backwards compatibility, instead of a whitelist of allowed domains or features to use.
Re: Protecting sites from Cryptojacking with CSP and SRI
#63Presumably, the "[Warning] Do not copy or self host this file, you will not be supported" is because they change the script reasonably often, meaning that using SRI will require them to change their hashes on every linked page every time the script changes or it will stop working --- probably not what they want. when visiting the ICO website That is... amusingly ironic.
Was the warning added by the hackers, though?
Re: Protecting sites from Cryptojacking with CSP and SRI
#64This makes me wonder what happens when a popular nodejs library get used in this way. What could hackers do with thousands of compromised nodejs servers?
Nowadays it's just about getting as many miners as possible. No big mystery.
Well they might do other things in to your house, now they have the keys.
Re: Protecting sites from Cryptojacking with CSP and SRI
#65Something like JS 'permissions' could help here. I.e. load a script but limit how much CPU/GPU access it has plus determining if it has DOM access, XHR access, etc. So you load the script and tell it what it can do. Also developers taking security more seriously. But it is rarely a priority, since risk reduction is not paid for today.
Re: Protecting sites from Cryptojacking with CSP and SRI
#66A useful tech it is. The problem is 3rd party code from adnets is changing all the time, and they will never tell you about that because they hide all kind of anti-clickfraud trick there. From intentionally broken JS syntax, to intentionally broken Unicode, to actual 0day exploits.
When I first read this discussion, I just assumed that BrowseAloud was some sort of ad-tech or analytics code. But it's assistive technology for screen readers. The list of web sites that were compromised were web sites that were trying to do the right thing to help disabled users.
Ad-tech is a giant security hole that can't be fixed without burning it all down, but BrowseAloud could be fixed.
Re: Protecting sites from Cryptojacking with CSP and SRI
#67am I weird in that I'd prefer to host a known version of a dependency than effectively hot-link like this?
Avoiding this sort of attack is a just a side-benefit to the main premise of knowing that its always going to work consistently.
Re: Protecting sites from Cryptojacking with CSP and SRI
#68Something like JS 'permissions' could help here. I.e. load a script but limit how much CPU/GPU access it has plus determining if it has DOM access, XHR access, etc. So you load the script and tell it what it can do. Also developers taking security more seriously. But it is rarely a priority, since risk reduction is not paid for today.
I like this option, similar to how apps request permissions on a mobile OS. There could be a default list of modifications an external javascript script can run, any further access must be explicitly white listed by the developer. Then even if the script was malicious, at least the impact is controlled.
for instance, maybe the default is that an external script can read the DOM but needs extra permissions to write/modify it?
Re: Protecting sites from Cryptojacking with CSP and SRI
#69Earlier quoted context omitted.
Yeah, the best way to handle this is with a version in the path and then the host can knowingly/willingly upgrade the library version and SRI hash at the same time.
That doesn't really solve this problem, it just slows down both the rollout of the subverted version and the rollout of the fix. People aren't auditing the (minified) javascript they put onto their sites. SRI is good for use with a CDN, where the same entity controls both the HTML that references the JS and the JS being referenced. In that case it keeps someone who subverts the CDN from being able to XSS the site.
If there’s a version in the path, then the website referencing the script can include a hash, secure in the knowledge that the resource they reference should never change.
Re: Protecting sites from Cryptojacking with CSP and SRI
#70Earlier quoted context omitted.
When will the JavaScript community learn to stop trusting 3rd party code downloaded over the internet? Given that the majority in the JS community probably have it enabled by default in their browsers, probably never...
Not 3rd party in relation to the user's machine. 3rd party in relation to the site. As in " rel="nofollow">https://someone.elses.domain/something.js">
Those are the same thing