Closed Bug 1359867 Opened 7 years ago Closed 4 years ago

Add attribute allow-top-navigation-by-user-activation to iframe sandbox

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla79
Tracking Status
firefox79 --- fixed

People

(Reporter: binlu, Assigned: jkt)

References

Details

(Keywords: dev-doc-complete)

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36




Expected results:

There is a new attribute proposed to iframe sandbox:
https://html.spec.whatwg.org/multipage/browsers.html#attr-iframe-sandbox-allow-top-navigation-by-user-activation

This is a follow-up work of https://bugzilla.mozilla.org/show_bug.cgi?id=1190641

The new attribute requires a user activation (or gesture) being processed to trigger a top-level navigation. This change would enable more use cases of sandboxing untrusted third-party contents (eg., ads) by allowing top navigation while blocking malicious auto-redirecting, and thus help building a safer internet (eg., a safer ads ecosystem in which all ads could be sandboxed to prevent unexpected malicious behaviors like plugin exploits, auto-redirects, file downloading, modal dialogs, etc). 

For more context:
https://github.com/w3ctag/design-reviews/issues/154
https://github.com/WICG/interventions/issues/42
Component: Untriaged → DOM: Security
Product: Firefox → Core
The big problem here, of course, is defining "user activation" in a sane way...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → enhancement
Component: DOM: Security → DOM: Core & HTML
Priority: -- → P2
An update: 
In addition to Chrome, Webkit (Safari) has landed CLs to support this: https://bugs.webkit.org/show_bug.cgi?id=171327.
Ad networks have started to use this feature to prevent malicious behaviors (like plugin exploits, auto-redirects, etc) from third-party contents (eg., ads).

It would be great if Firefox could support this soon. Thanks.
Again, the big problem is defining "user activation".  Browsers define it totally differently, and Gecko has at least three different internal definitions I'm aware of.... We'd need to at the very least pick one of those definitions.
Thanks Boris for the reply!
I have no knowledge on how Gecko defines "user activation", but I guess anything reasonable should be fine although browser interoperability would be great. FYI.: Here is a link to how Chromium defines "user activation":
https://docs.google.com/document/d/1mcxB5J_u370juJhSsmK0XQONG2CIE3mvu827O-Knw_Y/edit?ts=59affec4#heading=h.t0ybg8byy7bg
We're also working on a proposal for a) simplifying this in Chrome and b) standardizing the new behavior once we've proven to ourselves that it's web compatible. We haven't quite gotten around to sharing it anywhere yet though. Will try to do soon.
Hello, Any update on this?

Ad networks are increasing adopting iframe sandbox, e.g, the % of page views with iframe sandbox has jumped to ~8% from ~0.4% last May (https://www.chromestatus.com/metrics/feature/timeline/popularity/672), and there are also some tech articles talking about this "allow-top-navigation-by-user-activation" attribute now:
https://www.linkedin.com/pulse/can-sandboxing-defeat-redirects-gavin-dunaway/
https://www.peerlyst.com/posts/unsandboxed-ad-iframes-and-content-reco-widgets-are-vulnerable-to-malvertising-attacks-dr-augustine-fou-cybersecurity-ad-fraud-researcher?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BdFXGE2CZQmufZntqTKEgIA%3D%3D

It would be great if Firefox could support it. Thanks.
Flags: needinfo?(overholt)
Wanted to add my support for this.   

The following browsers support this

We see it working in the following browsers
Chrome for desktop release 58
Chrome for Android release 58
Android WebView release 58
Opera release 45
Opera for Android release 45
Safari Tech Preview 48

It looks like IOS 12 will have this rolled out but we are hoping Apple deploys sooner given the security aspect of the issues.


Force browser redirects is the primary method being leveraged by bad guys to distribute malware and fraud.  Here is a good recent article on a giant network exposed by Confiant https://blog.confiant.com/uncovering-2017s-largest-malvertising-operation-b84cd38d6b85 and another one by GeoEdge http://markets.businessinsider.com/news/stocks/Researchers-at-GeoEdge-uncover-new-Auto-Redirects-Costing-Publishers-and-Marketers-over-1-BillionWith-Auto-Redirects-a-fast-growing-concern-GeoEdge-s-Security-team-uncovered-seven-new-and-1012665863
This isn't being actively worked on right now.
Flags: needinfo?(overholt)
comment 2 and comment 4 are still the main issues here. 

We don't really follow the last step of 
https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation 
I wonder what other browsers do, exactly.
(first two steps are sort of handled https://searchfox.org/mozilla-central/rev/47cb352984bac15c476dcd75f8360f902673cb98/dom/events/Event.cpp#677)
I /think/ the general idea of "chain of algorithms" in the spec is that anything that is "ultimately" triggered by a user action is treated as such.  For example, a click event handler that sets a timeout function that sends a postMessage... The spec line meant to cover all such cases through this recursive definition.

Chrome maintains and passes on (stack-scoped) UserGestureTokens to allow following the "chain".  But it is far from being complete, sometimes simply because we didn't really get a chance to fix it (e.g. for Promises: crbug.com/404161), sometimes because of implementation complications.  There are cases where we break the chain deliberately; e.g. we don't allow setTimeouts beyond depth 1 perhaps to disallow tricky multiple-popups-per-activation cases.

I doubt if any browsers fully implements the spec.

Currently we are implementing a new simple model ("User Activation v2") where activation states are stored in frames, and propagated up the frame tree (so chaining/stack-scoping won't be needed).  We are fighting regressions now :( .  *If* everything goes well, we plan to propose a new spec (crbug.com/696617).

(A separate thread with MS last month seemed to suggest that Edge does something close to our v2.)
At least some of the "is user activation" bits in Gecko explicitly report "no" if it's been too long such that users would not perceive the thing that happens as a response to their action.
Olli, Thanks for looking into this.
Have Mustaq and Boris's explanations answer your question?
Is there any other concerns/blockers on implementing this? Thanks.
Flags: needinfo?(bugs)
The concern is the same as it was all along: definition of "user activation".
The spec has a definition. It's known not to be perfect (https://github.com/whatwg/html/issues/1903), and Chrome is investing some resources into working on that.

But I am hopeful that in the meantime that browsers are still willing to ship features that take advantage of user activation, just like they've done with e.g. the notifications API, the credential management API, service workers' clients API, recent work to move the vibrate API behind user activation, etc. (https://www.google.com/search?q=%22triggered+by+user+activation%22+site%3Agithub.io seems informative.)

In other words, I'm not sure why this feature in particular would be held up by trying to perfect the definition of user activation, when Firefox has shipped many other features based on it.
The real question is to what extent we need to worry about compat fallout.  That needs to be decided on a case-by-case basis.  Navigation not working is obviously a bigger compat problem than notifications not working, for example.

But yes, we can of course just ship something and then hope that we don't break too many sites when we end up changing behavior later.  That still requires us deciding what the "something" we ship is, because Gecko has multiple different concepts that sort of look like "user activation", as I said above.  And that needs someone with time to sit down and think about how this will be used in practice and which of those concepts best maps onto the use cases.
Two points re the "user activation" worries:

- For popups in major browsers, we hardly found any consistency from this perspective: https://docs.google.com/presentation/d/1vilDD2x__CXOV5kAPmhUCzgsVAkFt5fxsnT4AqlP8KU/edit#slide=id.g242f4237e9_0_74

- Since you mentioned the need for a thorough look: in Chrome we are doing exactly that today.  For User Activation v2, our end goal is to replace Chrome's hacky old system with one that simple enough for cross-browser implementation.  Feel free to comment on our design: https://docs.google.com/document/d/1erpl1yqJlc1pH0QvVVmi1s3WzqQLsEXTLLh6VuYp228/edit?usp=sharing
Received confirmation from Microsoft team that this is now in their dev queue.  Would really love to see a path forward.
It seems like the biggest hangup here is lack of clarity around "user activation". What specific questions do we need answered? Should we check with the Edge team on what they are planning on doing? Or is it just like Boris says in comment 16 that someone needs to sit down and think about it?
Flags: needinfo?(bzbarsky)
I think we just need to sit down and think about it, though checking what other UAs are doing could be useful input, sure.
Flags: needinfo?(bzbarsky)
Flags: needinfo?(echen)
AFAIK, 
1. Most of user-activation in Gecko is based on whatever EventStateManager::IsHandlingUserInput[1] returns. And it treats key events (except Esc, Shift, Ctrl, Alt ..), mouse events and pointer events as user input. (Spec treats contextmenu as user-activation, but Gecko doesn't)
2. The user-activation for Fullscreen adds 1000ms timeout [2].
3. The user-activation for popup has a whitelist [3] + all access key [4].

[1] https://searchfox.org/mozilla-central/rev/e126996d9b0a3d7653de205898517f4f5b632e7f/dom/events/EventStateManager.cpp#4121
[2] https://searchfox.org/mozilla-central/rev/e126996d9b0a3d7653de205898517f4f5b632e7f/dom/base/nsContentUtils.cpp#7120-7125
[3] https://searchfox.org/mozilla-central/rev/f2ac80ab7dbde5400a3400d463e07331194dec94/modules/libpref/init/all.js#1248
[4] https://searchfox.org/mozilla-central/rev/3fa761ade83ed0b8ab463acb057c2cf0b104689e/dom/html/nsGenericHTMLElement.cpp#2544
See Also: → 1473985

See https://www.admonsters.com/can-sandboxing-defeat-redirects/ for motivation. "While Chrome (versions 58 and later) has enabled the control, Firefox, Safari, and Internet Explorer prior to 10 have not."

(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #22)

See https://www.admonsters.com/can-sandboxing-defeat-redirects/ for motivation. "While Chrome (versions 58 and later) has enabled the control, Firefox, Safari, and Internet Explorer prior to 10 have not."

Just a clarification: Safari has supported this on both Mac & iOS since April 2018: https://bugs.webkit.org/show_bug.cgi?id=171327, which is also mentioned above.

So with Edge moving to use Chromium, Firefox would be the only major browser not supporting this.

FWIW, here's an example of where another major open source project could take advantage of this if it existed, which would improve UX for millions of users:

https://core.trac.wordpress.org/ticket/39097#comment:19

Assignee: nobody → jonathan
Status: NEW → ASSIGNED
Pushed by dluca@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1a75435c9764
Add support for allow-top-navigation-by-user-activation iframe sandboxing r=smaug
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/23888 for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Upstream PR merged by moz-wptsync-bot
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla79

Docs work completed; see https://github.com/mdn/sprints/issues/3414#issuecomment-652566772 for the full details.

The MDN iframe page already describes the new token nicely, so there was not much to do here.

Flags: needinfo?(echen)
Flags: needinfo?(bugs)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: