A 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.
Protecting sites from Cryptojacking with CSP and SRI
51–60 of 85 posts
Re: Protecting sites from Cryptojacking with CSP and SRI
#52we used to do an ajax load of a resource and doing simply hash of it "by hand," sending "alarm, lib A has suddenly changed" by ajax to HQ
Re: Protecting sites from Cryptojacking with CSP and SRI
#53Earlier quoted context omitted.
> Proof of stake will solve this. No. It. Won't. The issue isn't PoW/PoS but the loading of infected code into browsers. PoS may stop the need for this particular JS code to get inserted. However, PoS will hinder no other JS from being inserted.
In principle, sites should be secure. In practice, putting an implicit bug bounty on every widely-used Javascript library does produce more exploitation. I think you missed an opportunity to engage your parent comment more productively.
What principle states sites should be secure?
There is hardly even a nod to security, no defense in depth, and no cryptographic protections. There is widespread loading of untrusted unvetted code. The operating principle of the web seems to be, "it's okay to do this, everyone else is."
Re: Protecting sites from Cryptojacking with CSP and SRI
#54What percentage of mainstream sites use the "integrity" hash validation attribute when loading 3rd-party script for a known-good library version? Would be a useful data point for a "tech stack" web crawler to monitor.
Use of integrity hash validation is pretty limited -- I see 90k sites in the top 10 million. It's a shame this isn't more popular, I'd love to build a browser add-on that uses the integrity hash as the name of the script, and load them from ipfs or something. Top sites: gov.uk, nhm.ac.uk, change.org, blogs.worldbank.org, handbrake.fr, army.mil, genome.gov, ...
that info. on the level of support is v. interesting, is there any published data on it that could be linked to (blog posts, web site etc)?
Re: Protecting sites from Cryptojacking with CSP and SRI
#55This 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?
yeah the complete lack of signing on npm libs + the large dependency trees that can trip you up (e.g. the leftpad problem) are only going to cause more issues as attackers move on to that as a vector.
Re: Protecting sites from Cryptojacking with CSP and SRI
#56Earlier quoted context omitted.
Use of integrity hash validation is pretty limited -- I see 90k sites in the top 10 million. It's a shame this isn't more popular, I'd love to build a browser add-on that uses the integrity hash as the name of the script, and load them from ipfs or something. Top sites: gov.uk, nhm.ac.uk, change.org, blogs.worldbank.org, handbrake.fr, army.mil, genome.gov, ...
that info. on the level of support is v. interesting, is there any published data on it that could be linked to (blog posts, web site etc)?
There are a bunch of crawlers that aggregate that kind of info -- I'm building a new search engine, and I'm not in the business of publishing stuff that would encourage anyone to block my crawler.
builtwith.com is an example, but they're being pretty strict with what you can see for free these days. And hey, they only know about 2k sites using script integrity, so maybe I've got a bigger crawl than they do! :-)
Re: Protecting sites from Cryptojacking with CSP and SRI
#57"On top of all of that, you could be alerted to events like this happening on your site via CSP Reporting" Too bad this can be abused by marketing parasites.
How?
CSP reporting is an unprotected form, in itself a vulnerability.
The author of the article is biased as he made a SaaS product for CSP reporting.
CSP reporting should be for local debugging only.
Re: Protecting sites from Cryptojacking with CSP and SRI
#58[deleted]
Re: Protecting sites from Cryptojacking with CSP and SRI
#59I use uMatirx and it’s given me a pretty good lesson on how much stuff sites load from 3rd-parties. Many sites need me to play whack-a-mole to get them to display - which 3rd party sites do I need to allow to get the content to show up. I’m really torn by this sort of thing. On one hand, when many sites use jQuery (for example), there’s huge benefits (bandwidth, speed, etc) in having it loaded from one location relat…
The Firefox extension decentraleyes promises to cache common libraries locally. Thus making you, your own CDN.
Which, incidentally, exposes an info leak. Timing the load time for a cached script reveals if you've loaded that script before. Value low for extremely common libraries, higher for less common libraries.
Re: Protecting sites from Cryptojacking with CSP and SRI
#60Earlier quoted context omitted.
How?
CSP reporting is an unprotected form, in itself a vulnerability. The author of the article is biased as he made a SaaS product for CSP reporting. CSP reporting should be for local debugging only.
I'm sorry, I'm still not following. How can CSP reporting be used by marketers? It requires a header sent from the server, so it's not like a tracking pixel that can be added by a third party. And I'm not sure about local debugging only, locally it offers no benefits over just viewing the devtools console, whereas it offers a lot of benefits when enabled on users of your sites.