Steps to reproduce:

1. Navigate to https://ssrf.kr/topnavigation.html
   iframe URL: https://vuln.live/top

Actual results:

iframe can navigate top window

1. Same-origin: iframe loaded in https://example.com bypasses via top navigation to https://example.com/redirect?url=https://attacker.com or https://example.com/?xss=alert(1)

2. Same-site: iframe loaded in https://example.com bypasses via top navigation to https://subdomain.example.com/redirect?url=https://attacker.com or https://example.com/?xss=alert(1)

3. Same-origin/same-site, different scheme: iframe loaded in https://example.com bypasses via top navigation to plaintext http://example.com/attacker-page (note HTTP in destination URL)

This does not affect sandboxed iframes

Expected results:

iframe cannot navigate top window

Please Note that ssrf.kr and vuln.live is not the Same-Origin but vuln.live could control different Origin - ssrf.kr's window.

This means that if attacker can control the iframe src (like community's board) to his own page can occurs arbitrary page location control which has evil actions.

Why do you think a cross-origin frame can't navigate it's parent? If that weren't the historical case they wouldn't have had to make a point of preventing it as part of the definition of a sandboxed iframe. Further evidence is that _parent and _top are explicitly supported values for a link's target attribute.

In hindsight it sure can lead to mischief, but sadly this was baked in to HTML early on. The editors of the HTML spec are definitely not a fan:

The Location exotic object is defined through a mishmash of IDL, invocation of JavaScript internal methods post-creation, and overridden JavaScript internal methods. Coupled with its scary security policy, please take extra care while implementing this excrescence.

If you've found a browser that behaves differently than the standard that would be interesting to know.

Interesting that both Chrome and Safari block the navigation in the testcase as it's written, but as an anti-annoyance feature like a pop-up blocker. In both browsers if you click inside the frame before the timeout (to show user interaction) then the navigation is allowed. So they don't block your testcase navigation because it's cross-origin, but cross-origin is one of the signals they use in their heuristic of what a user might find annoying. Probably a good idea.

Safari blocks the navigation with only a message on the console.

Chrome also has an animated toolbar icon that, if clicked, allows setting an exception for the site. Seems to be combined with the popup permission. The per-site permission can also be managed through their preferences pages.

Anne: has there been a spec change or discussion about this? Or did Safari and Chrome just independently do a similar intervention?

Maybe cross-origin frame navigate parent frame seems intentional. The same-site bypass might have been implemented to address compatibility issues/concerns. However, in the case of chrome, it was recognized as a vulnerability. It didn't block all, but it blocked navigate when it had different origin or different scheme.
Above all, I think this can lead to potential security vulnerabilities. Please check out my scenario.

Like my co-researcher said, Google thought this as an vulnerability (The other browsers started to block this from few months ago since they treat this as a vulnerability).

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30534

This CVE is issued by same bugs with our report and attackers can abuse this feature with written scenario.
In fact, I could trigger account takeover with this trick in real world test on Firefox only. That's why we reported this as an vulnerability.

Maybe you would be better to change the top window policy as working when the destination is same-origin only.

https://crbug.com/1151507

It seems this has been discussed in https://github.com/WICG/interventions/issues/16 to some extent and apparently it also broke some websites, but as far as I know this hasn't been upstreamed to the HTML Standard (I'll leave a comment). Requiring a user gesture seems reasonable to me though.

Can you change this to Security Issue?

or May I just submit this to MIRE for issuing CVE Number (because this report looks like opened to all right now)

(In reply to SeungHyun Kim from comment #8)

Can you change this to Security Issue?

or May I just submit this to MIRE for issuing CVE Number (because this report looks like opened to all right now)

Sorry, not MIRE, It was MITRE

pbz, do you know if we have some meta bug to track this kinds of issues?

Sorry, I'm not aware of a good meta-bug for this.

Is there any update?