5 ms·

1. Yes 2. Because that requires you to know how to find the hash and add it. Truthfully the burden should be on the third party that's serving the script (whe

1. Yes 2. Because that requires you to know how to find the hash and add it. Truthfully the burden should be on the third party that's serving the script (where did you copy that HTML in the first place?) but they aren't incentivizes to have other sites use a hash.

valenterry 2y ago
Well, to be honest, the browsers could super easily solve that. In dev mode, just issue a warning "loaded script that has hash X but isn't statically defined. This is a huge security risk. Read more here" and that's it. Then you can just add the script, run the site, check the logs and add the hash, done.
- sirl1on 2y ago
  You can define a CSP header to only exec 3rd Party scripts with known hashes
  - valenterry 2y ago
    But that doesn't make it easy to integrate a new script from an author who doesn't provide the hash already.
    - no_wizard 2y ago
      Vendor your dependencies. It’s better for you as a maintainer anyway, since caching only works[0] with first party domains with any reliability. And once you vendor your dependencies you can calculate the hash yourself [0]: there are caveats to this
      - TZubiri 2y ago
        How would third party distribution like a cdn affect hashing? I think https and integrity hashes address two very orthogonal attack vectors.
        0xCMP 2y ago
        Because if you're not getting the real benefit (improved response times due to caching) you can stop worrying about hashing it properly or not and simply serve a copy you know to be good (or at least known and probably version controlled). Now you don't need to hash or know which hash is correct or worry about the user getting served the wrong file because someone else got hacked.
        TZubiri 2y ago
        Not sure I follow, how does hashing mean you lose improved response times or caching? Do you mean that hashing the file takes time? I guess that can be significant, but it's probably 2 or 3 cycles per byte, and average js size is like 10kb tops? 30khz doesn't look like much, it's a millionth of a second.
        0xCMP 2y ago
        No, the hashing either when generating or checking is very fast like you said. Hashing itself isn't the culprit, but the battle between browsers and those fingerprinting users. Originally the point of using a shared CDN like this was that if others used it too the file would already be cached on the user's computer and make it even faster. But, this feature was used for fingerprinting users by checking which files from other websites were cached and browsers have isolated the caches in response which makes it impossible to get the speed benefits from before. So if you're not getting that speed benefit, and only really getting a tiny bandwidth reduction, the risks of serving the file from a 3rd party (which could be mitigated by the hashes) aren't worth it compared to simply vendoring the file and serving it yourself. So it's not that hashing prevents caching or lowers response times, but that the risk it is mitigating isn't worth the effort. Just 'err on serving the file yourself.
        no_wizard 2y ago
        It’s about control foremost. If you vendor your dependencies you know what you’re serving and can calculate the hash and use it in your CSP, and provides more stability for versioning. Plus, as mentioned, only 1st party origins enjoy any benefits of caching content for faster load times so you get an additional benefit
    - TZubiri 2y ago
      But you can .. get the hash yourself? wget url; sha256 file
      - valenterry 2y ago
        Of course you can. But when it comes to security, one thing is very important in practice: making the secure way of doing things as easy as possible. So, why did you not actually post the correct shell script? Apparently that would have been more effort to get right and ensure is correct right? And also work for every OS. And there you have it: if someone first has to figure out which script to run, some percentage will give up here. And that's my point: the browser should make it as easy as possible to avoid that from happening.
      - account42 2y ago
        Cool. Now your site will break if the upstream pushes a fix while you're on vacation.
- bastawhiz 2y ago
  > In dev mode, just issue a warning "loaded script that has hash X but isn't statically defined. How does the browser know which files to warn you about? What about scripts that are generated dynamically and have no static hash? There's plenty of reasons why you wouldn't want this.
  - valenterry 2y ago
    It just warns about all embedded non-same-origin scripts that don't have a hash. > What about scripts that are generated dynamically and have no static hash? Well, then the warning is still valid because this is a security risk. I guess it'd be fine to be able to suppress the warning explicitly in those cases. > There's plenty of reasons why you wouldn't want this. For example? Honestly curious where you would not want a warning by default.
quacksilver 2y ago
I wish popular browsers would get together and release an update that says: - After version X we are displaying a prominent popup if a script isn't loaded with a hash - After version Y we blocking scripts loaded without hashes They could solve this problem in a year or so, and if devs are too lazy to specify a hash when loading scripts then their site will break.
- TZubiri 2y ago
  I don't think it's just laziness. There's use cases where the libraries are designed to be updated automatically. Also some of the tracking scripts I don't think are strictly static content, maybe their strategy to fingerprint browser involves sending different shit to different users.
  - quacksilver 2y ago
    If you are the one serving the website, then you are the one generating the hash. If you want to serve different stuff then you could dynamically generate the hash for that different stuff rather than hard code it statically. Specifying a script hash says that you as the owner of that site agree to load the content only if it matches the hash. Presumably you trust the content enough to serve it to your users.
- bastawhiz 2y ago
  Literally every website that uses JSONP will stop working if that happened. This would break the web in fundamental ways. If we're going to break the web in fundamental ways, resource integrity is hardly among the things that I'd be interested in changing.
  - quacksilver 2y ago
    Why would people choose JSONP over CORS? There are security risks with JSONP (a hack to bypass same-origin policy), and the successor (CORS) has been around since 2009, so phasing it out may be a good thing. https://dev.to/benregenspan/the-state-of-jsonp-and-jsonp-vulnerabilities-in-2021-52ep https://dev.to/benregenspan/the-state-of-jsonp-and-jsonp-vul...

valenterry 2y ago

Well, to be honest, the browsers could super easily solve that. In dev mode, just issue a warning "loaded script that has hash X but isn't statically defined. This is a huge security risk. Read more here" and that's it. Then you can just add the script, run the site, check the logs and add the hash, done.

sirl1on 2y ago
You can define a CSP header to only exec 3rd Party scripts with known hashes
- valenterry 2y ago
  But that doesn't make it easy to integrate a new script from an author who doesn't provide the hash already.
  - no_wizard 2y ago
    Vendor your dependencies. It’s better for you as a maintainer anyway, since caching only works[0] with first party domains with any reliability. And once you vendor your dependencies you can calculate the hash yourself [0]: there are caveats to this
    - TZubiri 2y ago
      How would third party distribution like a cdn affect hashing? I think https and integrity hashes address two very orthogonal attack vectors.
      - 0xCMP 2y ago
        Because if you're not getting the real benefit (improved response times due to caching) you can stop worrying about hashing it properly or not and simply serve a copy you know to be good (or at least known and probably version controlled). Now you don't need to hash or know which hash is correct or worry about the user getting served the wrong file because someone else got hacked.
        TZubiri 2y ago
        Not sure I follow, how does hashing mean you lose improved response times or caching? Do you mean that hashing the file takes time? I guess that can be significant, but it's probably 2 or 3 cycles per byte, and average js size is like 10kb tops? 30khz doesn't look like much, it's a millionth of a second.
        0xCMP 2y ago
        No, the hashing either when generating or checking is very fast like you said. Hashing itself isn't the culprit, but the battle between browsers and those fingerprinting users. Originally the point of using a shared CDN like this was that if others used it too the file would already be cached on the user's computer and make it even faster. But, this feature was used for fingerprinting users by checking which files from other websites were cached and browsers have isolated the caches in response which makes it impossible to get the speed benefits from before. So if you're not getting that speed benefit, and only really getting a tiny bandwidth reduction, the risks of serving the file from a 3rd party (which could be mitigated by the hashes) aren't worth it compared to simply vendoring the file and serving it yourself. So it's not that hashing prevents caching or lowers response times, but that the risk it is mitigating isn't worth the effort. Just 'err on serving the file yourself.
      - no_wizard 2y ago
        It’s about control foremost. If you vendor your dependencies you know what you’re serving and can calculate the hash and use it in your CSP, and provides more stability for versioning. Plus, as mentioned, only 1st party origins enjoy any benefits of caching content for faster load times so you get an additional benefit
  - TZubiri 2y ago
    But you can .. get the hash yourself? wget url; sha256 file
    - valenterry 2y ago
      Of course you can. But when it comes to security, one thing is very important in practice: making the secure way of doing things as easy as possible. So, why did you not actually post the correct shell script? Apparently that would have been more effort to get right and ensure is correct right? And also work for every OS. And there you have it: if someone first has to figure out which script to run, some percentage will give up here. And that's my point: the browser should make it as easy as possible to avoid that from happening.
    - account42 2y ago
      Cool. Now your site will break if the upstream pushes a fix while you're on vacation.
bastawhiz 2y ago
> In dev mode, just issue a warning "loaded script that has hash X but isn't statically defined. How does the browser know which files to warn you about? What about scripts that are generated dynamically and have no static hash? There's plenty of reasons why you wouldn't want this.
- valenterry 2y ago
  It just warns about all embedded non-same-origin scripts that don't have a hash. > What about scripts that are generated dynamically and have no static hash? Well, then the warning is still valid because this is a security risk. I guess it'd be fine to be able to suppress the warning explicitly in those cases. > There's plenty of reasons why you wouldn't want this. For example? Honestly curious where you would not want a warning by default.

quacksilver 2y ago

I wish popular browsers would get together and release an update that says: - After version X we are displaying a prominent popup if a script isn't loaded with a hash - After version Y we blocking scripts loaded without hashes They could solve this problem in a year or so, and if devs are too lazy to specify a hash when loading scripts then their site will break.

TZubiri 2y ago
I don't think it's just laziness. There's use cases where the libraries are designed to be updated automatically. Also some of the tracking scripts I don't think are strictly static content, maybe their strategy to fingerprint browser involves sending different shit to different users.
- quacksilver 2y ago
  If you are the one serving the website, then you are the one generating the hash. If you want to serve different stuff then you could dynamically generate the hash for that different stuff rather than hard code it statically. Specifying a script hash says that you as the owner of that site agree to load the content only if it matches the hash. Presumably you trust the content enough to serve it to your users.
bastawhiz 2y ago
Literally every website that uses JSONP will stop working if that happened. This would break the web in fundamental ways. If we're going to break the web in fundamental ways, resource integrity is hardly among the things that I'd be interested in changing.
- quacksilver 2y ago
  Why would people choose JSONP over CORS? There are security risks with JSONP (a hack to bypass same-origin policy), and the successor (CORS) has been around since 2009, so phasing it out may be a good thing. https://dev.to/benregenspan/the-state-of-jsonp-and-jsonp-vulnerabilities-in-2021-52ep https://dev.to/benregenspan/the-state-of-jsonp-and-jsonp-vul...