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

On Wed, Oct 28, 2015 at 5:54 AM, Nick Doty <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> 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.
>