CSP as a signal for permission persistence (was Re: Comments/Questions on Media Capture Streams – Privacy and Security Considerations)

To be clear, my suggestion was for the site developer to have an optional flag to indicate that persisting permission was unlikely to make sense for their site.

But, for the purpose of exploring the possibility of using CSP as a signal, responses inline below.
—Nick

> On Oct 27, 2015, at 7:45 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
>>> At the least, I think Mathieu's suggestion about CSP might be useful in
>>> updating that section of the spec. We could give more specific
>>> recommendations about use of CSP and maybe user agents can take that
>>> signal into account when determining whether to grant a permission based
>>> on a prior granting.
>> 
>> Actually I'm coming back on my original idea. I don't think CSP can be of any help, now that I realize CSP can be added to a compromised page using html meta element.
> 
> That certain attackers can add CSP policies doesn't prevent their usefulness in this area. What we're concerned about is whether a previously-provided permission grant for getUserMedia can be safely relied on for later access to camera/microphone without a permission prompt. If a CSP policy is in place when getUserMedia was first used by a site and is still in place, then the browser can be provided some confidence that a permission still makes sense and is relatively less likely to be a XSS attack.
> 
> Wait, now you want the browser to *persist* the CSP policy and check
> that the same policy is still in place? That's totally infeasible, if only
> for the obvious reason that either (a) we check that the CSPs are
> identical in which case we'll get all kinds of false positives or
> (b) we have to do some kind of "substantively the same" check.

It might make most sense for browsers just to check at the time that a permission is first granted whether a relevant CSP is present and use that as a signal in determining whether to persist the permission grant.

I think it's possible that a browser might want to do some sort of checking/comparing of policies over time in determining the safety of automatically providing access, but I agree that specifying that seems difficult.

> If you called getUserMedia on your small site and don't have a CSP policy and someone later finds an XSS attack, the lack of a CSP might be an indicator for the user agent not to persist the permission request.
> 
> But again, since the attacker can *inject* CSP of his own, any check that
> relies on the existence of CSP is trivial to circumvent.

The security problem that we were particularly noting here was that a site developer (not currently under attack) would use the getUserMedia API and get permission from the user that was persisted by the browser, either via user checkbox or automatically; subsequently, an attacker using XSS (or session fixation or URL parameter problem) could access the camera without a permission prompt. If browsers were to take the presence of a CSP at the time of the initial API call as a signal for persisting permission, then the fact that the attacker could introduce a CSP policy via tag during their subsequent attack wouldn't make a relevant difference.

In other discussions today, people have suggested that maybe a browser could interpret a different signal to CSP provided through HTTP header vs. that provided in a meta tag; I'm not entirely sure WebAppSec would want to make that a general distinction, but in any case I don't think it's necessary here.

>> At the least, I think Mathieu's suggestion about CSP might be useful in updating that section of the spec. We could give more specific recommendations about use of CSP and maybe user agents can take that signal into account when determining whether to grant a permission based on a prior granting.
>> 
> I don't have a problem with recommending that people use CSP, but I don't agree that
> it makes sense to require browsers to take that into account, at least at the time
> of grant use for the reason I indicated previously.

Sorry, I'm not sure if you meant that 1) presence of a CSP at the time that getUserMedia permission is granted by the user shouldn't be considered for persisting that permission for subsequent getUserMedia calls or 2) presence of a CSP at the time of a getUserMedia call shouldn't be considered in determining whether permission should be granted automatically. (I think I might agree with 2, but probably not 1.)

>> What we're saying is that every XSS or related security bug you have in the future, in addition to having security implications for your site's business, will also expose every previous user of your site to video and audio surveillance. It's not, "using this API involves sensitive data, so audit to find security bugs when you're using it", but rather "if you ever used this, you have to commit to perfect security diligence in perpetuity."
>> 
> Well, again, not in Firefox, because Firefox doesn't persist permissions by default.

The site might have visitors using browsers other than Firefox. If we were to conclude that the current Firefox behavior is the only safe way to implement this for sites like the one in my example, then that would be something to specify for interoperability. It sounds like browser vendors weren't in agreement on that, though.