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

21–30 of 85 posts

Re: Protecting sites from Cryptojacking with CSP and SRI

#21

Post by JoachimSchipper »

IncRnd wrote: post #9
stri8ed wrote: post #5

Proof of stake will solve this.

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

Re: Protecting sites from Cryptojacking with CSP and SRI

#22

Post by Mister_Snuggles »

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 relatively infrequently and cached for many pages. This is exactly the promise of shared libraries, just on a much wider scale.

On the other hand, why aren’t web site operators delivering all of the code that is needed for the site to function? If they want all their users to execute that code, why aren’t they willing to serve it themselves?

I’m not sure what the right answer is, but this incident is a pro for pulling in all of your dependencies. The limited data plans that a lot of people have are a big pro for hosting libraries centrally.

Re: Protecting sites from Cryptojacking with CSP and SRI

#23

Post by K0nserv »

greglindahl wrote: post #11
walterbell wrote: post #3

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

SRI[0] is still a fairly new technology with lacking browser support. I expect its usage to grow, but it's worth keeping in mind that the use of SRI does not matter at all if the client doesn't support SRI.

0: SRI - Subresource Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Re: Protecting sites from Cryptojacking with CSP and SRI

#25

Post by gokhan »

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?

Possible if the 3rd party script is versioned.

Re: Protecting sites from Cryptojacking with CSP and SRI

#26

Post by amenghra »

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.

Re: Protecting sites from Cryptojacking with CSP and SRI

#27

Post by jakobegger »

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…

Near the end of the post, the author suggest using SRI to prevent the compromised CDN problem. However, that only works for linking to static files (eg. a specific version of a JS library).

More info on SRI: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Re: Protecting sites from Cryptojacking with CSP and SRI

#28

Post by bluejekyll »

sitkack wrote: post #18

Isn't this literally out of 'How I Steal Your Credit Card Number' playbook?

It’s similar. If I remember the CCN playbook correctly, it was about taking over one of your JS dependencies via npm. This is about cross hosted JS, loading remote code.

Re: Protecting sites from Cryptojacking with CSP and SRI

#29

Post by greglindahl »

K0nserv wrote: post #23
greglindahl wrote: post #11

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

SRI[0] is still a fairly new technology with lacking browser support. I expect its usage to grow, but it's worth keeping in mind that the use of SRI does not matter at all if the client doesn't support SRI. 0: SRI - Subresource Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

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.

Re: Protecting sites from Cryptojacking with CSP and SRI

#30

Post by K0nserv »

greglindahl wrote: post #29
K0nserv wrote: post #23

Earlier quoted context omitted.

SRI[0] is still a fairly new technology with lacking browser support. I expect its usage to grow, but it's worth keeping in mind that the use of SRI does not matter at all if the client doesn't support SRI. 0: SRI - Subresource Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

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
Post reply on HN