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

31–40 of 85 posts

Re: Protecting sites from Cryptojacking with CSP and SRI

#31

Post by greglindahl »

amenghra wrote: post #26
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 right answer is to specify a HMAC when serving js from third parties. CSP/SRI already enables this. Ideally you should be able to serve content from your own domain + specify the hash, and let browsers optimize things by re-using cached content from another domain. There’s no easy/standardized way of doing that today.

I think you can already do a browser extension that intercepts loads and gets things with script integrity from a cache, another domain, ipfs, whatever.

Decentraleyes is an example of an existing codebase you could use: https://github.com/Synzvato/decentraleyes

Re: Protecting sites from Cryptojacking with CSP and SRI

#32

Post by floatboth »

userbinator wrote: post #17
jnordwick wrote: post #12

When will the JavaScript community learn to stop trusting 3rd party code downloaded over the internet? In the previous event the code disappeared. This time it isn't what you wanted.

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">

Re: Protecting sites from Cryptojacking with CSP and SRI

#33

Post by greglindahl »

K0nserv wrote: post #30
greglindahl wrote: post #29

Earlier quoted context omitted.

As a guy who crawls, indexes, and archives websites, subresource integrity matters to me whether or not the client supports it. You probably had end-users in mind.

Yeah exactly I was thinking of end users. Since the support in end user's client dictate what websites will implement I think we'll see use of SRI increase over the coming years

I would be amazed if anyone disagreed with you about that.

Status of client support: https://caniuse.com/#search=integrity

Re: Protecting sites from Cryptojacking with CSP and SRI

#34

Post by Scott_Helme_ »

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.

Re: Protecting sites from Cryptojacking with CSP and SRI

#35

Post by Scott_Helme_ »

amenghra wrote: post #26
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 right answer is to specify a HMAC when serving js from third parties. CSP/SRI already enables this. Ideally you should be able to serve content from your own domain + specify the hash, and let browsers optimize things by re-using cached content from another domain. There’s no easy/standardized way of doing that today.

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.

Re: Protecting sites from Cryptojacking with CSP and SRI

#37

Post by tetha »

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. This is exactly the promise of shared libraries, just on a much wider scale.

This is an interesting comment.

So, packing all the JS into one file + optionally removing unused symbols would be similar to statically linked binaries. If optimized well, this would be the smallest amount of code / binary a system has to load to execute the program, but if you have multiple binaries, you might load the same library code multiple times. And security updates of libraries require you to recompile everything. But, in this context, you have to trust basically one JS-file from the host you're accessing.

On the other hand, dynamic libraries minimize the bandwidth / memory required to hold the code for a set of binaries, because libc/jquery/... just gets loaded once, instead of once per application. And, technically, shared libraries simplify security updates - update openssl, restart services, and hope that RHEL tested well so you don't end up with a mess. This would be really cool, if you think about it. Depend on magic-js-provider.acme.org/jquery/2.1.x.js, and get security fixes like that. Except the testing would be a nightmare.

Re: Protecting sites from Cryptojacking with CSP and SRI

#38

Post by oldcynic »

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…

> which 3rd party sites do I need to allow to get the content to show up

This is a game I'm increasingly unwilling to play. The number of domains has got out of hand and are increasingly vaguely named - whether it's a CDN, ads or tracking is often almost impossible to judge.

Life's too short now sites are frequently calling out to 15 or more domains for me to jump through hoops just to get some text to display. Images I'm usually happy to dispense with. So I increasingly favour sites that don't need these games. There's still more than enough - for now at least!

Re: Protecting sites from Cryptojacking with CSP and SRI

#40

Post by sago »

Scott_Helme_ wrote: post #35
amenghra wrote: post #26

Earlier quoted context omitted.

The right answer is to specify a HMAC when serving js from third parties. CSP/SRI already enables this. Ideally you should be able to serve content from your own domain + specify the hash, and let browsers optimize things by re-using cached content from another domain. There’s no easy/standardized way of doing that today.

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.

Post reply on HN