Media Source URL defined in iframe sandbox being blocked
Reported by
fwy1...@gmail.com,
Jan 29 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: 1. Code: https://gist.github.com/anonymous/b016c856b9f667112cdc3b90fed5a0ad 2. python -m SimpleHTTPServer visit http://127.0.0.1:8000/out.html What is the expected behavior? [inside sandbox] Source Created! in.html:23:9 What went wrong? Chrome blocks the script from accessing that mediasource URL. Not allowed to load local resource: blob:null/a8c584d3-bcd1-4c5a-8d4a-f912a4f1a0c6 Did this work before? N/A Does this work in other browsers? Yes Chrome version: 55.0.2883.87 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 24.0 r0 Hello! I am writing a JavaScript program that runs in an iframe sandbox. It creates a Media Source (via Media Source Extensions API) inside the iframe, and tries to append data to its buffer. Code: https://gist.github.com/anonymous/b016c856b9f667112cdc3b90fed5a0ad $ python -m SimpleHTTPServer http://127.0.0.1:8000/out.html Chrome blocks the script from accessing that mediasource URL. ``` Not allowed to load local resource: blob:null/a8c584d3-bcd1-4c5a-8d4a-f912a4f1a0c6 ``` but Firefox does not block it. ``` [inside sandbox] Source Created! in.html:23:9 ``` Then I closed Chrome, restarted it with `google-chrome --allow-file-access-from-files`, but I had the same problem. It didn't help. Since the iframe is sandboxed, the mediasource URL starts with `blob:null/`, but after all the script inside the iframe is creating a mediasource URL inside the iframe. It does not induce any network traffic. It does not try to access any resources outside the iframe. I believe it should not considered as a cross-origin request. A [relevant issue](https://bugs.chromium.org/p/chromium/issues/detail?id=379206) was opened two years ago, but was closed due to lack of response from the bug reporter. This sandbox configuration is actually from [ZeroNet](https://zeronet.io). WebTorrent is [affected](https://github.com/feross/webtorrent/issues/783) by this Chrome bug. Best, [ZeroMux](mai1to ZeroMux__at__tuta dot io) dev
,
Feb 3 2017
Ack, posted my comment to the wrong bug. No idea on this one at the moment.
,
Feb 4 2017
I defer to the security experts on this one. It looks like the canDisplay(url) check in https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp?rcl=a51779b5e41d1d8e1498e8dc10d4795b5988515f&l=1339 is saying "no" (from log on a local repro:) selectMediaResource(...) MDW frame=(non-null) document().getSecurityOrigin()->canDisplay(url)=0 isSafeToLoadURL(..., "blob:null/65298a9f-5dfa-4be8-8a9a-cb4c77b34957") -> FALSE rejected by SecurityOrigin noneSupported(...)
,
Feb 4 2017
,
Feb 6 2017
Mike, thoughts on this, c#4? Could one of the teams triage this and update the right component?
,
Feb 6 2017
Internals>Media>Source looks correct. Dropping the others.
,
Feb 6 2017
,
Feb 7 2017
mkwst: Can you please check my interpretation of the specs below? The Media Source Extensions spec defers to the File API spec for URL.createObjectURL() [1]. Blob URLs must be created with the same origin as the incumbent settings object [2, 3]. This should actually read the "current settings object" [4]. This ends up being the document's settings object (mild handwaving here), which contains an unique opaque origin [5]. This origin is then serialized as "null" when forming the blob's URL. Superficially, it seems like this issue is an undesirable effect of the blob's origin having to round-trip through URL serialization before the security checks are performed. However, the URL spec states that when parsing blob: URLs, we should use the blob ID in the path to look up the Blob in the registry, and return a structured clone of the blob URL stored there [6]. This would mean the unique opaque origin compares equal to the request's current origin in step 11 of a main fetch, as specified in the Fetch spec [7]. Long story short, we seem to be in the wrong here. [1] https://w3c.github.io/media-source/#url [2] https://w3c.github.io/FileAPI/#originOfBlobURL [3] https://html.spec.whatwg.org/multipage/webappapis.html#environment-settings-object [4] https://github.com/w3c/FileAPI/issues/60 [5] https://html.spec.whatwg.org/multipage/browsers.html#concept-origin [6] https://url.spec.whatwg.org/#url-parsing [7] https://fetch.spec.whatwg.org/#main-fetch
,
Feb 7 2017
matt, can you take a look c#9?
,
Feb 7 2017
Actually, it seems to me that we're doing the right thing at the File API level. Blob URLs are read correctly even in sandboxed iframes. WPT test CL: http://crrev.com/2678223002 This makes me guess that the bug lies in MediaSource code.
,
Feb 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9fa1e2b8da2b53ab1fbdfe85fc46227d3920913c commit 9fa1e2b8da2b53ab1fbdfe85fc46227d3920913c Author: pwnall <pwnall@chromium.org> Date: Wed Feb 08 03:13:05 2017 WPT test for reading Blob URLs minted in iframes w/ and w/o sandboxing. BUG=686516 Review-Url: https://codereview.chromium.org/2678223002 Cr-Commit-Position: refs/heads/master@{#448886} [add] https://crrev.com/9fa1e2b8da2b53ab1fbdfe85fc46227d3920913c/third_party/WebKit/LayoutTests/external/wpt/FileAPI/url/blob-url-in-sandboxed-iframe.html [modify] https://crrev.com/9fa1e2b8da2b53ab1fbdfe85fc46227d3920913c/third_party/WebKit/LayoutTests/external/wpt/MANIFEST.json |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by phistuck@chromium.org
, Feb 2 2017Status: Untriaged (was: Unconfirmed)