1800190 - Unsandboxed iframes can navigate their parents (should provide toplevel navigation blocking like chrome)

Status: RESOLVED DUPLICATE of bug 1419501

(Core :: DOM: Navigation, enhancement)

Description

[Krishna]

Attachment: Bugbounty.zip

Steps to reproduce the Issue:

1. Create a simple node js web app. This web app runs on domain localhost and port 8080 (http://localhost:8080)
2. In the web app's main page, host an iframe that loads the content from 127.0.0.1 and port 8081 (http://127.0.0.1:8081)
3. In the iframe, run javascript to redirect the user i.e. window.top.location = http://127.0.0.1:8081
4. Firefox automatically redirects the user without throwing a console error to the arbitrary domain provided by the iframe.
5. Please note that the http://localhost:8080/ and http://127.0.0.1:8081/ are different origins because of the port number change.
6. Firefox is respecting the sandbox attribute when it is used. Because sandbox automatically blocks script executions in an iframe. But if the sandbox attribute is not used, the redirection is happening.

Risk:

1. Millions of sites depend on iframe to show ads etc.
2. Any app compromised and hosted in an iframe has the ability to redirect the user to an arbitrary domain.
3. Once the user is redirected to an arbitrary domain, an attacker could steal credentials, install malware or trick the user to leak PII.

Tested on Firefox version 106.0.1 on Mac OS
Also tested on the latest versions of Chrome and Safari, where they throw an error in the Console and Chrome in particular, also shows a popup-blocker style error in the url bar, providing a choice to the user.

Testing:

• Please see the attached sample app. The attached sample app can be run using node server.js
• Once the app is running, visit http://localhost:8080/ in Firefox version stated above. The iframe that is loaded will redirect the user to http://127.0.0.1:8081/

Comment 1

[:Gijs (he/him)]

It's not clear to me this needs to stay hidden as security-sensitive; it seems more like a feature request, as the web has in the past always behaved like this. I'm not sure if there was a spec change or if Google decided to block these navigations unilaterally (and if so, what criteria they use).

Comment 2

[Krishna]

Hello, just checking if you are still considering this or if you want any information from me? I understand that the spec doesn't specify. But it would be nice to prevent a compromised iframe from redirecting a user to arbitrary domains.

Comment 3

[Nika Layzell [:nika] (ni? for response)]

This is what is expected by the spec right now, in terms of allowed behavior. It sounds like there is a chrome intervention which is preventing it in your specific case. It seems based on https://github.com/whatwg/html/issues/8013 like this intervention isn't very well understood right now, so probably isn't ready for us to adapt. As the spec changes we'll adopt to it as well.

Comment 4

[Andrew McCreight [:mccr8]]

This is a known issue so it doesn't need to stay hidden.

Comment 5

[Krishna]

Thanks for the update! Requesting to disclose this issue. Please let me know if I can disclose this. Thanks!

Comment 6

[Andrew McCreight [:mccr8]]

Yes, the issue is public now.

Comment 8

[Krishna]

Hello, I would like to check if you can revisit this and consider this a bug. Looks like Chromium project considers a similar issue (even though specs say otherwise) a bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1251790

Comment 9

[Frederik Braun [:freddy]]

We think the Chrome behavior requiring a user interaction is non-standard (comment 3) that Chrome made unilaterally and we do not offer the same kind of protection without risking web compatibility issues. We will consider implementing this as a security enhancement.

The bug you Chrome bug https://bugs.chromium.org/p/chromium/issues/detail?id=1251790 does not match this issue here, in our opinion. The latter is a way to violate the Content-Security-Policy sandbox directive, which is a protection we do provide and that we do not consider broken with this example. But please let us know if you can do that too and file a new bug.

Comment 11

[Daniel Veditz [:dveditz]]

I'm "confirming" that our behavior differs from Chrome's proposed spec change. It does not mean that we support or will adopt that change -- that will be argued in the standards process.

Comment 15

[Maurice Dauer [:mdauer]]

Malte and I will start investigating the possibility of adapting this in Firefox and adjusting the spec.

Comment 16

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Is bug 1419501 also a duplicate of this? There is the same html issue in the URL field.

Comment 17

[Malte Jürgens [:maltejur]]

(In reply to Hsin-Yi Tsai (she/her) [:hsinyi] from comment #16)

Is bug 1419501 also a duplicate of this? There is the same html issue in the URL field.

Yes, they seem to be the same. I'll merge this one into the older bug.