-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Send reports for Permissions Policy violations in iframe to parent frame's endpoint #537
Comments
I don't think that addresses the concern raised. And I don't think we can address the concern raised without compromising on the same-origin policy, which we shouldn't do. |
Right, the solution proposed will send a report for each iframes which has an allow attribute with denied origin, but it does not tell whether the permission was used inside an iframe. Any objection to implementing this? |
Yes, it's not clear to me it's solving an actual problem. |
@shhnjk, is the idea here that simply constructing an iframe, which tries to delegate a permission that it is not allowed to, would trigger a report in the embedding page? |
Yes, the idea is to report when the document delegates a permission to an iframe whose origin is not allowed to receive the permission in the Permissions Policy configuration. I think this has two main benefits:
Taking a step back, I see this as a relatively small change with large security impact because this is what any medium-sized application will need to be able to enable Permissions Policy restrictions and control cross-origin permission delegation. As @shhnjk mentioned at TPAC, this is currently a significant security gap for applications which use strict CSP - an HTML injection can delegate any of the affected origin's permissions to the attacker, even if the attacker is prevented from executing script in the affected app by CSP. It seems useful for developers to be able to prevent this (which would also help them ensure their third-party widgets don't overly broadly delegate the top-level application's permissions); and getting reports for cross-origin permission delegation is pretty much necessary for developers to be able to lock down their Permissions Policies. |
Thanks, @arturjanc -- that makes sense. I was having trouble imagining the use case, but that makes it much more concrete. A couple of questions --
|
Ah, interesting. I see that Permissions Policy has only a single report type of
This is an excellent point. My understanding is that a cross-origin navigation in an iframe with delegated permissions will remove permission delegation unless the post-navigation origin is explicitly specified in the To address this, @shhnjk suggested that the violation report could contain the full allowlist specified in the Also, I think it's quite rare in practice for permissions to need to survive cross-origin iframe navigations. So even without this additional reporting I expect most developers would be able to safely roll out locked down Permissions Policies if we give them "incorrect delegation" reports.
Yes, I think so. |
That's correct, and it was designed to be safe in that way. And by default, if you just specify These can get out of sync in two ways, though. First, you could try to delegate permission to a page that redirects away: Permissions-Policy: fullscreen=(self, "https://adnetwork.example") <iframe src="https://adnetwork.example/" allow="fullscreen"></iframe> If the frame does a 302 redirect to https://advertiser.example, then the permission will be blocked, but we can't report on that. Conversely, if you did something like Permissions-Policy: fullscreen=(self, "https://github.com") <iframe src="https://www.github.com/" allow="fullscreen"></iframe> Then this proposal would report that as a violation. However, when the frame redirects from www.github.com to github.com (no www.), the feature would in fact be allowed in the frame. I think this is the best we can do, though, without revealing anything more about the actions within the frame itself. |
Permissions-Policy: fullscreen=(self, "https://adnetwork.example")
<iframe src="https://adnetwork.example/" allow="fullscreen"></iframe>
I agree, but in this case the permission will be blocked not because the developer added the If we see reporting as a way to enable developers to set restrictive Permissions-Policy: fullscreen=(self, "https://github.com")
<iframe src="https://www.github.com/" allow="fullscreen"></iframe>
This kind of false positive is fine - practically, the worst that would happen is that developers would see violations for |
I agree with @arturjanc that the false positive would be fine.
Maybe I prefer to have additional disposition types, which are |
@annevk, let us know your thoughts given above discussions. |
I'm still not really convinced this is solving anything. This is information you by-and-large already have access to and wouldn't help with removing origins that may or may not use a permission.
I guess that means the header can override the |
Violation reports delivered by the Reporting API (for features such as CSP, COEP, Permissions Policy, etc.) often have information that the page has access to in principle, but which is quite difficult to collect in practice. For example, instead of CSP violation reporting a page could load a script to look at its DOM and find all instances of inline event handlers, resource locations, etc., and then send this information to the server to check if a given CSP would be compatible with the application. However, this runs into two substantial practical problems:
This is why HTTP header-based report-only violation reporting is really necessary in practice when enabling any kind of security policy that restricts what an application can do -- in this case, to restrict where permissions can be delegated.
The case we're discussing here is an application that doesn't yet use Permissions Policy, but would like to enable it to restrict which embedded origins can request permissions (e.g. to protect users from sensitive permissions being delegated to an attacker-controlled iframe in the case of any HTML injection). Without this reporting change it's practically extremely difficult to enable any Permissions Policy in a moderately complex application, because enforcing the policy would break all instances of cross-origin permission delegation, without notifying developers of this fact through report-only violations. @annevk you're right that if an application already legitimately delegates an unused permission to an origin then this model would not let the developer know that the permission is unused and would result in this origin being allowlisted in the Permissions Policy. But even if this happens then an enforcing policy will just allowlist a small number of potentially unnecessary origins, but still prevent delegation to any other location, e.g. in case of an HTML injection. IMO this is a very small price to pay in order to both unblock useful violation reporting for Permissions Policy and keep this in line with the same-origin policy and avoid exposing any information about the activity of cross-origin frames.
@clelland knows more about this, but I don't think so. IIUC if an iframe's Actually, I think we got confused here because in Ian's scenario ( |
Not really -- in that example, the header allowed only
That's true -- although I usually think about it the other way: if the header specifies a list of origins, the allow attribute can't delegate to anything not on that list. But it's an AND operation between the two, so the logic works either way. |
Oohhh... I got confused there, too :( You're correct, and the way I worded it, even post-redirect, the permission shouldn't be allowed. The scenario I meant to describe was one where the HTML looked like <iframe src="https://www.github.com/" allow="fullscreen *"></iframe> In this case, the header would block fullscreen if the page loaded in the frame came from |
I'm really appreciative of the direction we're taking with this change, aiming to simplify the process for web developers to implement secure, non-breaking permission policies. One aspect I'd like to understand better is how this proposed change would affect reporting in scenarios where permissions are implicitly delegated to iframes (i.e. iframes that don't use the My assumption is that the proposed changes wouldn't impact such implicit delegations of permission. Reporting only permissions that are implicitly delegated due to usage in such iframes could leak usage information from the framed origin. Conversely, reporting all permissions that could be implicitly delegated to such iframes could generate a large volume of reports that aren't particularly meaningful. @shhnjk, could you confirm if my understanding is correct? Specifically, would this proposed change not impact cases where permissions are implicitly delegated without the |
I'm not sure if there is an example of a permission which implicitly delegates without declaring in the |
I stand corrected. After further testing, I've confirmed that permissions are not implicitly delegated to frames. Thank you for the clarification! |
@clelland, should we create new disposition types called |
From https://crbug.com/1501168:
So far, the discussion has been leaning to send reports whenever iframe's
allow
attribute was specified with an origin which is blocked by the Permissions Policy.To implement this, we will likely add Is feature enabled in document for origin to Parse policy directive.
We'd like to know if there is a concern to this change.
CC: @arturjanc, @mikewest, @ddworken, @salcho
The text was updated successfully, but these errors were encountered: