Closed Bug 1381728 Opened 2 years ago Closed 2 years ago

<object data="data:text/html,...> should have unique opaque origin

Categories

(Core :: DOM: Security, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
mozilla57
Tracking Status
firefox57 --- fixed

People

(Reporter: allstars.chh, Assigned: allstars.chh)

References

Details

(Whiteboard: [domsecurity-active])

Attachments

(2 files)

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
Flags: needinfo?(bzbarsky)
<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?
Flags: needinfo?(bzbarsky)
Thanks, that answers my question, it's really helpful.
Priority: -- → P2
Attached patch Bug1381728.patchSplinter Review
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
Flags: needinfo?(annevk)
Yeah, given that it's in old-tests I'd r+ removal as well.
Flags: needinfo?(annevk)
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&regexp=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 yhuang@mozilla.com:
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
https://hg.mozilla.org/mozilla-central/rev/63c9ee282df2
https://hg.mozilla.org/mozilla-central/rev/9b492cecc402
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
You need to log in before you can comment on or make changes to this bug.