Iframe pointing to data-url has access to parent window's cookies

VERIFIED WONTFIX

Status

()

Core
Security
--
major
VERIFIED WONTFIX
7 years ago
7 years ago

People

(Reporter: Fedor Indutny, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: DUPEME)

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
Build Identifier: 

When I'm creating iframe with src equal to following: data:text/html;plain,<!doctype html><html><body><script>alert(document.cookie);</script>hello world!</body></html> and open page - it displays parent window's cookies (while has no access to window.parent variable).

Reproducible: Always

Steps to Reproduce:
1. Create iframe with src = "data:text/html;plain,<!doctype html><html><body><script>alert(document.cookie);</script>hello world!</body></html>" on any non-local page.
2. Open page and add any cookie
3. Refresh page
Actual Results:  
I see cookie of parent window

Expected Results:  
Not to see cookie as in Chrome and Opera.
(Reporter)

Comment 1

7 years ago
Created attachment 502241 [details]
testcase

Put this file on any non-local source and open it.
(Reporter)

Comment 2

7 years ago
Created attachment 502244 [details]
correct testcase

correct testcase

Comment 3

7 years ago
I believe this is the intended behavior: a data: document inherits the domain and privileges of the site which opened it, by design.
Component: General → Security
Product: Firefox → Core
QA Contact: general → toolkit
Version: unspecified → Trunk
(Reporter)

Comment 4

7 years ago
I understand you, but they have different hostname as I see. Am I wrong?
Chrome and Opera disallows usage of document.cookie, and Firefox disallows usage of window.parent.

Probably you should enable window.parent in this case. But at look at this like it's a variant of cheap content sandboxing (That's how I'm using it on : http://mapchat.me/ )
(Reporter)

Comment 5

7 years ago
Actually, I'm embedding content here:
http://mapchat.me/#/point/25.77/-80.21
> Probably you should enable window.parent in this case.

window.parent should work in this case, and does for me.  Again, the data: URI has the same permissions as the thing that loaded it.

Yes, this is different from what Webkit and Opera do.  But it's what we've done for close to 10 years now, and is well-known behavior.  Attempts to use data: URIs for "sandboxing" are just broken.

Removing security-sensitive flag, since this is all well-known documented behavior.
Group: core-security
(Reporter)

Comment 7

7 years ago
Can you please post here a link to any specification document, that describes such behavior?
I don't see any benefits of such behavior, it can't be usable b/c of non-existance of browser's compatibility.
(Reporter)

Comment 8

7 years ago
Sorry, I wanted to say, that it's not cross-browser, and since that is not usable.
Hmm.  We used to have documentation for this on mozilla.org, but I can't find it right this second.

> I don't see any benefits of such behavior

The ability to dynamically create documents that you can then actually interact with?

> it can't be usable b/c of non-existance of browser's compatibility

Yeah, it's too bad Opera and Webkit decided to do something incompatible.... ;)

For what it's worth, there is discussion about standardizing the behavior here in the whatwg, or has been in the past.  The fact that @sandbox exists will probably matter for your sandboxing use case.
Whiteboard: DUPEME
(Reporter)

Comment 10

7 years ago
> The ability to dynamically create documents that you can then actually interact with?

Why not just create regular html elements? :)
Sandboxing using this technique gives much more benefits to me: you can not only embed elements, but do JSONP requests in this iframes and than pass data to parent window, using window.postMessage().
> Why not just create regular html elements? :)

Because it can be much slower?

Seriously, what you're trying to do doesn't work and hasn't worked for over 10 years.  If you need sandboxing, you need a different approach.
(Reporter)

Comment 12

7 years ago
Heh.

Like to see, that Mozilla is not for cross-browser compatibility ;)
It's like posting bugs to Microsoft about Internet Explorer - noone cares about cross-browser functionality.

Anyway, thank you for answering.

Comment 13

7 years ago
Mozilla is for it, which is why we are having the spec discussion.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
We're not for unilaterally changing our longstanding behavior, breaking existing content in the process, to try to match other browsers if they won't tell us what, exactly, they implement.

We're all for working with them to figure out a spec for the behavior that we all agree on, and then implementing it.  Which is what we're doing.
(Reporter)

Comment 15

7 years ago
Is there any place where I can subscribe for discussion of this spec?
whatwg@whatwg.org should work.  You may want to search the archives at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/ to see what's already been said in the past.
(Reporter)

Comment 17

7 years ago
Ok, http://www.w3.org/Bugs/Public/show_bug.cgi?id=11720
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.