Intent to Deprecate and Remove: Cross-origin top navigation without a user gesture

[Nate Chapin]

Primary eng (and PM) emails

jap...@chromium.org (kenji...@chromium.org)

Summary

Content in an <iframe> can generally navigate the top level browsing context unless explicitly forbidden by the sandbox attribute (sometimes called 'framebusting'). Restrict this ability to content that is processing a user gesture, unless it is same-origin to the top.

Motivation

Framebusting was originally used by content that wanted to prevent being placed in an <iframe>. However, there are other, more specific tools to accomplish this (see section below). On the other hand, this framebusting technique is being used by malicious content to forcibly navigate the user.

Compatibility Risk

There isn't a good way to detect framebusting as a defense against being put in an <iframe> if it isn't actually being triggered, so the compatibility risk is somewhat uncertain. For this reason, it seems wise to ship as a Finch trial at first, to gather more definitive data.

Alternative implementation suggestion for web developers

Developers that wish to prevent their content from appearing in an <iframe> should use the CSP frame-ancestors directive or X-Frame-Options.

Usage information from UseCounter

Per UseCounter, an <iframe> navigates its top browsing context on 0.017% of page loads. Per UMA, 2.38% of these navigations are cross-origin without a user gesture. Ergo, this change will affect approximately 4 out of every 1 million page loads.  However, note that this rate varies across platforms: for instance, Chrome for Android will see 15 out of every 1 million page loads affected.

OWP launch tracking bug

crbug.com/640057

Entry on the feature dashboard

https://www.chromestatus.com/feature/5851021045661696

Requesting approval to remove too?

Yes, initially as a Finch trial.

[Chris Harrelson]

Seems reasonble to try. Please specify a milestone at which you anticipate removing support. Also, have you added code to trigger a console warning when the navigation is refused?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Jeffrey Yasskin]

On Tue, Aug 23, 2016 at 12:55 PM, Nate Chapin <jap...@chromium.org> wrote:

Compatibility Risk

There isn't a good way to detect framebusting as a defense against being put in an <iframe> if it isn't actually being triggered, so the compatibility risk is somewhat uncertain. For this reason, it seems wise to ship as a Finch trial at first, to gather more definitive data.

Folks have commented on previous intents that using Finch trials to change the behavior of a web feature can cause problems. When developers get bug reports from their users, they need to be able to blame them on a particular change we made. If Finch makes the behavior not reproduce for them, they won't be able to tell us that we broke them.

Jeffrey

[Nate Chapin]

There's a standard console warning when an illegal navigation is attempted, which will get triggered for this case.  Would you prefer a separate warning specific to this case?

~Nate

[Chris Harrelson]

Hi,

On Wed, Aug 24, 2016 at 11:41 AM, Nate Chapin <jap...@chromium.org> wrote:

There's a standard console warning when an illegal navigation is attempted, which will get triggered for this case.  Would you prefer a separate warning specific to this case?

It would be better to have a more specific warning, to make it more actionable for developers to fix or provide us feedback on a use-case we didn't anticipate.

[John Mellor]

Given that framebusting was used as security feature to protect against clickjacking (before superior options like CSP frame-ancestors directive or X-Frame-Options became available), this might make old websites vulnerable to new security exploits. Perhaps that should factor into the compatibility risk calculation here?

[Nate Chapin]

Makes sense. I guess having a very specific error message and an entry in chrome://flags to force the experiment doesn't fully resolve that risk, since developers need to then discover the flag?

 

Jeffrey

[Nate Chapin]

On Wed, Aug 24, 2016 at 11:47 AM, Chris Harrelson <chri...@chromium.org> wrote:

Hi,

On Wed, Aug 24, 2016 at 11:41 AM, Nate Chapin <jap...@chromium.org> wrote:

There's a standard console warning when an illegal navigation is attempted, which will get triggered for this case.  Would you prefer a separate warning specific to this case?

It would be better to have a more specific warning, to make it more actionable for developers to fix or provide us feedback on a use-case we didn't anticipate.

Will do. Should the console warning include a link to the launch bug?

[Nate Chapin]

On Wed, Aug 24, 2016 at 12:01 PM, John Mellor <joh...@chromium.org> wrote:

Given that framebusting was used as security feature to protect against clickjacking (before superior options like CSP frame-ancestors directive or X-Frame-Options became available), this might make old websites vulnerable to new security exploits. Perhaps that should factor into the compatibility risk calculation here?

I perhaps didn't express it very well, but that was what I was trying to get at in the compatibility section of the Intent.  It's definitely the biggest risk in my mind, but I'm not aware of a good way to measure how common it is.

[Jeffrey Yasskin]

Yeah, the developer's flow is:

1) Receive bug report with reproduction instructions

2) Try to reproduce; it doesn't.

3) ???

4) Turn on flag; succeed at reproducing.

[John Mellor]

Instead of ignoring non-user-gesture top navigations, can we treat them as X-Frame-Options:DENY and immediately unload the iframe? That should remove any security risk of this change.

[Chris Harrelson]

On Wed, Aug 24, 2016 at 12:10 PM, Nate Chapin <jap...@chromium.org> wrote:

On Wed, Aug 24, 2016 at 11:47 AM, Chris Harrelson <chri...@chromium.org> wrote:

Hi,

On Wed, Aug 24, 2016 at 11:41 AM, Nate Chapin <jap...@chromium.org> wrote:

There's a standard console warning when an illegal navigation is attempted, which will get triggered for this case.  Would you prefer a separate warning specific to this case?

It would be better to have a more specific warning, to make it more actionable for developers to fix or provide us feedback on a use-case we didn't anticipate.

Will do. Should the console warning include a link to the launch bug?

Up to you. Whatever you think is most clear & actionable...

[Nate Chapin]

Ok, I've updated my draft patch (https://codereview.chromium.org/2092293002/) to reflect the comments in this thread, namely:

* A specific console message when a framebust attempt is blocked, including a link to the launch bug.

* A blocked framebust will result in the offending Document being unloaded, which should retain the clickjacking-defense use case of an attempted framebust.

I think I'm sold on the idea that a Finch trial is a bad idea, and this should just be launched directly (with plenty of bake time on dev/beta, and a flag to disable it if need be).  Does that seem reasonable?

~Nate

[Chris Harrelson]

LGTM1 to try.

[Rick Byers]

Normally we put links to the chromestatus entry instead of the launch bug in console warnings, since that  normally has a more succinct description (and links to the bug anyway).

The 4-15 per million number is quite low.  If it was just compat (not security) we were talking about here I'd say we should just ship it - doing a partial Finch trial is probably more harm than good at that level.

Can we get someone from the security team (eg. mkwst) to weigh in on the security risk here?

LGTM2 (subject to security approval ofcourse)

[Mike West]

On Sat, Aug 27, 2016 at 4:25 AM, Rick Byers <rby...@google.com> wrote:

Normally we put links to the chromestatus entry instead of the launch bug in console warnings, since that  normally has a more succinct description (and links to the bug anyway).

The 4-15 per million number is quite low.  If it was just compat (not security) we were talking about here I'd say we should just ship it - doing a partial Finch trial is probably more harm than good at that level.

Can we get someone from the security team (eg. mkwst) to weigh in on the security risk here?

Looking at Nate's draft patch, this doesn't seem to introduce new security concerns, as the page is protected from being framed (by being unloaded in the same way we unload for the XSS Auditor). As Nate notes, that should mitigate the risk that we're exposing old pages to clickjacking attacks that they would otherwise have defended against.

LGTM2 (subject to security approval ofcourse)

LGTM3, FWIW.

Have you talked to other browser vendors about this approach? It would be nice to get other folks on board, and to get this worked into HTML's navigation algorithm in some way once we're happy with the results.

-mike

[Jochen Eisinger]

lgtm3

[Nate Chapin]

There's a WICG issue, and I took a quick look through the spec to try to figure out where a change would go, but that's the extent of it.  When in the process would a spec change typically take place?

 

-mike

[Mike West]

I'd suggest that this would happen somewhere in the navigation algorithm. Possibly as an addendum to https://html.spec.whatwg.org/multipage/browsers.html#allowed-to-navigate and its callsites?

The WICG issue is probably enough for the moment. I'll CC some folks there, and once this is something that we're shipping, and we're pretty sure compat issues aren't going to force us to turn it off, we can propose a more specific patch to the spec.

-mike

[Rick Byers]

+1 that this is the right process for interventions like this.  We want to discuss our design/intentions in public and listen to any feedback.  But interventions are really experiments for us, there's little point in trying to specify them precisely until we've really learned about the right compat/user-experience tradeoff and we only get that by shipping.  We also tend to have a LOT more feedom to change these sorts of things post-ship - don't have much of the normal worry around lock-in.

 

-mike

[xjlia...@gmail.com]

Hi, 

I am a web developer from China,but my English is just so so, I try to express my opioions well, haha. As a surfing user, I am happy with the new feature in this draft, for it forbids the unfriendly navigation without my permission. But as a web developer, I may be sad for this new feature, for it means I have to make changes to avoid this limitation. As I know, it is widely used for usage of  top.location in cross-domain jumping , once the new version of chrome with this feature released, it may affect many websites. 

To say the least, I think chrome should provide some facilities for developers to conduct users to access their target. for example, why chrome blocks the navigation and stay in blank page, like the following picture:

I also want to post a question here: why the try-catch have no effect on the top.location once it was blocked by the new feature? As a web developer, I hope that we can have more control with such limitation , on condition that it throws exception and go into the catch block instead of staying in the exception point.

Best wishes

Looking forward to your reply. 

在 2016年8月24日星期三 UTC+8上午3:55:11，Nate Chapin写道：

[Nate Chapin]

On Thu, Sep 22, 2016 at 6:23 AM, <xjlia...@gmail.com> wrote:

Hi, 

I am a web developer from China,but my English is just so so, I try to express my opioions well, haha. As a surfing user, I am happy with the new feature in this draft, for it forbids the unfriendly navigation without my permission. But as a web developer, I may be sad for this new feature, for it means I have to make changes to avoid this limitation. As I know, it is widely used for usage of  top.location in cross-domain jumping , once the new version of chrome with this feature released, it may affect many websites. 

To say the least, I think chrome should provide some facilities for developers to conduct users to access their target. for example, why chrome blocks the navigation and stay in blank page, like the following picture:

There are a couple of options you can consider to work around this:

* If top is friendly to you, it can provide a postMessage interface that, when called, will cause top to navigate itself.

* top.location navigation is allowed in response to a user action. You can wait for the user to interact with your <iframe>, and set top.location inside the event handler (e.g., onclick).

 

I also want to post a question here: why the try-catch have no effect on the top.location once it was blocked by the new feature? As a web developer, I hope that we can have more control with such limitation , on condition that it throws exception and go into the catch block instead of staying in the exception point.

I'm not sure I have fully understood this question: are you asking why no exception was thrown when the navigation was blocked?  The page is blocked using the same logic we use to block suspected XSS: we simply navigate the <iframe> to a blank document.  It should look like a standard navigation away from your document's perspective.

Hope this helps,

~Nate

[Rick Byers]

It's a good point that interventions are ideally predictable (without, for example, having to rely on a hard coded UA string version check).  Is there any way to feature-detect for this behavior?  Eg. create a hidden iframe, try to have it do a dummy navigation of top (maybe change only the fragment identifier then change it back), and check to see if that iframe has been unloaded?  Linking to some sample code for this sort of detection from the chromestatus entry could help impacted developers create a mitigation (adding "click here to go to ..." buttons only when actually necessary). 

[raman...@juspay.in]

Hi,

We use iFrame that is embedded by our clients in their web page, to securely capture sensitive credit card information. Once the user submits this information in our iFrame, we use XHR to POST the card data to our server. Since in our country 2FA is mandatory for card payments, the server returns a URL. Our iFrame loads this URL on the top window so that the user can authenticate the card transaction. 

This use case of ours is now broken with this change. Can you please share some ideas about how we can fix this with the new change?

[Ojan Vafai]

xjliang2007, thanks for writing in. Do you have a page you can point us to that we can experiment with? Having real world web pages to fix is a great way for us to decide what to ship.

ramanathan, do you also run script in the top-level page? Can you do the postMessage solution Nate proposed? Also, can you point us to a broken page?

We're considering some changes to how this works and would like to understand the cases the current solution breaks. For example, we might be able to make it so that we only require the frame to have had a user gesture at some point, not at the point of the navigation. I think that would fix your case?

[Ramanathan RV]

Hi Ojan,

Please check this form here: https://www.instamojo.com/@sengupta/lf077fd48a1bf41d4ab53e6885bac63f8/. Card details are captured by our iFrame (api.juspay.in) which is embedded into the host (instamojo.com). 

Please use this card number 5243 6811 0007 5285 (my personal card that has already expired, so feel free) with any future expiry (say Oct 2020) and cvv as 111. The image below shows the error after submitting the card form. 

Since 2 factor authentication is mandatory in our country, users will be redirected to Visa/MasterCard 3D secure page after the card form submission. 

There is only 1 XHR between the redirection and the user gesture on our frame. If that can be accommodated, then our scenario will work perfectly.

--

Thanks

Ramanathan RV

juspay.in | @juspay

[Nate Chapin]

FYI, Ojan and I have talked about this a bit more and agree that it makes sense to have this intervention be narrower than it is currently, given the amount of legitimate content it's breaking. The tentative plan is to allow navigating the top frame if the cross-origin iframe has *ever* processed a user gesture, instead of requiring it to *currently* be processing a user gesture. https://codereview.chromium.org/2392773002 is the work in progress for this.

However, that patch is non-trivial and will not be a good candidate for merge to the M55 branch, so I'm planning on removing this restriction for M55.

Thanks!

~Nate

[Rick Byers]

Thanks for the update, and for re-evaluating after analyzing the reports of breakage!  It's definitely worth the extra effort to iterate on the tradeoffs here until it seems both reasonably safe and valuable.

[kyle...@gmail.com]

This breaks my oauth workflow and I don't have too many ways around it because of a lack of cooperativeness from the vender.

It seems like if we allow the user to implicitly consent to the redirect we should allow the user to explicitly consent via a redirect blocked ui similar to the pop up blocked one.

[PhistucK]

Please, either describe the exact use case, or better yet, share a URL a reproduces the problem.

☆PhistucK

On Fri, Feb 17, 2017 at 11:44 PM, <kyle...@gmail.com> wrote:

This breaks my oauth workflow and I don't have too many ways around it because of a lack of cooperativeness from the vender.

It seems like if we allow the user to implicitly consent to the redirect we should allow the user to explicitly consent via a redirect blocked ui similar to the pop up blocked one.

--