Protecting sites from Cryptojacking with CSP and SRI

Re:Protecting sites from Cryptojacking with CSP and SRI by petagonoral on Sunday February 11, 2018 @01:17PM (#16353896)

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

[ Parent | on HN ]

Re:Protecting sites from Cryptojacking with CSP and SRI by teej on Sunday February 11, 2018 @01:21PM (#16353918)

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?

[ Parent | on HN ]

Re:Protecting sites from Cryptojacking with CSP and SRI by gokhan on Sunday February 11, 2018 @01:39PM (#16354018)

Possible if the 3rd party script is versioned.

[ Parent | on HN ]

Re:Protecting sites from Cryptojacking with CSP and SRI by stordoff on Sunday February 11, 2018 @11:23PM (#16356519)

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)?

[ Parent | on HN ]

Re:Protecting sites from Cryptojacking with CSP and SRI by petagonoral on Sunday February 11, 2018 @03:12PM (#16354511)

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

< Do you want a 3rd party provider to have access to hot deploy to your website?

Clearly not. Nor was this inferred.

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

[ Parent | on HN ]