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

RESOLVED FIXED in Firefox 57

Status

()

Core
DOM: Security
P2
normal
RESOLVED FIXED
10 months ago
10 months ago

People

(Reporter: allstars, Unassigned)

Tracking

Trunk
mozilla57
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 fixed)

Details

(Whiteboard: [domsecurity-active])

Attachments

(2 attachments)

(Assignee)

Description

10 months ago
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
(Assignee)

Updated

10 months ago
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)
(Assignee)

Comment 2

10 months ago
Thanks, that answers my question, it's really helpful.
Priority: -- → P2
(Assignee)

Comment 3

10 months ago
Created attachment 8890371 [details] [diff] [review]
Bug1381728.patch

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)

Comment 4

10 months ago
Yeah, given that it's in old-tests I'd r+ removal as well.
Flags: needinfo?(annevk)
(Assignee)

Updated

10 months ago
Attachment #8890371 - Flags: review?(bugs)
(Assignee)

Comment 5

10 months ago
Created attachment 8890722 [details] [diff] [review]
Part 2: remove legacy web platform test for <object>
Attachment #8890722 - Flags: review?(annevk)

Comment 6

10 months ago
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 7

10 months ago
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+
(Assignee)

Comment 8

10 months ago
(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 9

10 months ago
Comment on attachment 8890371 [details] [diff] [review]
Bug1381728.patch

Ok, this is similar to docshell.
Attachment #8890371 - Flags: review?(bugs) → review+

Comment 10

10 months ago
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
Last Resolved: 10 months ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Depends on: 1387812
You need to log in before you can comment on or make changes to this bug.