- From: Eric Rescorla <ekr@rtfm.com>
- Date: Mon, 2 Nov 2015 06:50:15 +0900
- 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>
- Message-ID: <CABcZeBPFOXsACXnQ5btYVvfJte4TZgNmWDVT0QfY-J1k=1Hx5A@mail.gmail.com>
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