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

On Mon, Sep 21, 2015 at 1:03 PM, Mathieu Hofman <Mathieu.Hofman@citrix.com>
wrote:

> 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?
>
I would not be in favor of this. Measurements by some of my Mozilla
colleagues
suggest that it's quite common for people to have ineffective CSPs, and this
just seems like a recipe for yet people to have useless CSPs in order to get
access to the camera/microphone.

WRT to the specific suggestion of requiring a CSP at time of *use* of
persistent permissions, if we assume that the attacker can do JS injection
(which seems like a requirement to exploit an issue of this type), then
I believe they will be able to do document.write() to insert a CSP, so this
doesn't seem like an effective security measure

-Ekr