Re: webRTC and Content Security Policy connect-src

On Mon, Jan 15, 2018 at 7:16 AM, Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> 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.
>

Hmm... you mean with *existing* CSP? That seems like it violates the
principle of least astonishment quite baly.

-Ekr




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> <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 hacks https://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 to ibc@aliax.net for starting the discussion and sergio.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.
>
>
>
>