W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2015

Re: Comments/Questions on Media Capture Streams – Privacy and Security Considerations

From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 2 Nov 2015 06:50:15 +0900
Message-ID: <CABcZeBPFOXsACXnQ5btYVvfJte4TZgNmWDVT0QfY-J1k=1Hx5A@mail.gmail.com>
To: Mathieu Hofman <Mathieu.Hofman@citrix.com>
Cc: Nick Doty <npdoty@w3.org>, Martin Thomson <martin.thomson@gmail.com>, Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
On Mon, Nov 2, 2015 at 12:05 AM, Mathieu Hofman <Mathieu.Hofman@citrix.com>
wrote:

>
>
>
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* Tuesday, October 27, 2015 3:45
> *To:* Nick Doty <npdoty@w3.org>
> *Cc:* Mathieu Hofman <Mathieu.Hofman@citrix.com>; Martin Thomson <
> martin.thomson@gmail.com>; Harald Alvestrand <harald@alvestrand.no>;
> public-media-capture@w3.org; public-privacy (W3C mailing list) <
> public-privacy@w3.org>
> *Subject:* Re: Comments/Questions on Media Capture Streams – Privacy and
> Security Considerations
>
>
>
>
>
>
>
> On Tue, Oct 27, 2015 at 1:44 AM, Nick Doty <npdoty@w3.org> wrote:
>
> On Oct 27, 2015, at 10:53 AM, Mathieu Hofman <Mathieu.Hofman@citrix.com>
> wrote:
>
> 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."
>
> 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.
>
>
>
> I think what was meant here is that CSP be present when saving the
> persisted permission and when using a saved persisted permission. The
> content of the CSP doesn’t have to be the same, just that it be enabled
> during both save and read of the persisted permission. That way, the site
> was hopefully protected when the user first granted the persisted
> permission and later still protected when the site uses a stored persisted
> permission.
>
>
>
>
>
> 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.
>
>
>
> Well if there was originally no CSP, the persisted permission would not
> have been stored, so there should be a user prompt. The CSP requirement
> wouldn’t protect a new user visit, just a repeated visit. The 2 vectors
> left are: site is vulnerable despite CSP presence (bad CSP); and website
> had CSP, user granted persistent permissions at that point, website removed
> CSP, gets compromised, and attack re-injects own CSP. In both cases, the
> developer arguably didn’t implement CSP correctly, but it’s not a failing
> of CSP itself.
>

No, it's not, but given how commonly it happens, I don't think it's
appropriate
to mandate CSP in this context.

-Ekr



>
> Mathieu
>
Received on Sunday, 1 November 2015 21:51:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:34 UTC