Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
bzbarsky opened this issue Apr 26, 2017 · 6 comments
Open

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

bzbarsky opened this issue Apr 26, 2017 · 6 comments
Labels
integration Better coordination across standards needed

Comments

@bzbarsky
Copy link
Contributor

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:

  • Safari loads the image in the blob document
  • Firefox and Chrome do not load the image in the blob document (but do without the CSP on the parent)
  • Edge doesn't seem to load the image no matter whether I use CSP (??)
@bzbarsky
Copy link
Contributor Author

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
Copy link
Contributor Author

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

//cc @mikewest

@annevk annevk added the integration Better coordination across standards needed label Jan 22, 2018
@annevk annevk mentioned this issue Apr 23, 2019
Open
@koto koto mentioned this issue Jun 3, 2020
Closed
@domenic domenic mentioned this issue Dec 24, 2020
Open
@domenic
Copy link
Member

domenic commented Jun 24, 2021

Same as #2592 (comment) , this is probably fixed in the spec but unsure if it's fully tested.

@annevk
Copy link
Member

annevk commented Jun 25, 2021

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

@wert310
Copy link

wert310 commented Jul 22, 2021

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
Copy link
Member

antosart commented Jul 23, 2021 •
edited
Loading

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
integration Better coordination across standards needed
Milestone
No milestone
Development

No branches or pull requests
5 participants
@domenic @bzbarsky @annevk @antosart @wert310