3 ms·

I don't imagine any browser vendor implementing this at all. A hash collision seems unlikely but if it can be constructed, the results are potentially disastrou

I don't imagine any browser vendor implementing this at all. A hash collision seems unlikely but if it can be constructed, the results are potentially disastrous. No one else should be able to decide where code from site is loaded except me. "pretty sure" isn't really good enough.

sarciszewski 11y ago
Not sure why this is being downvoted. It's a reasonable point.
- icebraining 11y ago
  It's not. If browser vendors thought that the potential for breaking a decent hash function was a real threat, they would also not implement HTTPS, signed updates, etc, all of which depend on the trust in hash based signatures.
  - sarciszewski 11y ago
    I, for one, welcome EdDSA signing of Javascript resources.
icebraining 11y ago
Then developers who feel the same can simply not add any hash to their <script> tags, no?
- michaelmior 11y ago
  Yes. And then not the security benefits that subresource integrity is intended to provide.
  - icebraining 11y ago
    HTTPS, code and binaries signing, etc all depend on the fact that getting a malicious message with a hash signature that collides with another arbitrary message is all but impossible. If you don't trust that, you're pretty much unable to trust anything that's transmitted over the 'net, and this potential hole is not significant in that context.
    - michaelmior 11y ago
      That's a fair point. But it still increases the attack surface for questionable gain. You're not just relying on the attacker being unable to create a hash collision. You're also relying on all browsers to provide a correct implementation of this code sharing mechanism. Allowing this sort of code sharing provides another attack vector. If a malicious site is able to exploit a browser vulnerability that allows it to populate the shared cache, then you've suddenly enabled code injection on any site using subresource integrity.

sarciszewski 11y ago

Not sure why this is being downvoted. It's a reasonable point.

icebraining 11y ago
It's not. If browser vendors thought that the potential for breaking a decent hash function was a real threat, they would also not implement HTTPS, signed updates, etc, all of which depend on the trust in hash based signatures.
- sarciszewski 11y ago
  I, for one, welcome EdDSA signing of Javascript resources.

icebraining 11y ago

Then developers who feel the same can simply not add any hash to their <script> tags, no?

michaelmior 11y ago
Yes. And then not the security benefits that subresource integrity is intended to provide.
- icebraining 11y ago
  HTTPS, code and binaries signing, etc all depend on the fact that getting a malicious message with a hash signature that collides with another arbitrary message is all but impossible. If you don't trust that, you're pretty much unable to trust anything that's transmitted over the 'net, and this potential hole is not significant in that context.
  - michaelmior 11y ago
    That's a fair point. But it still increases the attack surface for questionable gain. You're not just relying on the attacker being unable to create a hash collision. You're also relying on all browsers to provide a correct implementation of this code sharing mechanism. Allowing this sort of code sharing provides another attack vector. If a malicious site is able to exploit a browser vulnerability that allows it to populate the shared cache, then you've suddenly enabled code injection on any site using subresource integrity.