Category Archives: same origin policy

Can someone elaborate on the attacks alluded to in this paragraph from the W3C SubResource Integrity spec?

In order to mitigate an attacker’s ability to read data cross-origin by brute-forcing values via integrity checks, responses are only eligible for such checks if they are same-origin or are the result of explicit access granted to the loading origin via Cross Origin Resource Sharing [CORS].

To me, it comes across as nonsensical because:

1. My reading of “read data cross-origin by brute-forcing values” suggests it’s an attack against the server.
2. A non-browser user agent can always fetch from a server without CORS.
3. I don’t see how adding hash verification presents a new threat that CORS mitigates when unverified cross-origin CSS and JavaScript retrieval predate CORS and must be supported for legacy compatibility.

On a more practical level, I ask because:

1. It feels as if user tracking via SRI Origin+IP has the potential to become a partial workaround for the growing ability to suppress (sites) or forge (browsers) Referer headers for protection against Referer+IP tracking (a reason I always self-host my subresources to avoid hypocrisy).
2. I’m wondering whether there would be any increased security risk to me if I were to complement my existing browser extensions like Decentraleyes with a more general solution based on requesting a CSS or JavaScript resource using the pre-CORS set of headers (paired with Referer forging), but then enforcing the provided hash anyway.

EDIT: While @Anders answered the rationale for using it with credentialed requests (ie. requests with session cookies or similar), that doesn’t explain why crossorigin="anonymous" is acceptable for doing integrity checks on <script> and <link rel="stylesheet">, but omitting the crossorigin attribute altogether is not.

If the attack involves using onload or onerror to extract one bit of information based on whether the subresource matches a hash, then doing it with crossorigin="anonymous" is a class of attacks that are already possible for CSS and JavaScript subresources by setting an onload on an SRI-free subresource and then examining whether they have modified the DOM or its rendering.

Continue reading What attacks are mitigated by requiring CORS for subresource integrity verification?→