Intent to prototype: Delegate and restrict permission in third party context

[Thomas Nguyen]

Summary: People don’t have a good understanding of iframes, because
generally, no UI indicates that iframes are visible on a page, or what
their origin is. Permission requests from iframes cause significant
confusion for users because it is hard to determine where the requests come
from, as the address bar does not match the site in the permission prompt.

Currently, Firefox allows iframes on a site to make permission requests and
show up a permission prompt using the origin of the iframes. A user making
a decision based on the third party context presented in the notification
prompt is complicated and confusing. This confusion is exacerbated when
managing previously stored permission decisions.

To address this problem, we would like to impose a restriction on
permissions coming from third party context. There would be two main
changes proposed:

-

Give an ability to delegate permissions from first party to third party
embedded iframes, and impose a restriction to embedded iframes to request
permission only when the iframe’s embedder has explicitly delegated it. The
permission request will use the top level origin to show in the prompt,
then users are only required to make permission decisions about the first
party context.
-

This change is dependent on the ability of Feature Policy to disable
permissions by default in cross-origin iframes. It will require a site to
explicitly allow permissions for cross-origin iframes (setting allow
attribute, e.g allow=”geolocation”) otherwise, the permission
requests will
be denied on that iframes.
-

The change will be applied to geolocation, camera, microphone and
screen-sharing permission, and fullscreen request.


-

Completely deny permissions from third party context for vibration,
notification, and persistent-storage permission.


The plan is:

-

Enable Feature Policy allow attribute.
-

Make permission camera/microphone/geolocation/display-capture/fullscreen
disabled by default in third-party iframe.
-

Delegate Permissions: only cross-origin iframes that have explicit
delegated permission from their parent through the allow attribute will
have the right to make permission requests.
-

Reduce the number of supported features to geolocation, camera,
microphone screen-sharing, and fullscreen (the above features are supported
for permissions UI with notification prompts, except fullscreen). And we
will move all other features to experimental phrase under a user preference
which is disabled by default.
-

Simplify prompts/dialogs to only contain the top-level origin.
-

Deny vibration, persistent-storage permission from third party iframe
(notification permission was disabled in third party context, just do some
minor refactors).




Bug: The tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=1572461

Standard: Feature Policy
https://w3c.github.io/webappsec-feature-policy/#iframe-allow-attribute

Platform coverage: All.

Preference:

dom.security.featurePolicy.experimental.enabled: disabled by default, we
will limit supported features in Feature Policy to geolocation, camera,
microphone, fullscreen, display-capture and move others to experimental
phase.

permissions.delegate.enabled: enabled by default

dom.security.featurePolicy.enabled: this pref is implemented in Firefox 65
but enabled by default in Nightly only

Other browsers: Chrome supports permission delegation from Chrome 71.

web-platform-tests: We only have web platform tests for feature policy but
not permission delegation

Some of Feature Policy web-platform-tests that the permissions are disabled
by default in cross origin iframe:

https://searchfox.org/mozilla-central/source/testing/web-platform/meta/feature-policy

testing <https://searchfox.org/mozilla-central/source/testing>/web-platform
<https://searchfox.org/mozilla-central/source/testing/web-platform>/tests
<https://searchfox.org/mozilla-central/source/testing/web-platform/tests>/
permissions
<https://searchfox.org/mozilla-central/source/testing/web-platform/tests/permissions>
/feature-policy-permissions-query.html
<https://searchfox.org/mozilla-central/source/testing/web-platform/tests/permissions/feature-policy-permissions-query.html>

testing <https://searchfox.org/mozilla-central/source/testing>/web-platform
<https://searchfox.org/mozilla-central/source/testing/web-platform>/tests
<https://searchfox.org/mozilla-central/source/testing/web-platform/tests>/
mediacapture-streams
<https://searchfox.org/mozilla-central/source/testing/web-platform/tests/mediacapture-streams>
/MediaStream-default-feature-policy.https.html
<https://searchfox.org/mozilla-central/source/testing/web-platform/tests/mediacapture-streams/MediaStream-default-feature-policy.https.html>

testing/web-platform/tests/mediacapture-streams/MediaDevices-enumerateDevices-not-allowed-mic.https.html
<https://phabricator.services.mozilla.com/D42958#change-R6vBFB8IJIFC>

testing/web-platform/tests/mediacapture-streams/MediaDevices-enumerateDevices-not-allowed-camera.https.html
<https://phabricator.services.mozilla.com/D42958#change-7eOHWcqTIeBw>

testing/web-platform/tests/mediacapture-streams/MediaDevices-enumerateDevices.https.html
<https://phabricator.services.mozilla.com/D42958#change-pqamxq3whbwg>

Secure contexts: yes.

Is this feature enabled by default in sandboxed iframes? Yes


--
Best regards,

=====================================================
Thomas Nguyen
IRC : tng...@irc.mozilla.com
Slack: tnguyen
Email: tng...@mozilla.com
=====================================================

[s.h.h...@gmail.com]

1. If a user already gave permission to certain origin (e.g. skype.com), and that origin had HTML injection, does that mean attacker can now silently inherit permission from skype.com?

2. If so, how can a website mitigate the risk of permission being silently taken to third party website?

[kgil...@mozilla.com]

This is exciting news, thank you for implementing!

The WebXR Devices API will be shipping imminently by multiple vendors, with feature policy integration:

https://immersive-web.github.io/webxr/#feature-policy

The "xr-spatial-tracking" feature policy will effectively grant permission to use the calculated position and orientation of a headset and controllers in space, required for "immersive" VR and AR sessions.

Could such an "xr-spatial-tracking" feature be enabled by the "dom.security.featurePolicy.experimental.enabled" preference?

If so, what would the conditions be to later move features from an experimental state to being enabled by default?

[Thomas Nguyen]

I did not notice your question, my account somehow did not get any notification from this thread. At the moment, there're still changes in specs and we only support "permission type" feature (having a UI prompt/dialogs). The experimental list is for unstable spec features or without UI changes. I don't find it is too hard to add xr-spatial-tracking to the experimental list (then you can flip dom.security.featurePolicy.experimental.enabled), or even add to supported list after you have a UI prompt and stable specs.

[Thomas Nguyen]

On Monday, November 25, 2019 at 10:38:28 PM UTC+1, s.h...@gmail.com wrote:
> 1. If a user already gave permission to certain origin (e.g. skype.com), and that origin had HTML injection, does that mean attacker can now silently inherit permission from skype.com?
>
> 2. If so, how can a website mitigate the risk of permission being silently taken to third party website?

Yes, I agree it might be a thing we should consider because we grant permission access broader. However, if the origin is vulnerable, I don't think we could protect more. If you have granted access to the origin, the origin can expose data to other via postMessage (or other mechanisms).

[s.h.h...@gmail.com]

How will you leak Geo Location, Camera data, etc, using HTML injecting? I’m saying the origin is vulnerable to HTML injection, and origin is not malicious.

[Thomas Nguyen]

On Wednesday, November 27, 2019 at 4:55:35 PM UTC+1, s.h...@gmail.com wrote:
> How will you leak Geo Location, Camera data, etc, using HTML injecting? I’m saying the origin is vulnerable to HTML injection, and origin is not malicious.

Thanks, yes, that is a consideration we should care about, of giving broader permission access and obviously, this is not ideal. I have not added any mitigation to the implementation yet.
Conversely, there would be another attack to link to attacker spaces on already-trusted sites (but not top-level) and get silently access too. I think there would be a trade-off between them. Besides, if a user granted skype.com, the origin is vulnerable to HTML injection, then when an attacker requests a permission grant, the users may not have any context for or understanding of them, that is very confusing and users tend to accept that request because they are under a trusted context of the top-level origin.

[s.h.h...@gmail.com]

>Conversely, there would be another attack to link to

>attacker spaces on already-trusted sites (but no top-level) >and get silently access too.
That is not silent, because user would have already granted permission to that origin to access in previous model.

>Besides, if a user granted skype.com, the origin is
>vulnerable to HTML injection, then when an attacker
>requests a permission grant, the users may not have any
>context for or understanding of them, that is very
>confusing and users tend to accept that request because
>they are under a trusted context of the top-level origin.

So the way you are solving this problem is, instead of showing prompt with iframe’s origin, just delegate permission from top frame or request permission with the origin of top frame? How did that made the situation better? You are ultimately taking away origin indicator from people who understood what it means :(

I’m really disappointed that Firefox is taking this path.

[Thomas Nguyen]

The idea to change comes from a couple of reasons. One as I mentioned, there were attacks, deep linking to attacker spaces on already-trusted sites (not the top), and a couple of UI issues that could be resolved by this simplification.
So sorry if it hurts your, anw, thanks for your idea, we will look into that to see if we have any mitigation

[Nils Ohlmeier]

Hi Thomas,

Thank you for pushing feature policy over the finish line and making the web a safer place!

Best
Nils Ohlmeier

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Johann Hofmann]

I think the main question that needs to be answered here is: "How does that
make the situation better?" There is an extensive document from the Chrome
team
<https://docs.google.com/document/d/1x5QejvpyQ71LPWhMLsaM1lWCfSsBsSQ8Dap9kJ6uLv0/edit?ts=5b857603#heading=h.ib6rctasbt3y>
on their motivation, but I'd like to add some things on the Firefox side.

Let's examine the current situation in Firefox, which, in my opinion (as
someone who's partly responsible and wants to fix it), is quite bad. We
have two big problems:

When an origin requests access to a permission (either as first or third
party) and the user wants to remember this decision, the Firefox permission
manager by default stores a key-value pair consisting of origin and
permission value[0]. It does not "double-key", so there's no
differentiation between first or third party access. This means an embedded
google.com iframe, having access to your geolocation through google.com/maps,
can track your geolocation around the web. Or someone deep-links into
google hangouts in an iframe and records you. Fun. In Firefox's defense,
unlike in Chrome, the permission is not stored permanently by default, it's
an optional choice that few users actually make.

This problem could be easily[1] solved by double-keying permissions. So
that would be good, if it wasn't for another problem:

As outlined in the Chrome document, there is strong evidence that most
users (except maybe you, me and everyone else on this thread) can not
reason about the concept of iframes, at all. So asking users to make a
reasonable choice if "google-hangouts-secure-connection.com" on google
hangouts should get camera access or not is *a lot* to ask (assuming they
even look at the origin). Then there's the UX that needs to be built for
managing the permissions users granted. To enable proper configuration, you
basically have to model the frame tree in all your UI and hope users
understand it.

Some time ago the Chrome team came up with an approach to solve this.
Permission delegation enabled by Feature Policy. It solves both issues
outlined above by taking some responsibility away from the end user and
putting more responsibility in web developers hands. I fully understand
that as a security researcher you've seen how that can go wrong and that as
an advanced user you feel secure with the current system. We agree to a
certain extent and we've taken a *long* time considering, standardizing and
implementing this approach.

The concept isn't perfect and of course it clashes with double-keying, so
we can't have both. As mentioned earlier, there are a few things we as
Mozilla have found too lax on the security side (like the "*" attribute)
and have thus modified in our implementation. You are right that this will
slightly increase the impact of HTML injection attacks under certain
conditions.

Nonetheless, after all consideration, we think this concept is the best
combined solution to both outlined problems that we've seen so far, which
is why we want to move ahead and ship it.

Cheers,

Johann

[0] it stores more than that of course, like expiry information, but not
the first party identifier by default
[1] conceptually easy. The implementation is messy, which we know since
we've recently built this as part of first-party isolation (for Tor) and
are still dealing with the fallout

[s.h.h...@gmail.com]

2019年12月6日金曜日 7時12分47秒 UTC-8 Johann Hofmann:

Thanks for the detailed explanation, it's good to have all the context :)

> It solves both issues
> outlined above by taking some responsibility away from the end user and
> putting more responsibility in web developers hands.

You are increasing the responsibility of web developers, but what mitigation(s) did you provide to web developers?

For example:
1. Have you broadcasted the message to have "Feature-Policy: blah 'none'" response header to all of webpages if they don't use any powerful features that requires permission?
2. What mitigation did you provide if a developer needs access to camera (for example) but doesn't want any other origins to inherit the permission via iframe?