Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Protecting sites from Cryptojacking with CSP and SRI

scotthelme.co.uk

Post reply on HN
Print view View original

41–50 of 85 posts

Re: Protecting sites from Cryptojacking with CSP and SRI

#41

Post by aepc2 »

Mister_Snuggles wrote: post #22

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

Re: Protecting sites from Cryptojacking with CSP and SRI

#42

Post by cbr » 

    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 running a script on your page to make changes. There's no option for defense in depth here: either you trust that their processes are secure enough that they're not going to XSS you, or you shouldn't run their code on your site at all.

The bar for including javascript from other sites should be a high one, but there are times when the tradeoff is reasonable. For example, I have Google Analytics [1] on my site, and I trust them to handle this responsibly.

[1] Disclosure: I now work for Google

Re: Protecting sites from Cryptojacking with CSP and SRI

#43

Post by Kenji »

cbr wrote: 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…

I really see no reason why anyone would include JS files from other sites. I regularly see people including jquery from google or other sources. Why the hell? You can't host a little JavaScript file yourself? What's wrong with web devs these days??

Re: Protecting sites from Cryptojacking with CSP and SRI

#44

Post by [deleted] »

sago wrote: post #40
Scott_Helme_ wrote: post #35

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.

[deleted]

Re: Protecting sites from Cryptojacking with CSP and SRI

#45

Post by gambler »

cbr wrote: 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…

>The bar for including javascript from other sites should be a high one

Yes, but that's not how most developers think these days. Try browsing the Web with NoScript and you will routinely witness dozens of domains in the block list.

Re: Protecting sites from Cryptojacking with CSP and SRI

#46

Post by cbr »

Scott_Helme_ wrote: post #34
userbinator wrote: post #8

Presumably, 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.

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.

Re: Protecting sites from Cryptojacking with CSP and SRI

#47

Post by petagonoral »

teej wrote: post #16
petagonoral wrote: post #13

> 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 Wouldn't this negate one of the benefits of a 3rd party hosted SaaS? Otherwise, you have to redeploy everytime your provider updates their lib?

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?

> It’s not uncommon to freeze 3rd party libs

Sure. 3rd party libs your code uses directly.

Haven't seen it too much with 3rd party service providers code that are somewhat outside your code boundaries. Taking 2 different popular 3rd party SaaS that are included as JS in sites as an example.

Google Analytics uses url of https://www.google-analytics.com/analytics.js [1]

Stripe uses url of https://js.stripe.com/v3/ [2]

Clearly not. Nor was this inferred.

[1] https://developers.google.com/analytics/devguides/collection... [2] https://stripe.com/docs/stripe-js/reference

Re: Protecting sites from Cryptojacking with CSP and SRI

#48

Post by gambler »

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.

Re: Protecting sites from Cryptojacking with CSP and SRI

#49

Post by foepys »

Mister_Snuggles wrote: post #22

I 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…

> On one hand, when many sites use jQuery (for example), there’s huge benefits (bandwidth, speed, etc) in having it loaded from one location relatively infrequently and cached for many pages.

Does it really decrease bandwidth usage and load times? Is there a study that looked at that specifically in recent months or is it just a assumption? I'm getting the feeling that including common JS libraries is on the decline and more and more developers are using node.js packages that are built into their frontend code. Not to mention that there are quite a few CDNs that are basically providing the same service for the most common frameworks and are thus detrimental to this theory.

Re: Protecting sites from Cryptojacking with CSP and SRI

#50

Post by greglindahl »

cbr wrote: post #46
Scott_Helme_ wrote: post #34

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

That depends on what "this problem" is -- lots of people here would say that the problem is websites that depend on unaudited, untested 3rd party resources. I can tell from your other comments that you think it's safe to trust 3rd party resources from places like Google. So there's a disagreement that is worth talking about explicitly.
Post reply on HN