5 ms·

Not just CDN, there's benefits to rolling out SRI for lots of your third parties. Your stripe js, scary ad networks js, front-end analytics companies. SRI is r

by ejcx 10y ago

Not just CDN, there's benefits to rolling out SRI for lots of your third parties. Your stripe js, scary ad networks js, front-end analytics companies. SRI is really neat and helps protect yourself from these many 3rd parties being pwned.

untog 10y ago
Except that when the third party changes that script you'll stop loading it. Unless they adopt strict versioning in their files you'll have to be careful.
- bpicolo 10y ago
  And they won't, because (reasonable so) being update-able is half the point of the way they're doing it.
hdhzy 10y ago
SRI may be a double edged sword. What if stripe fixes a bug and rolls a new version of their JS? Your page stops accepting payments. That's bad. If jQuery is compromised you'll detect it and download from different location but for stripe there is no fallback.
- cryptarch 10y ago
  Well, if Stripe wants you to stop accepting payments, you will. They already can take the resource offline, I don't see how this is a new/additional problem. If they want you to stay up-to-date, they'll provide a piece of PHP/Node that emits the latest URL/SRI tag.
  - LukeShu 10y ago
    You, as the web developer, want to start using subresource-integrity. Stripe, as a depended-upon 3rd party, has not yet bought in to subresource-integrity hype-train. Stripe rolls out a fix for a security issue or other bug in their JS. This breaks your subresource-integrity check. The didn't want you to stop accepting payments, they wanted to fix a vuln. That hampers the usefulness of using subresource-integrity on 3rd-party resources today (which is what yeldarb suggested). Perhaps in the future the 3rd party would provide a script that emits the URL/SRI, but that isn't today.
    - jffry 10y ago
      the 3rd party would provide a script that emits the URL/SRI And we're back to square one - we can't trust _that_ script to not get pwned
      - cryptarch 10y ago
        Not really, isn't packaging and securely distributing PHP/Node.js libraries a solved problem?
        johncolanduoni 10y ago
        If you're not updating the PHP/Node.js library, and you're not updating any data you give it, where does it get the information it needs to update the URL/SRI tag? And if you are doing any of those things when Stripe pushes an update, how is it any different that having to update the URL/SRI tag?
    - cryptarch 10y ago
      Ok, so how about caching the Stripe script and serving it yourself, then polling for new versions and then updating the cache and the SRI? You might break payment for $polling_interval if the script is incompatible with Stripe's server, so perhaps you could have retry logic there, to bridge $polling_interval more smoothly. You could also manually review the new Stripe code this way, by polling only by hand or by not automatically updating the cache and SRI.
  - mmarx 10y ago
    > If they want you to stay up-to-date, they'll provide a piece of PHP/Node that emits the latest URL/SRI tag. Then how do you verify the integrity the integrity for the tag?
MichaelBurge 10y ago
I thought those 3rd-party links are just to make it easier to get started. I've been checking Javascript files into my project repository, since it seemed unwise to add N different points of failure for no reason. And anything important like your financial provider is usually very risk-averse to breaking changes, and should give plenty of notice for an update. And if you're including a hash, you don't care about automatic updates anyways. I can understand trusting one CDN for performance reasons. But do people really add so many different dependencies on their sites? Should I be doing that instead?
- hdhzy 10y ago
  I don't think so. Especially with HTTP 2 fetching resources from the same domain will be very fast. I guess the main audience of CDNs are huge sites that will see immediate benefits. For them SRI is good. But using CDN from day 1 seems to me like a premature optimization. SRI solves some problems (CDN compromise) in exchange for different set of problems (resource not loaded, what now?). And old saying comes to mind... "I had a problem and decided to use regular expressions... Now I have two problems".

by ejcx 10y ago

untog 10y ago

Except that when the third party changes that script you'll stop loading it. Unless they adopt strict versioning in their files you'll have to be careful.

bpicolo 10y ago
And they won't, because (reasonable so) being update-able is half the point of the way they're doing it.

hdhzy 10y ago

SRI may be a double edged sword. What if stripe fixes a bug and rolls a new version of their JS? Your page stops accepting payments. That's bad. If jQuery is compromised you'll detect it and download from different location but for stripe there is no fallback.

cryptarch 10y ago
Well, if Stripe wants you to stop accepting payments, you will. They already can take the resource offline, I don't see how this is a new/additional problem. If they want you to stay up-to-date, they'll provide a piece of PHP/Node that emits the latest URL/SRI tag.
- LukeShu 10y ago
  You, as the web developer, want to start using subresource-integrity. Stripe, as a depended-upon 3rd party, has not yet bought in to subresource-integrity hype-train. Stripe rolls out a fix for a security issue or other bug in their JS. This breaks your subresource-integrity check. The didn't want you to stop accepting payments, they wanted to fix a vuln. That hampers the usefulness of using subresource-integrity on 3rd-party resources today (which is what yeldarb suggested). Perhaps in the future the 3rd party would provide a script that emits the URL/SRI, but that isn't today.
  - jffry 10y ago
    the 3rd party would provide a script that emits the URL/SRI And we're back to square one - we can't trust _that_ script to not get pwned
    - cryptarch 10y ago
      Not really, isn't packaging and securely distributing PHP/Node.js libraries a solved problem?
      - johncolanduoni 10y ago
        If you're not updating the PHP/Node.js library, and you're not updating any data you give it, where does it get the information it needs to update the URL/SRI tag? And if you are doing any of those things when Stripe pushes an update, how is it any different that having to update the URL/SRI tag?
  - cryptarch 10y ago
    Ok, so how about caching the Stripe script and serving it yourself, then polling for new versions and then updating the cache and the SRI? You might break payment for $polling_interval if the script is incompatible with Stripe's server, so perhaps you could have retry logic there, to bridge $polling_interval more smoothly. You could also manually review the new Stripe code this way, by polling only by hand or by not automatically updating the cache and SRI.
- mmarx 10y ago
  > If they want you to stay up-to-date, they'll provide a piece of PHP/Node that emits the latest URL/SRI tag. Then how do you verify the integrity the integrity for the tag?

MichaelBurge 10y ago

I thought those 3rd-party links are just to make it easier to get started. I've been checking Javascript files into my project repository, since it seemed unwise to add N different points of failure for no reason. And anything important like your financial provider is usually very risk-averse to breaking changes, and should give plenty of notice for an update. And if you're including a hash, you don't care about automatic updates anyways. I can understand trusting one CDN for performance reasons. But do people really add so many different dependencies on their sites? Should I be doing that instead?

hdhzy 10y ago
I don't think so. Especially with HTTP 2 fetching resources from the same domain will be very fast. I guess the main audience of CDNs are huge sites that will see immediate benefits. For them SRI is good. But using CDN from day 1 seems to me like a premature optimization. SRI solves some problems (CDN compromise) in exchange for different set of problems (resource not loaded, what now?). And old saying comes to mind... "I had a problem and decided to use regular expressions... Now I have two problems".