search

w3c / webappsec-subresource-integrity

WebAppSec Subresource Integrity
https://w3c.github.io/webappsec-subresource-integrity/
Other
70 stars 35 forks source link

Idea: Add Integrity Request Header #123

Open tetsuyainfra opened 4 months ago

tetsuyainfra commented 4 months ago

Hello. I recently learned of the polyfill.io malware issue.

Currently, SRI is supported in all major browsers. Therefore, if the integrity attribute is specified correctly, it is possible to prevent the execution of malicious scripts on the client side.

I believe that this issue is cases where scripts for which the integrity attribute is not specified are later pollutioned.

If a server error could be returned when loading a script for which the integrity attribute is not specified, developers would have no choice but to specify the attribute in the HTML.

<script
  src="https://example.com/example-framework.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC">
  </script>
GET /xample-framework.js
Integrity: sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7
...

HTTP/1.1 200 OK
...

It would be ineffective if the server cannot be trusted from the start, but I think the specification can be added without much impact.

Related: https://lists.w3.org/Archives/Public/public-webappsec/2017Jun/0000.html

mozfreddyb commented 4 months ago

I think the same can be achieved with a CSP script-src directive, no?