W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2014

CSP for WebRTC

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 28 Aug 2014 16:29:13 -0700
Message-ID: <CABkgnnXpo8G5YM7itUK7Y1YxzpB_nmkjKyMWBwNEejo-_52vuA@mail.gmail.com>
To: public-webappsec@w3.org
A question arose in discussions in the media capture task force around
sites being able to forswear access to WebRTC functions.

That was in the context of user media (your camera and microphone),
but I've concluded based on discussions with the local experts that
this isn't really worthwhile doing.

WebRTC data channels however, are ripe for exploitation as an avenue
unguarded by 'connect-src'.

Unlike other sources of script-accessible data, peer-to-peer data is
not associated with an origin, so I think that the only thing to do is
to clump all WebRTC data into a single group and identify that group
with a keyword source.

It seems like existing connect-src directives would naturally exclude
this new label, unless host-source includes "*", and that's a fairly
desirable outcome.

WebRTC media features are probably not worthwhile to cover.  Although
- theoretically - media can alter processing for an origin (for
example, through the use of WebAudio or processing video using canvas
snapshots), any exposure here would require a fairly complicated set
of prerequisites to exploit.  For example, a site performing speech
recognition might be vulnerable, but then that vulnerability should be
quite obvious.

Thus, I'd like to suggest a new keyword-source of 'webrtc-data',
governing the use of WebRTC data channels. That leaves the option to
block 'webrtc-media' in the future.  Alternatively, or in addition to
that, a single keyword 'webrtc' might cover both, should that be
desired.

--Martin
Received on Thursday, 28 August 2014 23:29:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:40 UTC