Hacker News new | ask | show | jobs
by DyslexicAtheist 2559 days ago
SRI is such a cool idea (in theory) but the approach fails in practice. Also very few sites maintain a solid Content Security Policy (CSP). What's the point of all these controls/tools when nobody uses them?
4 comments

I would suspect that ads make it difficult if not impossible to write a good CSP. It's also probably much easier to create a good CSP if you start with it, and much harder and likely to break unexpectedly if you try to add it retroactively on an existing site.

I also found that some modern tooling for web apps doesn't seem to be built with CSPs in mind. For example CSS styling in JS like React Styled Components, I'm not sure it's even possible to create a CSP that covers CSS in this case.

It is, but often not supported out of the box. You will need to extract any css during the build into separately served files. Also it‘s a pain during development. But it‘s possible.
Yes! I mean, I understand that few websites have the expertise, personnel and incentive to come up with a working CSP and maybe even SRI tags. But then you see these incidents where CC data is exfiltrated from the payment pages of major airlines (British Airways) and all that other MageCart shit and you start to wonder: These pages don't need ads on them, any code that goes out should be reviewed so there would be resources for CSP/SRI, and the economic incentive is somewhat given (bad press). Still nothing happens :/
Is no one using them because there's little awareness of them in the wider web dev industry? Is no one using them because the courses being taught at the moment don't include security? Are they too hard to use? Are they not turned on by default?
yes to all of them? I love these concepts but who wants to maintain CSP's and audit revisions to 3rd party javascript in a fast moving environment (see my DevOps is crap rant below). Maybe I start a new project with best intentions, but then marketing comes, then there is pressure to just get on with it ... Even with best intentions, it's literally impossible to keep track as the system matures and complexity increases. And you eventually have to give up on auditing any of the external resources (who even does that in the first place - instead we all assume it has been properly checked by the upstream vendor).

Having a "security-ops meeting" to discuss whether we should really be using shiny new XYZ.js from another external provider isn't going to work either. It all seems like it's more of a mindset problem than a technical one. It's one hot mess.

can someone explain the downvotes? Would be cool to understand why this is rubbing y'all the wrong way.
I didn't downvote you but this site is very downvotey for anything that doesn't fit the hivemind. The downvotes on Dropbox's first post are infamous.

You're absolutely right that CSP and SRI are good in theory but fail in practice.

For CSP, it's too difficult to implement a secure CSP, especially without breaking your site. I know companies where it took over a year to implement their CSP. And then, at the end of the day, it's really hard to do securely. Research has found most CSPs are insecure. For example, the posted blog's CSP is: default-src * data: 'unsafe-eval' 'unsafe-inline' But even CSPs that look like they're trying to be secure contain subtle insecurities.

Even trusted domains you might put in your CSP can be used in untrusted ways. For example, this blog post uses Gravatar. Did you know that Gravatar has an optional "default image URL" that can be used for data exfiltration even on sites with secure.gravatar.com in their CSP? It's because Gravatar will proxy the request to fetch the default image if it doesn't recognize the email. https://en.gravatar.com/site/implement/images/ So you may think you've done everything correctly and have a good CSP but in reality it's really hard to do securely.

SRI isn't practical for third party resources that are expected to change over time, which is actually most third party resources. For example, a chat script like Intercom will change when someone from marketing makes a change that affects its frontend settings. This may be changing some text or coloring. You can use SRI for something like a specific version of jQuery, but not for most of the products people are relying on that have more dynamic functionality.