W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2013

Re: Why does screen sharing require a browser extension?

From: Roman Shpount <roman@telurix.com>
Date: Wed, 27 Nov 2013 13:38:46 -0500
Message-ID: <CAD5OKxujewjLgo5CH3=9L9dLKAGmBkfzz=jENqa1nR1SO1LR4g@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Justin Uberti <juberti@google.com>, Lorenzo Miniero <lorenzo@meetecho.com>, cowwoc <cowwoc@bbs.darktech.org>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, Nov 27, 2013 at 12:59 PM, Martin Thomson

> On 27 November 2013 09:39, Roman Shpount <roman@telurix.com> wrote:
> > So, all we need is one web site that distributes this extension and
> allows
> > cross site scripting (by using JSONP for instance) and this entire
> security
> > model is out of the window. To be honest, I do not see how installing
> > extension is any better then having an option in the browser menu that
> > enables screen sharing access.
> That site would have to allow other sites to access the data.  We're
> talking about making MediaStreamTracks transferrable between contexts
> using postMessage, which would absolutely allow this restriction to be
> bypassed.
> The same way that you could get a permanent grant for gUM on audio and
> video and then hand it out willy-nilly to others.
> That sort of behaviour is exactly the sort of behaviour that Justin
> talks about when he refers to the ability to remotely disable
> extensions.  It's why that feature exists.

I believe a well designed user consent is required for screen sharing.
Anything else is circumventable.

If JSONP is supported anywhere on the domain that has a screen sharing
plug-in enabled, an attacker should be able to load an entire JavaScript
app in the context of that domain. This application can start screen
capture and send media to the attacker's server. Since extension publisher
can update the web site at any time and introduce ways to run such
exploits, web browser manufacturers will need to monitor all the web
content published on all the sites that are allowed in screen sharing
plug-ins. Since this screen sharing attack can be used against any web site
(and unlikely to be used against the plug-in publisher), it is unlikely
plug-in publisher will have any incentives to monitor their site for such
attack vectors.

So, unless I am missing something, a Foo conferencing company publishes
screen sharing plug-in which is authorized for *.foo.com domain only. It
also provides an API used for integration of conferencing functionality via
api.foo.com. This API is commonly used to embed conferencing functionality
within other web sites and is JSONP enabled. This means other web sites
also get the ability to run screen sharing plugin authorized for
Roman Shpount
Received on Wednesday, 27 November 2013 18:39:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:52 UTC