Live data from Hacker News

Protecting sites from Cryptojacking with CSP and SRI

scotthelme.co.uk

81–85 of 85 posts

Re: Protecting sites from Cryptojacking with CSP and SRI

#81
post #25
post #16

Earlier quoted context omitted.

It’s not uncommon to freeze 3rd party libs. Do you want a 3rd party provider to have access to hot deploy to your website?

Possible if the 3rd party script is versioned.

Isn't that the same as freezing the script (except still loading from a remote and using SRI to enforce that it wasn't changing)?

Re: Protecting sites from Cryptojacking with CSP and SRI

#82
post #40

Earlier quoted context omitted.

There is/was discussion in the standards body of using the SRI hash for exactly this purpose. It sounds really promising but iirc there was a privacy kink to work out.

You could potentially tell whether someone has been to a third-party site. Person goes to a porn site, get's file #A. Spying site, offers file #A, but never delivers it. If a person already has #A (i.e. doesn't request it), spy site knows they've been to porn site.

Could you limit it to widely used libraries? e.g. browser ships with the last N versions of jQuery etc., and avoids the request if it's a known hash. If it's widely used, it seems like the amount of information leaked would be low, and if the browser _always_ ships with it (rather than caching on first use), it would only identify the browser and not browsing history anyway.

As a bonus, developers could use it knowing that there is much less likely to be a performance hit from fetching it.

Re: Protecting sites from Cryptojacking with CSP and SRI

#83
post #42

Want to know how you can easily stop this attack? What I've done here is add the SRI Integrity Attribute and that allows the browser to determine if the file has been modified, which allows it to reject the file. SRI does not fix this problem. If you put an integrity attribute on the script, then the next time BrowseAloud releases to prod their script will stop working on your site. This is a product that works by ru…

> For example, I have Google Analytics [1] on my site, and I trust them to handle this responsibly.

I don't. And I don't appreciate people injecting Google beacons on their website. Same thing with Facebook, Twitter, Disqus and all the other shit-scripts.

Re: Protecting sites from Cryptojacking with CSP and SRI

#84
post #51

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.

I consider ad-tech to be fundamentally malicious and block it. It is only reasonable course of action.

Re: Protecting sites from Cryptojacking with CSP and SRI

#85
post #48

Content-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.

CSP is a whitelist-based approach; CSS/JS/etc. will only be permitted from the sources listed in the CSP header.
Post reply on HN