W3C home > Mailing lists > Public > public-privacy@w3.org > July to September 2015

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

From: Mathieu Hofman <Mathieu.Hofman@citrix.com>
Date: Mon, 21 Sep 2015 20:03:06 +0000
To: Harald Alvestrand <harald@alvestrand.no>, Nick Doty <npdoty@w3.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
CC: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Message-ID: <3CD080DCDA030D47B8ED720F6B99FC810D4F4A08@SJCPEX01CL02.citrite.net>
Quick thoughts on XSS attack and persistent permissions.

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Monday, September 21, 2015 4:23
To: Nick Doty <npdoty@w3.org>; public-media-capture@w3.org
Cc: public-privacy (W3C mailing list) <public-privacy@w3.org>
Subject: Re: Comments/Questions on Media Capture Streams – Privacy and Security Considerations


On 07/14/2015 04:28 AM, Nick Doty wrote:

The "note" section includes a description of a very serious attack. Is there anything that can be done about this beyond a note to website implementers, who may never read this section of the specification? Is it the case that any site that requests getUserMedia permission that subsequently suffers any sort of XSS vulnerability or URL parameter failure as you note will silently give live access to the user's video/audio to an attacker? As a site developer, am I liable if I use getUserMedia in one part of my site, users persist the permission and then somewhere else on my site I have a bug that allows for XSS or a URL parameter failure?

I'm not sure what the word "liable" means in this context - it's a word I usually try to avoid using unless I'm sure what I mean by it.

Any site that requests getUserMedia permission and has that permission persisted will have access to that permission - that's a given. If the site can be tricked into running other sites' Javascript - that site has a problem. I think that's an issue in all contexts, since running other sites' Javascript immediately renders all the considerations for "secure origin" null and void.

I don't know that this is something that Media Capture needs to call out specifically.



One way to help developers avoid this catastrophic scenario would be to allow sites to indicate whether they were confident about opting in to persisted permissions. A casual developer who calls getUserMedia() wouldn't have to worry about that failure due to some bug on their site. A serious developer who is confident about their security situation and whose functionality would benefit greatly from persistence could call getUserMedia(allowPersist=true).

Hm. I'd like to hear others' opinions on this.

Aren’t other permissions such as location not vulnerable to the same attacks? Does any of them have a similar “opt-in persist” mechanism?
I understand audio/video device access is a little more sensitive than location, so here is a possibility I might be able to live with: to make sure the developer understands the risk of XSS attacks on device access, make CSP (Content Security Policy) a requirement for persistent permissions to be saved/used. I don’t think we should be specific about the content of the CSP, just that it be there as acknowledgement to the risk, both when saving the persistent permission, and when allowing access without prompt when the origin has persistent permission already granted. The latter part is to protect against a secured media application on one location, but less secured pages at other location on the same origin.
I’m curious to hear others’ thoughts on this?
Received on Monday, 21 September 2015 20:03:40 UTC

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