whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.17k stars 2.69k forks source link

Should blob: inherit CSP in addition to origin? #2593

Open bzbarsky opened 7 years ago

bzbarsky commented 7 years ago

I see nothing involving CSP anywhere in https://w3c.github.io/FileAPI/ and I don't see the blob steps in https://fetch.spec.whatwg.org/#basic-fetch doing anything with CSP. There's nothing in the HTML spec that would give blob: any particular CSP.

So it looks to me like things loaded from blob: do not have CSP applying to them, per spec.

Using this testcase:

<!DOCTYPE html>
<meta http-equiv="Content-Security-Policy" content="img-src 'self'">
<iframe></iframe>
<script>
  const imageURL = "http://software.hixie.ch/resources/style/2010/trains.jpeg"
  function insertImage(doc) {
    var img = doc.createElement("img");
    img.src = imageURL;
    img.alt = "I am not here";
    doc.body.appendChild(img);
  }
  onload = function() {
    insertImage(document);
    var blob = new Blob(["<img alt='blob' src='" + imageURL + "'>"], { type: "text/html" });
    var url = URL.createObjectURL(blob);
    frames[0].location = url;
  }
</script>

I see the following behavior:

bzbarsky commented 7 years ago

I guess this is kinda handled in https://w3c.github.io/webappsec-csp/#initialize-document-csp sorta. But that's using the CSP of the parent or opener, not the CSP of wherever the blob came from, which is a bit odd.

bzbarsky commented 7 years ago

And clearly at least Safari found this none too clear...

//cc @mikewest

domenic commented 3 years ago

Same as https://github.com/whatwg/html/issues/2592#issuecomment-868017904 , this is probably fixed in the spec but unsure if it's fully tested.

annevk commented 3 years ago

I think we can duplicate this against https://github.com/w3c/FileAPI/issues/142 and #4926, but I'm okay with keeping it open if we want a dedicated tracking issue.

wert310 commented 3 years ago

Hi, I'm reading through the spec to understand the inheritance behavior for local schemes. I'm still trying to figure out if the correct behavior for blob: URLs is to inherit the CSP from the URL creator or to inherit it from the navigation initiator.

this is probably fixed in the spec

According to browsing-the-web.html#navigating-across-documents, "determine navigation params policy container" is called after "create a policy container from a fetch response", so a blob URL would not inherit the responsePolicyContainer ("a clone of response's URL's blob URL entry's environment's policy container") but the initiatorPolicyContainer (step 3 of "determine navigation params policy container" origin.html#policy-containers).

This matches the CSP spec (#security-inherit-csp) but seems to contradict the behavior defined for blob URLs in @antosart's policy container explainer. Am I reading it wrong?

but unsure if it's fully tested

In wpt/content-security-policy/inheritance, all tests concerning blob: URLs do not differentiate the creation and navigation steps. I quickly tested the behavior by modifying blob-url-inherits-from-initiator.sub.html so that createObjectURL and window.location are executed in two different same-origin iframes (see wert310/wpt/blob-url-inherits-from-creator). In the current dev versions of Chrome (93.0.4573.0) and Firefox (92.0a1), blob: URLs do not inherit from the creator of the URL but from the initiator of the navigation.

If the plan is to inherit the policy from the creator, the CSP of the navigator could be stripped by navigating to a blob: whose creator does not have a CSP. I see this as a variation of bugs.chromium/894228 where the policy of the inner frame is discarded and replaced with a weaker one after the navigation.

antosart commented 3 years ago

The goal is to inherit the policies from the creator. I believe you are right and there is a bug in the spec. I created #6895 to fix this.

Regarding tests, you are right that we don't have specific tests for this. The problem in writing tests here is that no vendor (at least that I know of) implements this at the moment, although in chrome we would like to address this at some point. (Note that since blob URLs can only be navigated from the same-origin, I believe the security implications of this are very low.)

I think we should merge the tests you created, though, even if they are failing on all vendors.