Closed Bug 624143 Opened 14 years ago Closed 14 years ago

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

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: fedor.indutny, Unassigned)

Details

(Whiteboard: DUPEME)

Attachments

(2 files)

testcase
185 bytes, text/html
Details
correct testcase
244 bytes, text/html
Details 
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.
Attached file testcase — 
Put this file on any non-local source and open it.
Attached file correct testcase — 
correct testcase
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
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/ )
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
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.
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
> 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.
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.
Mozilla is for it, which is why we are having the spec discussion.
Status: UNCONFIRMED → RESOLVED
Closed: 14 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.
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: