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

My initial design thoughts would tend towards use of HTML5 sandboxing (perhaps delivered by CSP) to place a document in its own origin and so drop privileges implicitly.  Any other approach is somewhat suspect, because if the document you want to restrict is still same-origin and can run script, it can always open an iframe to another resource at the origin that doesn't drop privileges and do what it wants by manipulating that.

If you want to permanently drop permissions until granted again, (instead of just exempting certain resources from accessing them) either adding that capability to the Permissions API or extending Clear Site Data would be good paths forward.

-Brad

From: Nick Doty <npdoty@w3.org<mailto:npdoty@w3.org>>
Date: Tuesday, November 10, 2015 at 1:12 PM
To: Bradley Hill <hillbrad@fb.com<mailto:hillbrad@fb.com>>
Cc: Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>, Mathieu Hofman <Mathieu.Hofman@citrix.com<mailto:Mathieu.Hofman@citrix.com>>, "public-media-capture@w3.org<mailto:public-media-capture@w3.org>" <public-media-capture@w3.org<mailto:public-media-capture@w3.org>>, "public-privacy (W3C mailing list)" <public-privacy@w3.org<mailto:public-privacy@w3.org>>
Subject: Re: CSP as a signal for permission persistence (was Re: Comments/Questions on Media Capture Streams – Privacy and Security Considerations)

Thanks, these are good points, and very useful, especially as we had heard this CSP suggestion in multiple places.

Regarding the earlier suggestion and the larger question about sites that might want to avoid persistence of a permission, my understanding of the WebRTC discussion at TPAC was that the most promising option, if the group were to address this use case/mitigation, was to have a method for revocation, either as part of getUserMedia or as a general part of the Permissions API. So, for the use case of a site that asked for camera access just for an avatar image, say, they could request permission and subsequently revoke any permission that might have been stored after the user profile image section of signup is finished. That would also help for a user logging out of the service, perhaps.

(That might be repetition for some people who were present at those discussions, but I thought it was worth catching people up on the lists.)

Thanks,
Nick

On Nov 9, 2015, at 12:57 PM, Brad Hill <hillbrad@fb.com<mailto:hillbrad@fb.com>> wrote:

I think it is a bad idea to regard the presence of a CSP, even a "non-trivial" one, as an indicator that a site is free of XSS, let alone CSRF, or other types of confused deputy or elevation of privilege issues which might leverage a previously granted permission.  This is doubly so because CSP is granular to the resource, but permission grants are granular to the origin.  It makes no sense to talk about the CSP for an origin, as one might for, say, the HSTS policy.

-Brad Hill

From: Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>
Date: Wednesday, October 28, 2015 at 2:01 AM
To: Nick Doty <npdoty@w3.org<mailto:npdoty@w3.org>>
Cc: Mathieu Hofman <Mathieu.Hofman@citrix.com<mailto:Mathieu.Hofman@citrix.com>>, "public-media-capture@w3.org<mailto:public-media-capture@w3.org>" <public-media-capture@w3.org<mailto:public-media-capture@w3.org>>, "public-privacy (W3C mailing list)" <public-privacy@w3.org<mailto:public-privacy@w3.org>>
Subject: Re: CSP as a signal for permission persistence (was Re: Comments/Questions on Media Capture Streams – Privacy and Security Considerations)
Resent-From: <public-privacy@w3.org<mailto:public-privacy@w3.org>>
Resent-Date: Wednesday, October 28, 2015 at 2:03 AM

On Wed, Oct 28, 2015 at 5:54 AM, Nick Doty <npdoty@w3.org<mailto:npdoty@w3.org>> wrote:
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.

As I said, this was in the original spec and explicitly discarded because
neither browser had an interest in implementing it.


On Oct 27, 2015, at 7:45 PM, Eric Rescorla <ekr@rtfm.com<mailto: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.

What do you believe a "relevant" CSP would be? The available data suggests that even
when people choose to deploy CSP, they often deploy CSP that (for instance) allows
unsafe-inline. So, either we accept trivial CSPs (in which case that is what we will
get and the world will arguably be worse) or we require strong CSPs, which seems
like a huge barrier to entry to persistence, with the negative results of non-persistence

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.

As I understood Mathieu's suggestion, it included checking CSP at the time of the
subsequent (persisted) permission request. My point is that that's not useful because
of meta-CSP.

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.)

I meant that #2 doesn't make technical sense, but I'm skeptical of #1 for the reasons
above.


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.

Yes, and those browsers need to make their own choices about how to protect
their users.

-Ekr

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.