Re: webRTC and Content Security Policy connect-src

Thanks Tim for the nice summary!

I would also like to add that this was started by this article:

https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

In it, it exposes the high risk that exist nowadays due to extended 
usage of third-party code in web applications that is not possible to be 
verified that could lead "easily" to add malicious code to legitimate 
application. CSP in that context allows to protect the end user by 
restricting the origin/destinations that the script can interact with.  
That is, even if a malicious code is able to run in the browser, it will 
not be able to leak data out of the browser to server not controlled by 
the legitimate app.

WebRTC bypass completely the CSP rules and will make it trivial to 
gather/leak data from/to a malicious server. Note that this is not 
related to datachannels, as there could be a lot of imaginative ways of 
leak data using webrtc (DTMF, encoding data via webaudio, transforming a 
byte stream to an qr-like image and capture it via canvas, or even using 
the turn request send and receive small amounts of data without even 
needing the PC to be established).

There is already an issue in CSP covering it:
https://github.com/w3c/webappsec-csp/issues/92

And I opened one to reference it in webrtc:
https://github.com/w3c/webrtc-pc/issues/1727

Best regards
Sergio


On 12/01/2018 12:01, T H Panton 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.

Received on Friday, 12 January 2018 11:35:22 UTC