Referrer-Policy is not respected inside iframes whose document URL was set by document.open
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
People
(Reporter: fastest963, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Whiteboard: [domsecurity-backlog1])
Attachments
(1 file, 1 obsolete file)
3.46 MB,
text/plain
|
Details |
Updated•7 years ago
|
Comment 1•7 years ago
|
||
Comment 2•7 years ago
|
||
Reporter | ||
Comment 3•7 years ago
|
||
Comment 4•7 years ago
|
||
Comment 5•7 years ago
|
||
Reporter | ||
Comment 6•7 years ago
|
||
Comment 7•7 years ago
|
||
Comment 8•7 years ago
|
||
Comment 9•7 years ago
|
||
Updated•7 years ago
|
Comment 10•7 years ago
|
||
Comment 11•7 years ago
|
||
Comment 12•7 years ago
|
||
Updated•7 years ago
|
Comment 13•7 years ago
|
||
Comment 14•7 years ago
|
||
Comment 15•7 years ago
|
||
Comment 16•7 years ago
|
||
Comment 17•7 years ago
|
||
Comment 18•7 years ago
|
||
Comment 19•7 years ago
|
||
Comment 20•7 years ago
|
||
Comment 21•6 years ago
|
||
Comment 22•6 years ago
|
||
Comment 23•6 years ago
|
||
Christoph, what's the spec status of this at this point? Bug 1330487 is long-since fixed....
Comment 24•6 years ago
|
||
(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #23)
Christoph, what's the spec status of this at this point? Bug 1330487 is long-since fixed....
Right, in fact Thomas is working on Bug 1534681 which will fix the problem here as well. I just chatted with him and he verified that is the case. I'll add Bug 1534681 as a blocker to this one and then we can use this bug to actually land a wpt test.
Comment 25•6 years ago
|
||
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #24)
(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #23)
Christoph, what's the spec status of this at this point? Bug 1330487 is long-since fixed....
Right, in fact Thomas is working on Bug 1534681 which will fix the problem here as well. I just chatted with him and he verified that is the case. I'll add Bug 1534681 as a blocker to this one and then we can use this bug to actually land a wpt test.
Sorry, I was wrong, I had to change document.open and pass callerDoc's referrer policy to current doc.
Chrome did that way and added a wpt about that, but it appears we don't have any spec says that.
So I think we should figure out what we have to do with document.open spec here. Bug 1534681 will only handle inheritance in srcdoc and blob iframe, unset dependency.
Comment 26•6 years ago
•
|
||
:annek, what do you think? Is it worth to add something points out referrer policy passing in document.open() spec (we had a wpt test but works for Chrome only) ?
Comment 27•6 years ago
|
||
Thomas, I would prefer matching https://html.spec.whatwg.org/#document-open-steps and leaving the referrer policy as-is when document.open() is invoked. Changing the WPT test and filing a bug against Chrome seems preferable here.
Dominic, do you know why Chrome modifies the referrer policy when document.open() is invoked to that of whoever called it?
Comment 28•6 years ago
|
||
The argument that makes the most sense to me here is that the URL that will be sent as referrer comes from the entry document, so the referrer policy should too. Otherwise any use of document.open() ends up risking leaking more referrer information than the document the URL comes from wanted to leak.
Comment 29•6 years ago
|
||
If that is a concern, we'll forever have to adjust document.open() to take into account new state might have to be copied over. (I guess we'll have to design some kind of abstraction to ensure this is hard not to do.)
Comment 30•6 years ago
|
||
I'm not sure specifically why we carry over the referrer policy. I imagine bz's comment may be the reason, I can ask jochen@ or someone if we're still interested in removing that from Chrome and fixing the WPT. May not be too tough of a sell, as it seems that's the only test that we currently have relying on that behavior 1. Do you still prefer that Anne?
Comment 31•6 years ago
•
|
||
I think copying state might be okay, but I'd like the answer to be more complete here. E.g., what about cookie URL (not specified yet) or CSP list?
See also bug 1534681 comment 7.
Comment 32•4 years ago
|
||
I'm afraid I still encounter this behavior which can in some situations be a serious security issue. I'd offer to help but am lacking the skills - sorry and thank you for your work.
Comment 33•4 years ago
|
||
Folks, I hate to reply to such an old thread, but I can confirm that this is still happening in Firefox (not Chrome) and is causing password reset token leaks to Intercom.
Comment 34•4 years ago
|
||
Same for me. Is there a workaround to avoid such behavior except not using services that use the technique with iframes and scripts inside them?
Reporter | ||
Comment 35•4 years ago
|
||
It looks like document.open() was clarified and https://github.com/whatwg/html/issues/3286 was closed. Does that resolve Anne's concerns about other things to copy over from the document?
Reporter | ||
Updated•4 years ago
|
Comment 36•4 years ago
|
||
I suspect this is essentially a duplicate of bug 1610450 at this point (we don't inherit into initial about:blank), but let's depend on it for now. And yeah, document.open()
just resets some state now (and does not affect referrer or referrer policy).
Updated•2 years ago
|
Updated•7 months ago
|
Description
•