Bug 170075 – Cannot read blobs in sandboxed iframes

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Jimmy Wärting]

Blobs can't be read in sandboxed iframes with allow-scripts

"[blocked] The page at https://jsfiddle.net/bgh27rre/1/ was not allowed to display insecure content from blob:null/39cc8f5e-0ff2-4435-8e82-eedb3ce3091c."

https://jsfiddle.net/bgh27rre/1/
https://github.com/Fyrd/caniuse/issues/3266
https://github.com/github/fetch/issues/481

[Jimmy Wärting]

Only apply to secure pages (https)

[Radar WebKit Bug Importer]

<rdar://problem/31282427>

[John Firebaugh]

This effectively prevents the use of web workers within <iframe sandbox="allow-scripts">:

1. Initializing the Worker with a blob URI doesn't work due to this bug.
2. Initializing the Worker with a http[s] URI doesn't work because without allow-same-origin, the iframe has a null origin, and Worker scripts are required to be same-origin.
3. WebKit does not support initializing the Worker with a data URI.

[Adam Podolnick]

This is still an issue in Safari 12.1 on Mojave.

[Kallyn Gowdy]

This is also an issue in Mobile Safari on iOS 12.3.1.

A workaround is to add the allow-same-origin option to the sandbox attribute, but as stated in the spec (http://w3c.github.io/html/semantics-embedded-content.html#element-attrdef-iframe-sandbox), this defeats the purpose of using the sandbox attribute.

[Tim Guan-tin Chien [:timdream]]

Created attachment 408940 [details]
test case

Made a demo and was going to file, but based on comment 3 this is already filed.

[youenn fablet]

Right, the issue is that the blob URL is something like blob://null/UUID so is considered "Not TrustedWorthy".
Chrome and Firefox seems to be treating it as trustworthy, probably because the context that created the blob is secure context.

I filed https://github.com/w3c/webappsec-mixed-content/issues/41 to clarify this since the specs are not super clear to me.

[youenn fablet]

Created attachment 421924 [details]
Patch

[youenn fablet]

Created attachment 421960 [details]
Patch

[Jimmy Wärting]

I almost forgot.
I have a new similar issue. Maybe it will get resolved in same patch but here is another test case

The top (secure) page sends a blob that have been generated and wants a sandboxed iframe to execute it safely. 
This is also not possible in safari, but works in other browsers. My current solution is to create a script with text content instead...

This kind of blob should be flagged as secure? so even if the iframe acted as secure or not it should still run it either way since this blob is made from a secure origin?

Demo https://jsfiddle.net/ekraqvw1/

the xhr.responseType = 'blob' problem in iframes is long forgotten - but still a issue

[youenn fablet]

(In reply to Jimmy Wärting from comment #10)
> I almost forgot.
> I have a new similar issue. Maybe it will get resolved in same patch but
> here is another test case
> 
> The top (secure) page sends a blob that have been generated and wants a
> sandboxed iframe to execute it safely. 
> This is also not possible in safari, but works in other browsers. My current
> solution is to create a script with text content instead...
> 
> This kind of blob should be flagged as secure? so even if the iframe acted
> as secure or not it should still run it either way since this blob is made
> from a secure origin?
> 
> Demo https://jsfiddle.net/ekraqvw1/

This is most probably the same issue.

[EWS]

Committed r273879: <https://commits.webkit.org/r273879>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 421960 [details].

[Aleksandr Dobkin]

The demo (https://jsfiddle.net/bgh27rre/1/) continues to reproduce iOS Safari 14.7.1.  Can you confirm when the fix will land?