Re: Restricting APIs in CSP

On 11/2/12 1:48 PM, Eric Rescorla wrote:
> I've been starting to wonder if it's worth having a mechanism to restrict
> access to APIs in CSP.  A good example here is getUserMedia(),
> which allows access to the camera and microphone.

The sites most at risk won't know to fill out this list of forbidden 
functions. Could we turn it around and require sites to supply a CSP if 
they want to use WebRTC, and only pages that "enable getUserMedia" get 
to use it?

> 1. Does this sound like a plausible goal to people?
> 2. Any suggestions about the syntax?

1. This fits nicely with the design/goals of CSP in that it allows a 
resource to declare "I don't use X,Y,Z" so that the UA can stomp on 
injected attempts to use those features.

2. I prefer an enabling syntax to a forbidding syntax but that might be 
a hard sell. We should explore what other features might be worth 
restricting in this way.

This can't be considered a UA mechanism to protect web surfers from 
potentially dangerous code that is attacking the browser itself -- 
obviously attackers would simply provide the required header. But if 
there are features that can be used by injected code to attack a site's 
capabilities or the user data they store it might be worthwhile.

The ability to lock document.cookie might be interesting. That one would 
have to use a "forbid" syntax though, we'd break the web if we suddenly 
started to require an "enable" header.

forbidding getUserMedia, or requiring it to be enabled, sounds a lot 
like the things <iframe sandbox> and the corresponding CSP sandbox 
directive do so maybe that's the right place for it.

-Dan Veditz

Received on Friday, 2 November 2012 14:57:56 UTC