WebRTC is changing the way we live by establishing new norms in communication. WebRTC makes this possible by supporting real-time browser-to-browser communication without additional plugins. It provides peer-to-peer (P2P) file sharing and streaming of P2P audio and video calls. And all these are done by incorporating real-time communication directly in the end user’s browser.
Also read: The Most Comprehensive Guide on WebRTC
Security measures implemented by WebRTC
So, now that this technology is selling like hotcakes, you might be tempted to dig into it. However, it would be advisable to first understand the risks and threats that come with it. The good news is that most of these risks could be mitigated, and this article helps you with it.
WebRTC communication comprises of two stages: Signaling stage and Communication stage. We need to consider the threats and security concerns related to all components involved, including the Server, client, and communication channel.
Let us first talk about the security measures implemented by WebRTC.
The server security measures are implemented using STUN (Session Traversal Utilities for NAT), which is used to get an external network address and IdP (Idenitity Provider). This ensures the identity of the authenticating party.
The client-side security mainly revolves around the access control permission from the user. Most browsers prompt the user for media device access and inform the user when it is in use.
The communication channel is the most critical and most protected part of WebRTC. Both the signaling plane (HTTP, SIP) and media plane (RTP) must be secured separately, which is a complicated task. This segregation between the signaling and media plane does not guarantee that the signaling user is the same as the media messaging user. Due to this, the WebRTC specifications enforce encryption of both the channels using DTLS-SRTP to ensure that the establishment of the media stream can take place without the need to reveal the SDP (Session Descriptor Protocol) in the message exchange.
To secure the communication channel from Man-in-the-Middle (MitM) attack where an attacker may be able to listen to communicating parties, a TLS certificate exchange is performed between the two parties. The TLS certificate is first sent via the signaling channel and then via the media channel and then compared for validity.
Read more: What is WebRTC And How It Works
Threats To WebRTC & How To Mitigate Them
Security – Client Server
Client: I have summed up the types of risks associated with the client-server at various levels below.
| Risk | Description | Possibility of attack | Mitigation | |
|---|---|---|---|---|
| General | Javascript Injection | An application is vulnerable to cross-site scripting (XSS), which allows a user to insert HTML and Javascript in the context of the application. | As WebRTC allows users to share information directly without an intermediary server, an attacker may
> extract password using phishing techniques > send malicious code embedded within a text message to the victim > capture conversation data. |
All the user supplied data must be validated against the HTML component it is displayed in. |
| Information disclosure during signaling phase on local client | Due to the nature of WebRTC, a browser must be able to access information such as internal IP address of the machine, which is used to establish a P2P connection without a server. | The attacker can acquire useful information about the victim and her network. | Configure the signaling server to send IP address only after both the parties have accepted communication with each other. | |
| Information disclosure during signaling phase on remote client | WebRTC requires the clients to access each other’s communication address which reveals information such as client’s internal IP address. | The attacker can obtain information about clients by acquiring their internal IP address and opening a communication channel with them. | This problem could be addressed by applying an application architecture in which a virtual client is the proxy to all of the communication which allows the attacker to view only virtual client’s IP address. | |
| Malware facilitation | When you share files on web applications, then security check on the file is performed at the Server. However, as WebRTC allows clients to communicate directly, one client can send malware to another directly | An attacker may send a malicious payload to be executed by the victim’s operating system. | Define a location where the file contents may be checked for viruses, and validated using digital signatures etc., prior to its delivery to the receiving client. This location could be on a server or on the receiving client. | |
| Registration and Termination | Registration without identity | A client may register with a WebRTC application without providing any identifying details. It is even possible for the attacker to bypass email-based or SMS-based verification. | An attacker can create multiple accounts for issuing WebRTC communication using the provided service. In such cases, the provider may not be able to comply with lawful interception requirements for telecommunication companies. | Associate the registration process with a credit card even if the service is provided free of charge. |
| Session not terminated | As a WebRTC application allows a client to be connected in several locations at the same time, appropriate session termination mechanisms must be implemented. | The attacker may reuse an active session in a previously used device, steal private information, and impersonate the client’s identity. | It is a good practice to integrate JavaScript code into WebRTC applications to terminate open conversations if the client is logged out or cannot communicate with Server. In case of telecommunication model where all conversations pass through a central server, it is important for the Server to notify the conversation proxy server of any logout request received. | |
| Android Client | Installation permissions | An attacker can create a malicious application that utilizes WebRTC to steal audio/video information. | The attacker may leverage this application to capture private information about the user. | Installing the android WebRTC application must prompt the user for specific privileges like INTERNET permission, RECORD_AUDIO, CAMERA permission. |
| Credential storage | A malicious application tries to capture the credentials of an existing/installed WebRTC-based application. | The attacker acquires credentials | To read the application data stored in the /data/data folder (default location), root privileges are required. Unless the developer strictly defined otherwise, access without root privileges requires leveraging a flaw in the Android OS. | |
| Network traffic tampering via browser plugins | When information is sent from WebRTC applications, the conversation is protected by DTLS-SRTP. However, a client’s credentials may be sent beforehand, using an unencrypted channel and allowing an attacker to reuse the session. | The attacker can install a browser plugin to steal WebRTC application credentials. | Browser plugins provide additional functionality to the browser, and they have elevated permissions to define, capture, and modify browser configuration— defining a proxy for the browser could be one of them | |
| Network traffic tampering via Android proxy | A malicious application can redirect traffic to an unwanted destination by creating a proxy. | The attacker can obtain sensitive information. | Proxies can be defined by a user, but root permissions are required for proxy configuration by an application | |
| Network traffic tampering via Android proxy via VPN | A malicious application can redirect traffic to an unwanted destination using a VPN proxy. | The attacker can obtain sensitive information. | The Android VPN is an alternative to establishing a proxy. The majority of applications that limit network traffic, as well as proxy applications such as Drony, Sendro, etc., utilize this functionality. |
After taking a long look at the possibility of security threats and possible solutions, I hope you have not forgotten to take care of the Server.
Security – Server
Server: Let us now take a look at the possible security threats at the Server side. As WebRTC is more about peer to peer and less about the Server, the list of threats is less exhausting than the client list above ?
| Risks | Possibility of attack | Mitigation |
| Signaling server takeover | An attacker who gains access to the signaling server can perform various actions such as: (1) crashing the system. (2) altering the data stream Recipient. (3) cloning the data stream by creating an “invisible” user participating in a conference conversation. (4) performing a MitM attack by creating a fake user. | Implement rigorous authentication. |
| Crashing the Server using malformed JSON | An attacker can send a malformed JSON to the Server as part of a legitimate request (i.e., a new field in the ICE candidate message). When the Server attempts to parse the JSON, it will result in an error and exit its main program loop rendering the Server unresponsive to new requests. | It is possible to avoid these kinds of attacks by rigorous input validation on the server side. |
| Registration hijacking in SIP | SIP (Session Initiation Protocol) is a communication signaling protocol heavily used in VoIP applications. In this protocol, a client may register itself to the Server, sending information such as the IP address. This information is sent in plain text, which can be captured by an attacker who can subsequently modify it so that all calls will be forwarded to the attacker. | Authentication, authentication and authentication! |
Security – Communication Channel
Communication channel: After having covered the other two major components viz. Client and Server, let us ensure the security of the communication channel.
| Risk | Description | Possibility of attak | Mitigation |
| Deducing information from encrypted communication | While WebRTC encrypts information by default, it may still be possible to obtain some insight regarding the type of conversation conducted between two participating users, and even extract other useful information, without tampering with the encryption. | The attacker may use sensitive data received in a social engineering attack. | In order to tamper inference from encrypted traffic the WebRTC application may obfuscate the data being sent. The simplest obfuscation method is padding and splitting all data chunks to create packets of the same size and send them with a constant frequency. Such solutions usually result in overutilization of network bandwidth and are not supported by existing WebRTC implementations. |
| Communication disruption/DoS attacks | Traditional enterprise firewalls often fail to manage WebRTC communication appropriately due to the segregation between the signaling and media channels in WebRTC. The UDP nature of WebRTC allows a possibility of IP spoofing. | If WebRTC firewall traversal is allowed, an attacker can send packets to a client, fooling the firewall into thinking that these packets are a legitimate part of the conversation. In case of outdated enterprise firewalls, this can end in a DoS attack. | Enterprise firewalls must be updated to support WebRTC communication. |
| Forceful use of a rogue Wi-Fi network by leveraging a server’s anti- DoS mechanism | The Server’sServer’s anti-DoS mechanism blocks IP of any legitimate Wi-Fi network that tries to perform a DoS attack on the WebRTC application. This safety feature can be exploited to force a victim to use a rogue Wi-Fi network instead of a legitimate one. | The attacker can get the IP of a legitimate Wi-Fi blocked as described and then create a rogue Wi-Fi network aimed at exploiting anyone that connects to it. Clients, being unable to connect to the WebRTC application due to the IP blocking, may decide to connect to the rogue network in order to use the WebRTC application. | Blocked IP lists must be cleared periodically |
WebRTC is rapidly changing the face of communication by replacing some of the traditional means of conducting audio/video calls, it has become especially important to telecommunication companies.
Hence, telecommunication companies are also forced to implement various security measures as the communications are channeled to and from telecommunication’s servers.
Summary : Risks Before you dive into WebRTC
This blog is especially helpful for you if you choose to go for the in-house development for embedding WebRTC in your applications. The idea is not to discourage you from going DIY but to help you make an informed decision. Alternatively, you could also engage a proven CPaaS provider, such as EnableX, who has the necessary securities in place.
