search

w3c / webappsec

Web Application Security Working Group repo
https://www.w3.org/groups/wg/webappsec/
Other
606 stars 148 forks source link

CSP: Change the scope of the Permissions API #312

Open andyearnshaw opened 9 years ago

andyearnshaw commented 9 years ago

I work for a large-scale adserving company who hosts third-party creatives on our CDN. One of the challenges we have at the moment is controlling the scope of the Permissions API. Consider the following case:

  1. User visits a website with an ad placement served from our CDN.
  2. User interacts with the ad, which wants to show him offers from local businesses close to him, asking to locate him via the Geolocation API.
  3. User disallows access to Geolocation API and stops interacting with the ad.
  4. Later, user visits another website with a different ad placement served from the same CDN.
  5. User interacts with the ad, which shows him a map with all the advertiser's retail stores as markers on the map.
  6. User repeatedly clicks the "locator" button on the map with frustration, but it has no effect because he already denied permissions to the Geolocation API earlier, and this applied to the entire CDN domain.

Given that, I'd like to suggest that a new directive could be implemented to change the scope of permissions from applying to an entire origin, to origin + path. For example, given the URL http://cdn.mydomain.com/1234567/12345/index.html, a relative or absolute path could be supplied. The following would be synonymous:

Content-Security-Policy: permissions-scope ../
Content-Security-Policy: permissions-scope /1234567/

Obviously an absolute URL would need to match the current origin and be part of the current path's tree. For our use case, this would scope the permissions to a specific campaign, so other campaigns would need to request permissions for themselves.

This could also be useful for other sites hosting third-party content, such as JSFiddle, CodePen, or eBay listings. Is this something that could be considered for the specification?

hillbrad commented 9 years ago

I think we could have a CSP directive that disabled the permission (even if previously enabled on the origin), and the ability to ask for it, on a resource-by-resource basis. I'm in the exact same situation as you and would love to be able to do that.

But placing a resource in a permission jail is different than trying to achieve a finer-grained permission API. Because the Same Origin Policy doesn't place security barriers between resources at the same origin, a path that is denied can always compel a path that is allowed to act as its deputy. So you can selectively deny, but you can't selectively grant.

On Mon, Apr 27, 2015 at 1:37 PM Andy Earnshaw notifications@github.com wrote:

I work for a large-scale adserving company who hosts third-party creatives on our CDN. One of the challenges we have at the moment is controlling the scope of the Permissions API. Consider the following case:

  1. User visits a website with an ad placement served from our CDN.
  2. User interacts with the ad, which wants to show him offers from local businesses close to him, asking to locate him via the Geolocation API.
  3. User disallows access to Geolocation API and stops interacting with the ad.
  4. Later, user visits another website with a different ad placement served from the same CDN.
  5. User interacts with the ad, which shows him a map with all the advertiser's retail stores as markers on the map.
  6. User repeatedly clicks the "locator" button on the map with frustration, but it has no effect because he already denied permissions to the Geolocation API earlier, and this applied to the entire CDN domain.

Given that, I'd like to suggest that a new directive could be implemented to change the scope of permissions from applying to an entire origin, to origin + path. For example, given the URL http://cdn.mydomain.com/1234567/12345/index.html, a relative or absolute path could be supplied. The following would be synonymous:

Content-Security-Policy: permissions-scope ../ Content-Security-Policy: permissions-scope /1234567/

Obviously an absolute URL would need to match the current origin and be part of the current path's tree. For our use case, this would scope the permissions to a specific campaign, so other campaigns would need to request permissions for themselves.

This could also be useful for other sites hosting third-party content, such as JSFiddle, CodePen, or eBay listings. Is this something that could be considered for the specification?

— Reply to this email directly or view it on GitHub https://github.com/w3c/webappsec/issues/312.

andyearnshaw commented 9 years ago

I hadn't thought of that, I guess a resource could just frame another resource on the site and use its permissions. Selectively denying permissions might be something that we do, or force a prompt each time a resource is loaded, if those were possible.

Ideally, we don't want to cut clients off completely from these APIs, we just want to sandbox them. So how about a directive to sandbox a resource entirely, for not just the permissions API, but to treat a tree as a completely separate origin to another tree? This would apply to permissions, canvas tainting, XHR and everything else that would otherwise be managed by the same origin policy.

hillbrad commented 9 years ago

You mean this? http://www.w3.org/TR/CSP2/#directive-sandbox

It is very unfortunate that the sandbox attribute was designed to be deny-by-default with flags to re-enable things, as this makes it very difficult to add new restrictions (like restricting the ability to ask for permissions) without potentially breaking existing deployed systems. But this may be a reasonable thing to add to the HTML sandbox directive.

On Tue, Apr 28, 2015 at 12:48 AM Andy Earnshaw notifications@github.com wrote:

I hadn't thought of that, I guess a resource could just frame another resource on the site and use its permissions. Selectively denying permissions might be something that we do, or force a prompt each time a resource is loaded, if those were possible.

Ideally, we don't want to cut clients off completely from these APIs, we just want to sandbox them. So how about a directive to sandbox a resource entirely, for not just the permissions API, but to treat a tree as a completely separate origin to another tree? This would apply to permissions, canvas tainting, XHR and everything else that would otherwise be managed by the same origin policy.

— Reply to this email directly or view it on GitHub https://github.com/w3c/webappsec/issues/312#issuecomment-96965438.

andyearnshaw commented 9 years ago

Yeah, adding it to the sandbox directive sounds like it might be a good idea. What's the process for new proposals like this?