1626566 - Blob URLs do not inherit CSP from originating page

Status: NEW

(Core :: DOM: File, enhancement, P3)

Description

[Jun (Request needinfo for comment, I ignore other updates)]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36

Steps to reproduce:

1. Go to https://vuln.shhnjk.com/blob_csp.html
2. Copy Blob URL and paste it into address bar
3. Press enter

Actual results:

CSP is bypassed.

Expected results:

https://github.com/w3c/FileAPI/issues/142

Comment 1

[:Gijs (he/him)]

I'm a little confused about the threat model here - this would only pose a risk to sites with a CSP, that also produce their own blob URLs with vulnerable content and expose those to users, that would then be exploited in a way where the attacker is able to convince the users to copy said blob URLs to the location bar and run them "manually", right? Like, if there's inline-script restrictions on the original site, you'd face a bootstrapping problem in terms of getting a blob URL with malicious content going yourself, because doing so requires calling createObjectURL, which you can't do if you can't run script on that origin... or am I missing something?

Potentially related: bug 1570889.

Comment 2

[Jun (Request needinfo for comment, I ignore other updates)]

This is an example. I've seen a site where they'd render user uploaded SVG image in img tag with Blob URL (by fetching uploaded content). That would also cause same thing as here. Sadly, many website relies on Blob URL for many contents.

Other portion of your comment is right, that attacker still has to convince user to copy and paste Blob URL. But imagining above SVG image example, I do sometime copy URL of image and re-render it in a tab so that I can see a bigger image (is it only me? :P).

Unfortunately, Firefox doesn't support opening Blob URL with Ctrl + Click, so this attack vector was only option I could find.

Anyways, this should be good another push to implement https://github.com/w3c/FileAPI/issues/142.

Comment 3

[:Gijs (he/him)]

(In reply to Jun from comment #2)

Unfortunately, Firefox doesn't support opening Blob URL with Ctrl + Click, so this attack vector was only option I could find.

It looks like we prevent this precisely because of the CSP, in this case - a tab opens for me on other examples, e.g. the "open the array URL" link from the demo on https://developer.mozilla.org/en-US/docs/Web/API/Blob . Though the page is empty... which seems like a different (non-security) bug.

Edit: filed bug 1626573 for this.

Comment 4

[Anne (:annevk)]

As this is publicly disclosed (and a flaw in the standard), I don't think this bug needs to be hidden, but it would be good to implement the model I outlined in that issue (I'm biased, though).

Comment 5

[Daniel Veditz [:dveditz]]

Adding bounty flag at reporter's request.

Comment 6

[Tyson Smith [:tsmith]]

Opening bug since the GitHub issue exists.

Comment 7

[Daniel Veditz [:dveditz]]

Are blobs broken with fission? If I paste the testcase blob URL back into the same window it works (clicking it doesn't; why?). If I paste it into a new tab I get the "hmm, that URL doesn't look right" error page.

Comment 8

[Anne (:annevk)]

That's bug 1626573.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 10

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Comment 11

[Jens Stutte [:jstutte]]

(In reply to Jun from comment #2)

Anyways, this should be good another push to implement https://github.com/w3c/FileAPI/issues/142.

Should we consider this more an enhancement request rather than a defect?

Comment 12

[Anne (:annevk)]

I suppose. Either way it's something we'll eventually have to fix.