W3C home > Mailing lists > Public > public-privacy@w3.org > October to December 2015

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 28 Oct 2015 06:01:55 -0400
Message-ID: <CABcZeBM-x9W79SGMo_mpW_EMESnPR7DW2jU9ddWu-6F6JDqZyQ@mail.gmail.com>
To: Nick Doty <npdoty@w3.org>
Cc: Mathieu Hofman <Mathieu.Hofman@citrix.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
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)
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
like a huge barrier to entry to persistence, with the negative results of

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

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


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.
Received on Wednesday, 28 October 2015 10:03:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:49:31 UTC