1419501 - consider requiring user interaction for cross-origin iframe window.top.location navigation

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[Ben Kelly [:bkelly, not reviewing]]

We should consider requiring user interaction before allowing a cross-origin iframe to navigate the top window.  For example, to prevent stuff like this:

https://twitter.com/NateTheFinch/status/933030604844740609

Chrome has been running an intervention to experiment with this and are shipping some kind of mitigation in chrome 64:

https://github.com/WICG/interventions/issues/16

If they are successful in shipping that, it might be nice to follow suit.

Comment 12

[Maurice Dauer [:mdauer]]

Attachment: WIP: Bug 1419501 - Restrict top-level navigations from cross-origin

Comment 13

[Malte Jürgens [:maltejur]]

Attachment: Bug 1419501 - Expand web-platform tests for preventing iframes from navigating their top window r?mdauer

Comment 14

[Maurice Dauer [:mdauer]]

Attachment: Bug 1419501 - Part 1: Add `dom.security.framebusting_intervention.enabled` pref, r?maltejur,freddyb

Comment 15

[Maurice Dauer [:mdauer]]

Attachment: Bug 1419501 - Part 2: Rename existing user-facing popup related strings, r?#fluent-reviewers,maltejur,freddyb

Comment 16

[Maurice Dauer [:mdauer]]

Attachment: Bug 1419501 - Part 3: Introduce `RedirectBlockedEvent`, r?#webidl,#dom-core,maltejur,freddyb

Comment 17

[Maurice Dauer [:mdauer]]

Attachment: Bug 1419501 - Part 4: Implement framebusting intervention, r?#dom-core,#fluent-reviewers,maltejur,freddyb

Comment 19

[Maurice Dauer [:mdauer]]

Attachment: Bug 1419501 - Part 5: Framebusting intervention browser tests, r?freddyb,maltejur

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/1fe32fbd965f
https://hg.mozilla.org/integration/autoland/rev/64540082033b
Part 1: Add `dom.security.framebusting_intervention.enabled` pref, r=maltejur
https://github.com/mozilla-firefox/firefox/commit/7663d6e2f74b
https://hg.mozilla.org/integration/autoland/rev/34abfdeecba5
Part 2: Rename existing user-facing popup related strings, r=fluent-reviewers,bolsson,Gijs
https://github.com/mozilla-firefox/firefox/commit/71ceddee6be6
https://hg.mozilla.org/integration/autoland/rev/20fbc6d90d1e
Part 3: Introduce `RedirectBlockedEvent`, r=maltejur,webidl,frontend-codestyle-reviewers,smaug
https://github.com/mozilla-firefox/firefox/commit/70b9c571f251
https://hg.mozilla.org/integration/autoland/rev/49381a07dfe2
Part 4: Implement framebusting intervention, r=fluent-reviewers,desktop-theme-reviewers,tabbrowser-reviewers,bolsson,edgar,mstriemer,sfoster,sthompson,emz
https://github.com/mozilla-firefox/firefox/commit/cdf51f29463f
https://hg.mozilla.org/integration/autoland/rev/1e1236d315cb
Part 5: Framebusting intervention browser tests, r=maltejur,frontend-codestyle-reviewers
https://github.com/mozilla-firefox/firefox/commit/375dd3f042bc
https://hg.mozilla.org/integration/autoland/rev/a745e721346e
Expand web-platform tests for preventing iframes from navigating their top window r=mdauer

Comment 21

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/54792 for changes under testing/web-platform/tests

Comment 22

[Maurice Dauer [:mdauer]]

Attachment: WIP: Bug 1419501 - Add "DOMRedirectBlockedEvent" handling for mobile, r?freddy,maltejur

Comment 23

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/64540082033b
https://hg.mozilla.org/mozilla-central/rev/34abfdeecba5
https://hg.mozilla.org/mozilla-central/rev/20fbc6d90d1e
https://hg.mozilla.org/mozilla-central/rev/49381a07dfe2
https://hg.mozilla.org/mozilla-central/rev/1e1236d315cb
https://hg.mozilla.org/mozilla-central/rev/a745e721346e

Comment 24

[Phabricator Automation]

Comment on attachment 9512678 [details]
WIP: Bug 1419501 - Add "DOMRedirectBlockedEvent" handling for mobile, r?freddy,maltejur

Revision D264466 was moved to bug 1988107. Setting attachment 9512678 [details] to obsolete.

Comment 25

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 26

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 27

[Hamish Willee]

FF144 MDN docs for this can be tracked in https://github.com/mdn/content/issues/41138

My understanding is that prior to this change a non-sandboxed cross-origin <iframe> could perform top navigation (if otherwise allowed by various protections such as those provided by COOP/COEP, whatever). So if an embedded iframe set window.top.location = 'https://example.com'; on frame load, this would succeed.

Following this change the navigation would fail unless the user had already interacted with some element in the embedded frame - i.e. Sticky activation. So you might set the top location using a button, but not on page load.
However this only applies to cross-origin frames - a same origin frame behaves as before.

1. Is that correct?
2. If the navigation is blocked, my understanding is that an error would be reported in the developer console and the page would simply not navigate. Is that right?
3. How are sandboxes affected by this? Would a sandbox with allow-top-navigation still require user interaction for a cross-origin sandbox? (i.e. I don't know how to interpret the sandbox-cross-navigationXxxx tests in https://wpt.fyi/results/html/semantics/embedded-content/the-iframe-element?label=master)
4. For browser compatibility data we might add a new subfeature "cross-origin top navigation requires sticky activation"
   • Does this sound reasonable?
   • What versions would we use for introduction in Chrome/Safari?
     Can I use the results of https://wpt.fyi/results/html/semantics/embedded-content/the-iframe-element/iframe_top_navigation_without_user_gesture_same_site.tentative.html?label=master to work this out? - i.e a pass indicates that the version requires user interaction for cross origin frames but not for same origin frames?
5. Do you have a preferred MDN release note for this?

Comment 28

[Maurice Dauer [:mdauer]]

Thanks for working on the MDN docs for this!

1. Is that correct?

Yes, this is correct! :]

2. If the navigation is blocked, my understanding is that an error would be reported in the developer console and the page would simply not navigate. Is that right?

Yes. If a third-party redirect is blocked, a notification appears giving the user the choice to allow the navigation. Chrome behaves the same, whereas on Safari (at least on mobile) there is no such option. The message in the developer console looks like this:

Attempting to navigate the top-level browsing context from frame with url "https://cross.origin.frame/" which is neither same-origin nor has the required user interaction.

3. How are sandboxes affected by this? Would a sandbox with allow-top-navigation still require user interaction for a cross-origin sandbox? (i.e. I don't know how to interpret the sandbox-cross-navigationXxxx tests in https://wpt.fyi/results/html/semantics/embedded-content/the-iframe-element?label=master)

This can be a bit tricky. Let me demonstrate with two examples. We have page A, page B and page C. All pages are cross-origin to each other and page A is always the top-level page.

• Case 1: Page A embeds page B with the sandbox attribute set to allow-top-navigation.
• Case 2: Page A embeds page B without a sandbox attribute. However, this time, page B embeds page C with the sandbox attribute set to allow-top-navigation.

In case 1, page B would be allowed to navigate the top-level page.

What about case 2, should page C be allowed to navigate the top-level page? No, because page B is not allowed to.
In other words, if a page is embedded with allow-top-navigation and it tries to navigate the top-level, we check if the parent is allowed to navigate.

4. For browser compatibility data we might add a new subfeature "cross-origin top navigation requires sticky activation"

Sounds good to me, I think that's the most accurate description. Other terms that we've used are "framebusting intervention" or "third-party redirect blocking".
For the versions, this is from the Intent to prototype:

• Blink: Shipped in M68 (https://chromestatus.com/feature/5851021045661696).
• WebKit: Shipped in Safari 13 (https://bugs.webkit.org/show_bug.cgi?id=193076).

I wouldn't use the web platform tests at this point, they are marked tentative and I'm actually not quite sure why we don't pass all of the iframe_top_navigation_* tests.

5. Do you have a preferred MDN release note for this?

As a suggestion and feel free to change it as you see the need, maybe something like this:

Framebusting Intervention: Cross-origin frames now require sticky activation to navigate the top-level page, aligning behavior with Chrome and Safari.

Comment 29

[Frederik Braun [:freddy]]

Hamish: Also take a look at the upcoming SUMO article. It may also help explain what is going on. Revision history should allow you to view the upcoming article at https://support.mozilla.org/en-US/kb/pop-blocker-settings-exceptions-troubleshooting/history.

Furthermore, a potentially interesting difference between the browsers that we observed

• Firefox prompts the user and logs to console
• Chrome prompts the user and logs to console
• Safari always blocks.