What attacks are mitigated by requiring CORS for subresource integrity verification?
The Same Origin Policy is the cornerstone of the client-side security model of the web through the isolation of user data. As you already know, CORS relaxes the default SOP restrictions. Without relaxing these restrictions, the origin site has no right to inspect responses, including the integrity of a resource via the
email = "[email protected]";
Onto your other points:
A non-browser user agent can always fetch from a server without CORS.
Client-side attacks always require the victim browser to play their part because it will supply the cookies in a credentialed request, or if another type of authentication mechanism is used (e.g. IP), then it will supply the victim's IP in a non-credentialled request. The attacker is not the one choosing the user agent, so taking non-browsers into the equation is a moot point.
I don't see how adding hash verification presents a new threat that
retrieval predate CORS and must be supported for legacy compatibility.
This is incorrect. Nothing legacy allows the reading of external resources by code. Yes, the browser itself can use JS and CSS external to the top level site, however this is not considered a CORS request because script from the origin is not reading the response - it's only the browser itself for rendering and for executing any script.
In my example above, there would be no way for the requesting origin site to read the literal code
email = "[email protected]";, even before subresource integrity came about. If the
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 and , but
omitting the crossorigin attribute altogether is not.
Remember, there are two crossorigin possible values:
Because CORS is required on the external origin, it makes sense to specify the expected one in the current origin.
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
onload on an SRI-free subresource and then examining whether they have
modified the DOM or its rendering.
naughty_or_nice.png returned whether the user was good or bad based upon IP address rather than login credentials, then
crossorigin="anonymous" would be fine, and the integrity of the resource could be checked if
Otherwise it needs to be
santaclause.com must output
Access-Control-Allow-Credentials: true as well as the ACAO header.
In the first example, the remote site can still control security. It still can examine the
Origin request header and allow or deny the request with its CORS header. In the second, it just needs to apply its authorisation rules as normal.
So to sum up, the
crossorigin tag is required so that the correct CORS header is sent (
Origin), and if the external site allows (via CORS), the
integrity tag allows the browser examine the response on behalf of the originating site.
crossorigin = I'm sending, and I expect either ACAO or ACAO and ACAC in response.
integrity = I'm receiving, and I'll check the hash from the external Origin if the aforementioned headers are appropriately returned.