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

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Friday, October 23, 2015 20:39
To: Mathieu Hofman <Mathieu.Hofman@citrix.com>
Cc: Harald Alvestrand <harald@alvestrand.no>; Nick Doty <npdoty@w3.org>; 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 Mon, Sep 21, 2015 at 1:03 PM, Mathieu Hofman <Mathieu.Hofman@citrix.com<mailto:Mathieu.Hofman@citrix.com>> wrote:
Quick thoughts on XSS attack and persistent permissions.

From: Harald Alvestrand [mailto:harald@alvestrand.no<mailto:harald@alvestrand.no>]
Sent: Monday, September 21, 2015 4:23
To: Nick Doty <npdoty@w3.org<mailto:npdoty@w3.org>>; public-media-capture@w3.org<mailto:public-media-capture@w3.org>
Cc: public-privacy (W3C mailing list) <public-privacy@w3.org<mailto: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

CSP is an HTTP header so you can’t inject it using JS.
From what I understand, if CSP is effectively used by the developer, the XSS attack is effectively prevented.

I agree that ineffective CSP could be a problem. Couldn’t this be solved by better tooling?
Also developers wouldn’t need CSP to get access to mic/webcam, but to persist the permission / use a persisted permission.

Mathieu