Closed Bug 1381728 Opened 2 years ago Closed 2 years ago
<object data="data:text/html,...> should have unique opaque origin
https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-object-element Step 4, If the data attribute is present and its value is not the empty string, then: ... Step 4.5 Fetch request. https://fetch.spec.whatwg.org/#main-fetch Step 12, request’s current url’s scheme is "data" HTML assigns any documents and workers created from URLs whose scheme is "data" a unique opaque origin. So <object data="data:text/html,.."> the object.contentDocument should have its own unique opaque origin. Also <object data="data:image/svg+xml,<svg>..</svg>"> https://html.spec.whatwg.org/multipage/embedded-content-other.html#svg-0 Returns the Document object, in the case of iframe, embed, or object elements being used to embed SVG images. Then this should back to the FETCH spec, "HTML assigns any documents and workers created from URLs whose scheme is "data" a unique opaque origin." In this case, object.getSVGDocument() should be cross-origin. However I am not sure for data:image,... in <object> <object data="data:image/png,..."> should this be treated as same origin or cross-origin? Because in the case of iframe, <iframe src="data:image/png,...">, it's cross origin, to my undestanding, in iframe, data:image/png is a "Document". However in Chrome browser, accessing <object data="data:image/png,...">.contentDocument doesn't throw, although it returns null , whereas accessing <object data="data:text/html,...">.contentDocument or <object data="data:image/svg+xml,...">.getSVGDocument() will throw. Boris, can you help to explain the case for <object data="data:image/png,...">? Thanks
2 years ago
<object data="data:image/png,..."> doesn't load a document. It loads an image, like <img src="data:image/png,...">. This is more obvious if you don't use a data: URI at all but a same-origin http(s) URI: you will still have a null .contentDocument, across all browsers. The relevant spec bit is as follows. Start at https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-object-element and scroll down to "queue a task to run the following steps to (re)determine what the object element represents" (not directly linkable, sadly; file a spec bug?). This creates a new request and fetches it via <https://fetch.spec.whatwg.org/#concept-fetch> in step 5, which calls <https://fetch.spec.whatwg.org/#concept-main-fetch>. At this point, the request mode is "no-cors", because nothing has changed it to be otherwise. Since the URL scheme is "data", response tainting is set to "basic" and https://fetch.spec.whatwg.org/#concept-scheme-fetch is called, which returns a response. Then we unwind to https://fetch.spec.whatwg.org/#concept-main-fetch step 13, follow to step 14, and create a basic filtered response (hence with type "basic"). Then we unwind back to the HTML spec. Back in the HTML spec, in step 8 we end up setting the resource type to "image/png" (in particular, in step 8.6.4, afaict). Then in step 9, "resource type" starts with "image/", so we discard the nested browsing context, if any, and decide that the <object> represents the image. OK, so once we have decided it represents an image, what are the consequences? 1. https://html.spec.whatwg.org/multipage/browsers.html#concept-bcc-content-document is null because there is no nested browsing context, so .contentDocument returns null. This would happen in Gecko no matter what you do with origins here. 2. You can't drawImage an <object> per the spec as it stands, so you can't tell whether it would taint the canvas if you did so. I feel that this is a bug in the spec, fwiw, but I'm pretty sure I've raised it before... So presumably it doesn't actually matter too much what origin you end up with in this case. If item 2 were changed so you could drawImage the image, then we'd want it to behave just like <img src="data:image/png,...">. Does that answer your question?
Thanks, that answers my question, it's really helpful.
So far this test will fail in the web-platform test http://searchfox.org/mozilla-central/source/testing/web-platform/tests/old-tests/submission/Opera/script_scheduling/100.html But looking at the test script, the data URI "parent.log" in the <object> shouldn't access the log function defined in http://searchfox.org/mozilla-central/source/testing/web-platform/tests/old-tests/submission/Opera/script_scheduling/testlib/testlib.js Anne, could you help to check this is the legacy test we also need to fix? Thanks
Yeah, given that it's in old-tests I'd r+ removal as well.
2 years ago
Attachment #8890371 - Flags: review?(bugs)
Did you check that testing/web-platform/tests/old-tests/submission/Opera/script_scheduling/scripts/include-12.js is not linked from any other tests? r+ if so.
Comment on attachment 8890722 [details] [diff] [review] Part 2: remove legacy web platform test for <object> Review of attachment 8890722 [details] [diff] [review]: ----------------------------------------------------------------- Sorry, if you hadn't we'd have more failures. Thanks!
Attachment #8890722 - Flags: review?(annevk) → review+
(In reply to Anne (:annevk) from comment #6) > Did you check that > testing/web-platform/tests/old-tests/submission/Opera/script_scheduling/ > scripts/include-12.js is not linked from any other tests? r+ if so. Yes, I checked http://searchfox.org/mozilla-central/search?q=include-12.js&case=false®exp=false&path=
Comment on attachment 8890371 [details] [diff] [review] Bug1381728.patch Ok, this is similar to docshell.
Attachment #8890371 - Flags: review?(bugs) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/63c9ee282df2 Part 1 : <object data="data:text/html,...> should have unique opaque origin. r=smaug https://hg.mozilla.org/integration/mozilla-inbound/rev/9b492cecc402 Part 2: remove legacy web platform test for <object>. r=anne
You need to log in before you can comment on or make changes to this bug.