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

71–80 of 85 posts

Re: Protecting sites from Cryptojacking with CSP and SRI

#71

Post by alexgvozden »

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…

it's kind of a huge benefit and then first image that gets displayed is unoptimized 200-300kb png

Re: Protecting sites from Cryptojacking with CSP and SRI

#72

Post by Mister_Snuggles »

foepys wrote: post #49
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…

I’ll admit that it’s not something I’ve verified, just an argument I’ve seen in favour of thise practice elsewhere, but it makes sense.

If a browser already has https://code.example.com/blah.1.0.0.js in cache, wouldn’t it just use that instead of loading it again?

Edit: This post from StackOverflow lists a number of benefits, most of which will result in better perceived performance when using Google’s CDN vs hosting jQuery yourself: https://stackoverflow.com/questions/2180391/why-should-i-use...

Re: Protecting sites from Cryptojacking with CSP and SRI

#73

Post by cbr »

greglindahl wrote: post #50
cbr wrote: post #46

Earlier quoted context omitted.

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.

Most sites are built on lots of unaudited untested (by them) third party code sever side. Adding some client side isn't great, but also isn't a fundamental change to the dynamic.

(I used to make web server software)

Re: Protecting sites from Cryptojacking with CSP and SRI

#75

Post by hyperpape »

foepys wrote: post #49
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…

Load times, I believe yes, unless you have your own CDN. But you’re right that the odds that any particular version is in the user’s cache are low. I gathered some links on the subject a while ago: http://justinblank.com/notebooks/browsercacheeffectiveness.h....

Re: Protecting sites from Cryptojacking with CSP and SRI

#76

Post by nodesocket »

If you use 3rd parties such as analytics and chat scripts you don't have control if they legitimaty change the response. I get it, they are supposed to use versioning and bump, but you'd be surprised.

All your hard coded hashes fail and your 3rd party analytics, chat, etc all stop working. Is there a solution to that?

Re: Protecting sites from Cryptojacking with CSP and SRI

#77

Post by hyperpape »

jschwartzi wrote: post #61

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.

I think adoption is limited enough that you just need to run NoScript, uBlock or something and whitelist JS.

Re: Protecting sites from Cryptojacking with CSP and SRI

#78

Post by throwawaypanda »

gambler wrote: post #45
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.

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

>but that's not how most developers think these days.

The decision to include third party javascript is sometimes not even up to developers these days.

"A deal has been signed with company X, put their widget on the site" is something I've now heard a few times.

Arguments about the third party code greatly increasing page load time, page size, introducing security vulnerabilities etc then fall on deaf ears. High developer turnover seems to co-occur in these environments.

Re: Protecting sites from Cryptojacking with CSP and SRI

#79

Post by greglindahl »

cbr wrote: post #73
greglindahl wrote: post #50

Earlier quoted context omitted.

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.

Most sites are built on lots of unaudited untested (by them) third party code sever side. Adding some client side isn't great, but also isn't a fundamental change to the dynamic. (I used to make web server software)

Uh, so that's terrible added to terrible, but it doesn't really address what I just said!

If I was the mean person at IBM that buys startups and makes them "right", it's a lot more work to fix terrible added to terrible than plain terrible. And my last startup got bought by IBM, so I've experienced that pain personally.

Re: Protecting sites from Cryptojacking with CSP and SRI

#80

Post by stordoff »

skinpop wrote: post #74

maybe we should throw out ads and instead let creators borrow our computers to mine for a few minutes while we interact with their content.

I suspect what we'd actually end up with is miners PLUS ads. There's little incentive to not use both forms of monetisation, as neither prevents the other from being used.

I also don't think it's a great trade-off for a variety of reasons (environment impact, possible wear and tear on user's machines, battery life on mobile devices etc.).

Post reply on HN