COOP bug within iframes
Categories
(Core :: DOM: Navigation, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox71 | --- | fixed |
People
(Reporter: ralucaelenaradu969, Assigned: CuveeHsu)
References
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36
Steps to reproduce:
While testing COOP behavior, I opened a new window from an iframe context. The iframe (origin B) and the top most window (origin A) had different origins, while the newly opened window had origin B.
Actual results:
I was able to manipulate the reference, navigate the openee and infer data about it, even though the openee (B) was cross origin with the top most window (A).
Expected results:
COOP should have cut the link and prevent the reference of being used. For better understanding please have a look at the following proof of concept test case scenario : https://coop-checker.appspot.com/bug/firefox_main_A.html.
|
Reporter | |
Comment 1•5 years ago
|
||
(In reply to Raluca Radu from comment #0)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36
Steps to reproduce:
While testing COOP behavior, I opened a new window from an iframe context. The iframe (origin B) and the top most window (origin A) had different origins, while the newly opened window had origin B.
Actual results:
I was able to manipulate the reference, navigate the openee and infer data about it, even though the openee (B) was cross origin with the top most window (A).
Expected results:
COOP should have cut the link and prevent the reference of being used. For better understanding, toggle the "browser.tabs.remote.useCrossOriginOpenerPolicy" flag to true and afterwards, please have a look at the following proof of concept test case scenario : https://coop-checker.appspot.com/bug/firefox_main_A.html.
|
||
Comment 2•5 years ago
|
||
Let's triage this issue, and I'll defer the confirmation of the issue to Anne, who is already Ni'ed.
|
||
Comment 3•5 years ago
|
||
Junior, can you take a look please?
This is a problem with https://gist.github.com/annevk/6f2dd8c79c77123f39797f6bdac43f3e too. It only talks about the creator's policy, but it should really be something like the creator's top-level browsing context's active document, and even that's not great.
Filed https://github.com/whatwg/html/issues/4902 to track this standards-wise.
|
||
Comment 4•5 years ago
|
||
Also adding Valentin to take a look here.
|
Assignee | |
Comment 5•5 years ago
|
||
|
|
Assignee | |
Comment 6•5 years ago
|
||
(In reply to Anne (:annevk) from comment #3)
Junior, can you take a look please?
This is a problem with https://gist.github.com/annevk/6f2dd8c79c77123f39797f6bdac43f3e too. It only talks about the creator's policy, but it should really be something like the creator's top-level browsing context's active document, and even that's not great.
Filed https://github.com/whatwg/html/issues/4902 to track this standards-wise.
I'm with you for the opener-policy should inherit from opener's top-level browsing context.
The thing I'm confused is what origin we should use in matching algorithm.
IMO we should use the creator's origin instead of top-level document's origin.
In this scenario from description:
Top-Level window with origin A (COOP: same-origin) embeds iframe with origin B, whose COOP should be same-origin based on our discussion.
However, when iframe creates a popup, we should use origin B as current origin in COOP match algorithm.
That is, creating a popup with origin B from iframe with origin B should pass match cross-origin opener-policies.
What do you think, Anne?
|
|
||
Comment 7•5 years ago
|
||
Right, the popup initial about:blank inherits everything as normal, i.e., it gets its origin and other things from the creator, but COOP is always gotten from the top-level browsing context, in this case the creator's top-level browsing context. Storing COOP on the top-level browsing context is a thing we could do here that would simplify this a bit (as you don't have to traverse the document tree).
|
|
Assignee | |
Comment 8•5 years ago
|
||
|
||
Comment 10•5 years ago
|
||
| bugherder | ||
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
||
Comment 11•5 years ago
|
||
Hello :Junior, do you have a reduced case we might use in order to reproduce this issue and verify the Fix , a few extra steps ? maybe a test page ? it would help us a lot.
Description
•