Re: webRTC and Content Security Policy connect-src

Well, I don't agree with how that statement is written (although I think 
we share the same idea)

WebRTC must be *disabled* by default if CSP is in place. Wether it is a 
simple rule or multiple complex rules to *enable* it back, won't affect 
normal web developers.

Best regards
Sergio

On 15/01/2018 15:19, Byron Campen wrote:
>     Agreed. All of this hullabaloo started with the publication of 
> this article 
> <https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5>, 
> one of the central points of which was "CSP won't stop me, because CSP 
> is frequently misconfigured". Let's make it as easy as possible for 
> web developers to avoid this problem, and refine things later as needed.
>
> On 1/14/18 9:33 PM, Martin Thomson wrote:
>> A simple rule prohibiting
>> webrtc entire seems more operationally feasible.
>>
>>
>> On Fri, Jan 12, 2018 at 10:01 PM, T H Panton<thp@westhawk.co.uk>  wrote:
>>> In the call yesterday, I said I'd try and summarize the concerns that have been raised about 'Drive-by webRTC CSP' attacks.
>>>
>>> Content Security Policy on web pages allows a site developer to proscribe what their page can do.
>>> This is intended to mitigate the risks of XSS and other injection attacks.
>>>
>>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/connect-src
>>>
>>> This reduces exposure to included 3rd party scripts being tampered with at source
>>> e.g. if someone hackshttps://webrtc.github.io/adapter/adapter-latest.js
>>>   - the page may not function correctly, but it should not be able to send sensitive
>>> data to domains that aren't whitelisted in the CSP connect-src header.
>>>
>>> This prevents a web-font supplier from capturing the credit card data from your
>>> e-commerce site shopping forms.
>>>
>>> The connect-src explicitly covers websockets. It does not mention DataChannels or webRTC.
>>>
>>> In principle you might not think that matters, since in order to set up a data-channel
>>> you need to perform an SDP exchange, and that SDP exchange would have to go through
>>> a whitelisted server.
>>>
>>> It turns out in the case of ice-lite the browser does not verify that the remote party has
>>> ever seen it's SDP - ICE responses do not require the requester's ufrag or pass.
>>> This means that the malicious javascript does not need to send an answer to a
>>> cooperating server.
>>>
>>> So it would be possible to bury static SDP for an ice-lite offer in malicious javascript.
>>> The offer would point to a malicious server that implemented ice-lite on a fixed port
>>> (for example) and accepted data channels without checking the DTLS fingerprint.
>>>
>>> The javascript would apply this to a peerconnection and drop the generated answer in the
>>> bit-bucket.
>>>
>>> The malicious javascript can now inspect the page DOM and send all the form values it
>>> finds over a datachannel to the malicious server. Despite the fact that the conscientious developer
>>> had configured connect-src to mitigate this risk.
>>>
>>> At the heart of this is that ice-lite breaks the conceptual linkage between the 5 tuple and the
>>> page origin.
>>>
>>> Proposal:
>>> a) Ban ice-lite on pages with any CSP set
>>> c) add a allow-ice-lite CSP
>>> b) add a CSP turn-servers whitelist (to prevent leakage via the credentials)
>>> c) test plain ICE to make sure it fails if the far side sends no valid requests.
>>> d) ensure that any new ICE api's don't make this mistake (worse)
>>>
>>> Thanks toibc@aliax.net  for starting the discussion andsergio.garcia.murillo@gmail.com  for pointing me at CSP connect-src:
>>> https://twitter.com/ibc_tw/status/949993145978245120
>>>
>>> P.S.
>>> As you will see in the twitter thread, this isn't specific to the datachannel - one can exfiltrate data over DTMF or G711 perfectly easily.
>>>
>>> Tim.
>
>