Comments (17)
If we grant X to iframe, that iframe can embed any other iframe and grant X to its descendant...
IMO redirects are fair game here. If we grant X to an origin/frame and that frame redirects, then it is, in effect, delegating that (full/same) access to the redirect destination.
from webappsec-permissions-policy.
I wasn't thinking about redirects specifically. Consider the case where I embed "google.com" and give it geolocation access. The user does a search in the iframe and clicks on a search result which navigates to a random website, bad.com. In this case, neither the top level page, nor the embedded page has given any indication that bad.com should be given access.
We had the same principle of revoking access for permission delegation. I think the same applies here. Thoughts?
from webappsec-permissions-policy.
FWIW, I think redirects are very common.. if we revoke the feature on redirects, I think that'd be a very painful experience for a lot of pages.
Re, navigations: this smells like a CSP + FP policy combination.
<iframe enable="geolocation" src="https://foo.com"
csp="navigate-to https://foo.com https://bar.com">
The discussion for navigate-to is w3c/webappsec-csp#125, and rumor has it, embedded CSP implementation may be underway in Chrome. /cc @mikewest
from webappsec-permissions-policy.
FWIW, I think redirects are very common.. if we revoke the feature on redirects, I think that'd be a very painful experience for a lot of pages.
Hmm - I understand the concern now. I still don't feel very comfortable with this from a security standpoint though, at least in the general case of one site navigating to another, for example navigating by setting window.location or by a user clicking a link. There is no indication that the site trusts the feature to be delegated to the site being navigated to. Furthermore, the original origin is now out of the picture and is no longer an active actor in the scenario. It no longer holds any responsibility for the actions of the navigated site. It's different in that sense from the frame embedding a site and actively delegating access.
I think I'd feel more comfortable if ads that needed it added in an extra iframe in their chain where all the redirects happened and they could delegate access to all origins they embed.
I'd be curious of the view of some security folks too :)
from webappsec-permissions-policy.
The discussion for
navigate-to
is w3c/webappsec-csp#125, and rumor has it, embedded CSP implementation may be underway in Chrome. /cc @mikewest
The page can already limit the things its frames can navigate to by setting frame-src whatever.com
on its own policy. Embedded enforcement isn't necessary unless you want to govern the places to which an embedded frame can open a new window (but it is ~half done behind a flag in Canary).
One case to consider here is, the embedder says enable="geolocation" for an iframe initialized to "good-site.com" but then the iframe is navigated to "bad-site.com". We don't want geolocation to be enabled.
This is made worse by the fact that frames are navigable cross-origin. That is, if I have a handle to your window (via window.open
or window.opener
or by framing you or by you framing me), then I can cause your frames to navigate: otherWindow.frames[0].contentWindow.location = 'https://evil.com/'
.
It would be unfortunate if that gave folks a trivial way of gaining permissions that had been granted to someone else.
from webappsec-permissions-policy.
We decided on the syntax enable="feature"
as a kind of shorthand for iframes, declaring that it would mean "enable the feature for this frame", and not thinking that the origin embedded in that frame could change.
If that's problematic, (and it seems that it is,) then we could change the interpretation of the shorthand, to explictly mean: "enable the feature in this frame for the initial origin embedded in it".
We could also change the syntax, to require developers to write something like
<iframe src="https://benevolent.com/" enable="geolocation:benevolent.com" >
or even require something like the JSON used for the full policy:
<iframe src="https://benevolent.com/" enable='{"geolocation": "https://benevolent.com"}' >
If a site really wanted to allow a feature to all origins potentially embedded in the frame, then it could
<iframe src="http://www.dmoz.org/" enable="geolocation:*" >
to allow that.
from webappsec-permissions-policy.
@clelland that's a good point :) I think the simplest thing, most secure and most common case is to delegate the feature only to the initial origin. I feel like that's good syntax to keep.
We could add additional syntax to specify which origins specifically as you suggested - I think we would want to make it a bit scarier because I think the guarantees are much less obvious.
Just brainstorming: would a separate attribute feature-policy="..." which allows specifying a full policy to override the header, but only for that iframe be a better approach? This would be scarier/more complicated but give full control. The enable/disable syntax would just be sugar for specifying the full policy. Is there precedent for specifying json in an attribute?
from webappsec-permissions-policy.
Can we nail down the threat model we're trying to address and how and why existing methods are insufficient? I'm still dubious of the solutions we're driving towards here..
enable
inherently offers much weaker security guarantees because it allows the application to specify the FP policy at runtime (as long as the header and meta policy allows it). As such, if the top level page is XSS'ed.. the script can delegate permission to whomever it wants. The only way to avoid that is to eliminateenable
.- Once you've granted permission to a frame you're extending full trust to that frame to delegate that permission in whatever way they like -- e.g. they can inject a frame and delegate it further down the chain, they can redirect themselves to somewhere else -- same difference, I think.
As @mikewest pointed out, if the top-level frame wants to protect itself against subframe's navigating themselves, it can use frame-src.. For sub-iframes, I believe the same frame-src via embedded enforcement applies?
How or why is the above not sufficient? I'd rather layer the various mechanisms, instead of trying to reinvent the wheel multiple times.
@clelland that's a good point :) I think the simplest thing, most secure and most common case is to delegate the feature only to the initial origin. I feel like that's good syntax to keep.
Not sure if it's simple.. But I'm pretty confident it's a non-starter for most interesting use cases -- e.g. ads, which often bounce through a series of redirects.
from webappsec-permissions-policy.
I think what we're really discussing is what the scope of an "enable" attribute should be by default, i.e. to which origins in the iframe should it apply (@clelland stated it well above :).
@igrigorik it seems like your preference is that by default an enable attribute should apply to any origin that gets loaded in the iframe to which it applies. If the embedder wants to prevent this from happening they need to restrict navigations by using another mechanism, e.g. frame-src. Is that accurate?
I'm not sure this is the best approach. It seems too easy to accidentally give geolocation to any origin that gets loaded in the iframe, and these origins might not be trusted by anyone. It means that in order to achieve least privilege, a developer first has to open up a big hole with "enable" and then subsequently lock it down with extra navigation restrictions. I think that people will be shooting themselves in the foot because they don't realize how broadly they are delegating access and they forget/never realize to lock it down afterward (see the examples above). That's why it seems preferable (from a security standpoint) to go the other way around: by default "enable" is scoped to the initial origin and if a developer wants it apply more broadly they can explicitly specify that.
Not sure if it's simple.. But I'm pretty confident it's a non-starter for most interesting use cases -- e.g. ads, which often bounce through a series of redirects.
I agree :) I think we need to find a solution that addresses this too. I'm just not sure that having enable apply to all origins that get loaded (by default) is the best approach.
from webappsec-permissions-policy.
@igrigorik it seems like your preference is that by default an enable attribute should apply to any origin that gets loaded in the iframe to which it applies.
I wouldn't say it's a preference, as much as.. a coherency and layering question: if sandbox whitelist grants privilege to all origins of the frame, then FP should -- I think -- follow the same model. That way, at least we have a single and simple path for developers: if you need to constrain the granted privileges use frame-src, etc. Mixing frame-src with special enable syntax for FP, with.. (insert whatever other mechanisms we dream up later).. is unmanageable.
I understand your concerns though, and I agree with them. I'm just arguing for a single mechanism to govern all this, instead of ad-hoc approaches in each mechanism.
from webappsec-permissions-policy.
It's a good point that sandbox doesn't revoke access on navigations, but I think there is an important difference. Sandbox is all about locking things down, rather than giving extra privilege. It's more like the "disable" attribute than the "enable" attribute. I think it would be ok (preferable) for the "disable" attribute to apply to all origins that get loaded in the iframe, just not enable. With FP we're considering delegation of powerful features. We need to be very careful that trust has been explicitly expressed by someone before giving access. I don't think that happens when enable applies to all origins in a frame.
Going back to the original example I had, I don't think this will be acceptable from a security standpoint, even with the fact that navigations can be restricted:
Consider the case where I embed "google.com" and give it geolocation access. The user does a search in the iframe and clicks on a search result which navigates to a random website, bad.com. In this case, neither the top level page, nor the embedded page has given any indication that bad.com should be given access.
from webappsec-permissions-policy.
Well, there is a reason why we don't allow google.com to be iframed (x-frame-options:SAMEORIGIN).. :-) The destination can protect itself by x-frame-options, the embedder can protect itself via CSP frame-src, right?
That said, what's the concrete proposal we're evaluating at this point? As I said earlier, I think we're solving this at the wrong layer, but I'm happy to be convinced otherwise.
from webappsec-permissions-policy.
Well, there is a reason why we don't allow google.com to be iframed (x-frame-options:SAMEORIGIN).. :-) The destination can protect itself by x-frame-options, the embedder can protect itself via CSP frame-src, right?
I don't think the reason we prevent google.com from being iframed is related to this issue though? It's easy to use other sites as an example, like bing.com that don't have x-frame-options. I don't think this isn't about the embedder or the destination protecting itself - rather the embedder being very specific about who they delegate access to. Having a default that grants access very broadly is a recipe for the embedder giving access to someone unintentionally.
The options we were discussing were to have "enable" apply only to the origin in "src" by default and having a way to broaden that access if the embedder really wants to, for example by having an additional attribute which allows specifying a full policy to apply to that frame. There are lots of variations of that idea that I'm open to though.
from webappsec-permissions-policy.
Discussed on VC today, the proposal is:
<iframe href=foo.com featurepolicy='{"usermedia": ["*"]}'>
<iframe enable=usermedia href=foo.com>
The former enables "full policy" syntax, which also allows the embedder to delegate permission to all origins (e.g. to deal with unknown redirects, etc). The latter (shorthand) enable
attribute is, on the other hand, simpler and safer in that it implicitly only delegates permission to the origin specified by frame element's href
attribute value.
from webappsec-permissions-policy.
The shorthand is equivalent to:
<iframe src=foo.com featurepolicy='{"usermedia": ["http://foo.com"]}'>
but is shorter, and hopefully less error-prone
Also implcit in this is that the disable
attribute has been replaced with featurepolicy='{"usermedia": []}'
We still need to resolve what happens if both attributes are specified -- whether for the same, or for different features, and whether changing the src
attribute on the iframe
element (as opposed to having the iframe navigate itself) should change that implicit origin.
from webappsec-permissions-policy.
Updated proposal in https://docs.google.com/document/d/1k0Ua-ZWlM_PsFCFdLMa8kaVTo32PeNZ4G7FFHqpFx4E/edit#heading=h.t3vfp0hdaogx.
Anything else we need to address on this one, or can we close it and iterate in the explainer?
from webappsec-permissions-policy.
Closing this -- the end result of this is that the policy applied by the parent document to its child frames can specify a list of origins, (a single origin in the limit) or allow all origins loaded in the frame to use the feature ("*").
The iframe allow
attribute takes a list of feature names and creates a container-policy from them which applies to the document loaded in that frame (see https://wicg.github.io/feature-policy/#container-policies). That policy will contain, for each named feature, the single origin from the iframe element's src
attribute, so that if the framed document navigates away, the feature will not be allowed.
For compatibility, the allowfullscreen
and allowpaymentrequest
attributes behave similarly, but generate a container policy that matches all origins. This allows the framed content to navigate to a new origin which will still retain the ability to use the feature, matching the behaviour of those attributes today. (https://wicg.github.io/feature-policy/#legacy-attributes)
from webappsec-permissions-policy.
Related Issues (20)
- can anyone help me?
- support <meta http-equiv> mechanism to set the policy HOT 2
- document.featurePolicy vs document.permissionsPolicy HOT 2
- Clarify the expected usage of "Should request be allowed to use feature?"
- Potential bug in access delegation to cross-origin iframe for feature that has default allowlist value "self"? HOT 2
- allow disabled-by-default features HOT 5
- Does url match expression in origin with redirect count? takes a URL, not an origin HOT 7
- "If the allowlist contains an origin representing self" is unclear HOT 2
- Editorial: "If origin is opaque" needs to use a cross reference
- Inconsistency in text and parsing algorithm (invalid member value)
- Add "mediasession" to the list of permission policies HOT 1
- Set declared policy for powerful features to self by default HOT 9
- A request's "window" is never a Window HOT 1
- methiyaowala HOT 2
- Permissions Policy report missing a document URL HOT 2
- Send reports for Permissions Policy violations in iframe to parent frame's endpoint HOT 19
- > 07881334 2 002065 031525 054161 F-3525824 PANYA YAOWALA ( AIA ) 0107537002761 0872220535 3410200102061 *01401125350 341020009143 3410200102096 41001470 165467 T-078813339 T078813342
- Query: Can trusted subframe allocate permission to one of it's cross-domain subframe HOT 2
- [clipboard] document.execCommand('copy') and presumably paste bypass permissions policy
- Permissions Policy "deferred-fetch"
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webappsec-permissions-policy.