4 ms·

> If you absolutely have to load someone else's code, check to see if it has been altered. Third party JavaScript code can be altered for legitimate reasons. e

by asaph 8y ago

> If you absolutely have to load someone else's code, check to see if it has been altered. Third party JavaScript code can be altered for legitimate reasons. e.g. adding new features, refactoring, security fixes, etc. In order to prevent a site which uses SRI from breaking every time a 3rd party makes an update to a js file, 3rd parties should version their JavaScript resources with a version number in the URL. This, of course, places the added burden on the site that uses the 3rd party JavaScript resource. They need to update the version number in the URL and update the SRI every time the 3rd party releases an update. And this should be a manual process because automating it would defeat the whole point of SRI.

amelius 8y ago
Why not just copy the file, inspect it, and serve it from your own servers?
- asaph 8y ago
  It's because that can break the site due to the browser's sandbox permissions model. Scripts are only allowed to make ajax calls to their origin servers. Also, serving a 3rd party script from the 1st party's domain gives the 3rd party permission to make ajax calls to the 1st party domain, which may open up security holes.
  - jszymborski 8y ago
    You are totally right, but I'm wondering if we shouldn't change this practice. I'm starting to think if you're making a call to an external service, it should be proxied through your network. It'd increase bandwidth/latency, but you can be assured that the network calls your page are making are hitting the correct 3rd parties, and even inspect to see that the payloads are "correct". Edit: Surely, this at the very least should be the case for payment pages and banking websites.
    - asaph 8y ago
      > ... but you can be assured that the network calls your page are making are hitting the correct 3rd parties ... The browser's sandbox security model already does this for us with the same origin policy. > ... and even inspect to see that the payloads are "correct". This is what SRI already does for us.
      - jszymborski 8y ago
        To the second point, I was thinking of checking what came over the wire after AJAX calls from 3rd party JS (which may or may not have been loaded with SRI). I'll have to concede the first point... I was thinking that you can whitelist entire URLs to be fetched as opposed to domains, but on second thought, I don't think that'd be a meaningful change. Thanks, this has made me think a lot more on this, however :)
  - euroclydon 8y ago
    What? You must be talking about some opt-in sandboxing. What about the millions of sites that load jQuery from a CDN and then use $.ajax() to make requests to their home domain?
    - deleted 8y ago
      [deleted]
  - paraditedc 8y ago
    > Also, serving a 3rd party script from the 1st party's domain gives the 3rd party permission to make ajax calls to the 1st party domain, which may open up security holes. What do you mean? The 3rd script served from 3rd party domain will still execute under 1st party domain in the client's browser and that's the origin that the server sees. It doesn't prevent the scripts from calling 1st party server.
    - asaph 8y ago
      If a 3rd party's script loaded from the 3rd party domain initiates any execution on its own (without being invoked by script on the 1st party's site), it won't have permissions to make calls to the 1st party's domain. Moving the 3rd party script to the 1st party domain opens this up. Update: Given the responses, I'm starting to think I might be incorrect on this point. I'll admit, I'm working from memory here. I'll have to go back and validate this.
      - woogley 8y ago
        I have never heard of this. Can you share a link that goes into detail about this behavior? I don't immediately see anything on MDN's same-origin page talking about it
        benmmurphy 8y ago
        I'm 99% sure this is not a thing and if it was it would be incredibly broken and not secure and most non-trivial pages relying on it for security would be vulnerable to the third party script. Anyway. This can easily be proved one way or another. `Here is an example that shows a third party script accessing a first party domain. There is no CORs as far as I can see: https://jsfiddle.net/aopmtn46/ https://jsfiddle.net/aopmtn46/ If you open the console you will see "STATUS 404" which is not possible if same origin on third party scripts is enforced.
        woogley 8y ago
        thank you for this test!
mnarayan01 8y ago
> 3rd parties should version their JavaScript resources with a version number in the URL I mean yes this is true, but it seems almost totally orthogonal to SRI (which is aimed at security AIUI), particularly given you can give more than one hash for a particular resource. If for some reason a third-party can't use fingerprinted URLs, they can still update the resource provided they give "sufficient" advanced notification of the new fingerprint to clients. > And this should be a manual process because automating it would defeat the whole point of SRI. Obviously it should be offline/write-once, but unless you're reviewing the actual assets as well I'm not sure I see the need to avoid automation.
- asaph 8y ago
  Without versioned assets, both the 3rd and 1st parties would need to make the update at the exact same time or else the enforced SRI would cause failures. This kind of tight coordination is impractical or even impossible. Versioned assets allow you to deploy updates when using SRI without breaking anything. The need to avoid automation stems from the fact that an automated process which simply detects that a change has been made and blindly updates the SRI attribute with a new hash would let a malicious code update through, which normally SRI would have blocked. This situation is no different than not using SRI at all.
  - mnarayan01 8y ago
    You can specify multiple digests for an asset, so a non-versioned one can be updated sans downtime: 1. Provider informs clients that a new version with digest X will be deployed. 2. Clients add the new digest in addition to the current digest. 3. Provider switches to new asset version. 4. Clients remove old digest (optional). Versioned assets are obviously better unless you're in a really weird situation, but SRI doesn't particularly require them.
    - asaph 8y ago
      Thank you for letting me know that you can use multiple hashes in SRI. I didn't know you could do that.

by asaph 8y ago

amelius 8y ago

Why not just copy the file, inspect it, and serve it from your own servers?

asaph 8y ago
It's because that can break the site due to the browser's sandbox permissions model. Scripts are only allowed to make ajax calls to their origin servers. Also, serving a 3rd party script from the 1st party's domain gives the 3rd party permission to make ajax calls to the 1st party domain, which may open up security holes.
- jszymborski 8y ago
  You are totally right, but I'm wondering if we shouldn't change this practice. I'm starting to think if you're making a call to an external service, it should be proxied through your network. It'd increase bandwidth/latency, but you can be assured that the network calls your page are making are hitting the correct 3rd parties, and even inspect to see that the payloads are "correct". Edit: Surely, this at the very least should be the case for payment pages and banking websites.
  - asaph 8y ago
    > ... but you can be assured that the network calls your page are making are hitting the correct 3rd parties ... The browser's sandbox security model already does this for us with the same origin policy. > ... and even inspect to see that the payloads are "correct". This is what SRI already does for us.
    - jszymborski 8y ago
      To the second point, I was thinking of checking what came over the wire after AJAX calls from 3rd party JS (which may or may not have been loaded with SRI). I'll have to concede the first point... I was thinking that you can whitelist entire URLs to be fetched as opposed to domains, but on second thought, I don't think that'd be a meaningful change. Thanks, this has made me think a lot more on this, however :)
- euroclydon 8y ago
  What? You must be talking about some opt-in sandboxing. What about the millions of sites that load jQuery from a CDN and then use $.ajax() to make requests to their home domain?
  - deleted 8y ago
    [deleted]
- paraditedc 8y ago
  > Also, serving a 3rd party script from the 1st party's domain gives the 3rd party permission to make ajax calls to the 1st party domain, which may open up security holes. What do you mean? The 3rd script served from 3rd party domain will still execute under 1st party domain in the client's browser and that's the origin that the server sees. It doesn't prevent the scripts from calling 1st party server.
  - asaph 8y ago
    If a 3rd party's script loaded from the 3rd party domain initiates any execution on its own (without being invoked by script on the 1st party's site), it won't have permissions to make calls to the 1st party's domain. Moving the 3rd party script to the 1st party domain opens this up. Update: Given the responses, I'm starting to think I might be incorrect on this point. I'll admit, I'm working from memory here. I'll have to go back and validate this.
    - woogley 8y ago
      I have never heard of this. Can you share a link that goes into detail about this behavior? I don't immediately see anything on MDN's same-origin page talking about it
      - benmmurphy 8y ago
        I'm 99% sure this is not a thing and if it was it would be incredibly broken and not secure and most non-trivial pages relying on it for security would be vulnerable to the third party script. Anyway. This can easily be proved one way or another. `Here is an example that shows a third party script accessing a first party domain. There is no CORs as far as I can see: https://jsfiddle.net/aopmtn46/ https://jsfiddle.net/aopmtn46/ If you open the console you will see "STATUS 404" which is not possible if same origin on third party scripts is enforced.
        woogley 8y ago
        thank you for this test!

mnarayan01 8y ago

> 3rd parties should version their JavaScript resources with a version number in the URL I mean yes this is true, but it seems almost totally orthogonal to SRI (which is aimed at security AIUI), particularly given you can give more than one hash for a particular resource. If for some reason a third-party can't use fingerprinted URLs, they can still update the resource provided they give "sufficient" advanced notification of the new fingerprint to clients. > And this should be a manual process because automating it would defeat the whole point of SRI. Obviously it should be offline/write-once, but unless you're reviewing the actual assets as well I'm not sure I see the need to avoid automation.

asaph 8y ago
Without versioned assets, both the 3rd and 1st parties would need to make the update at the exact same time or else the enforced SRI would cause failures. This kind of tight coordination is impractical or even impossible. Versioned assets allow you to deploy updates when using SRI without breaking anything. The need to avoid automation stems from the fact that an automated process which simply detects that a change has been made and blindly updates the SRI attribute with a new hash would let a malicious code update through, which normally SRI would have blocked. This situation is no different than not using SRI at all.
- mnarayan01 8y ago
  You can specify multiple digests for an asset, so a non-versioned one can be updated sans downtime: 1. Provider informs clients that a new version with digest X will be deployed. 2. Clients add the new digest in addition to the current digest. 3. Provider switches to new asset version. 4. Clients remove old digest (optional). Versioned assets are obviously better unless you're in a really weird situation, but SRI doesn't particularly require them.
  - asaph 8y ago
    Thank you for letting me know that you can use multiple hashes in SRI. I didn't know you could do that.