Request for Addition of WebRTC Security Subcategory in ASVS

[ImanSharaf]

I noticed that there is a dedicated subcategory for WebSocket security, but not for WebRTC (Web Real-Time Communication). Given the growing adoption of WebRTC in modern applications for audio, video, and data communication, I believe it is essential to address its security considerations within the ASVS.

I would like to propose the addition of a new subcategory specifically for WebRTC security. This subcategory could include items such as:

• Ensuring secure WebRTC signaling channels (e.g., TLS)
• Validating and sanitizing SDP (Session Description Protocol) exchanges
• Implementing secure WebRTC session termination
• Utilizing secure communication mechanisms for media and data streams such as DTLS-SRTP

I can write them in the ASVS style after we confirm what requirements we want to add.
Also, there are some good write-ups that we can extract valuable checks out of them such as this one ($3,500 was paid as bounty by Slack):

• Verify that the TURN server implements blacklist to block sensitive addresses from being specified as the XOR-PEER-ADDRESS in TURN messages

Inclusion of these items and potentially others would significantly benefit the community by raising awareness and providing guidance on securing WebRTC implementations.

[tghosth]

Can you suggest requirements that you think are not explicitly covered by existing requirements.

For example, I think we already have a requirement that all communications should be via TLS so I don't think we need extra requirements for that.

[tghosth]

hi @ImanSharaf any thoughts on this?

[ImanSharaf]

The specific check related to the TURN server and XOR-PEER-ADDRESS addresses a unique WebRTC-related concern that isn't necessarily covered by general security guidelines. SDP exchanges are unique to WebRTC and similar real-time communication protocols. Validating and sanitizing these exchanges are essential as they contain vital information about the media and data streams. They could be exploited if not secured properly. Unlike traditional communication channels, WebRTC sessions have unique characteristics, and ensuring their secure termination is essential to avoid unintended data leaks or unauthorized access.

[tghosth]

So can you suggest some specific requirements @ImanSharaf ?

[ImanSharaf]

Sure, do we want to create a subcategory for WebRTC similar to Websocket?

[elarlang]

How many requirements you have in mind? Web Socket category in my opinion contains duplicates which can easily handled with "parent" or more general requirement (but this is separate topic).

[tghosth]

Yeah let's see the WebRTC requirements first and then decide if we want a dedicated section or not.

[tghosth]

@ImanSharaf do you have suggested requirements for this?

[sandrogauci]

Hi there, as mentioned on X, we should be able to help on this very topic since it is one of our favorites 🙂.

Some references of past publications:

• Presentation at CommCon 2023: WebRTC & Video Delivery application security - what could possibly go wrong?. Slides are here
• A "podcast" episode and a similar, but earlier presentation for WebRTC Live #76: WebRTC Exposed! Vulnerabilities and Attacks; some other topics are covered here too
• Our blog posts on the topic and our newsletter which covers WebRTC security news

Also attaching the mindmap that we created to illustrate the WebRTC infrastructure attack surface as we see it.

We hope to convert some of this into ASVS styled requirements. Is this a good direction?

cc: @tghosth @ImanSharaf

[ImanSharaf]

@sandrogauci thank you. Please propose your suggested requirements.

[jmanico]

Here is a starting point forWebRTC from an expert system. WebRTC Security Requirements 1. **Authentication and Authorization:** - Verify that all peers are authenticated before establishing a connection. - Verify that only authorized users can initiate or join a WebRTC session. - Verify the use of secure tokens (e.g., JWT) to authorize WebRTC connections, ensuring tokens are short-lived and signed. 2. **Data Encryption:** - Verify that all WebRTC signaling data is transmitted over HTTPS (TLS). - Verify that all media streams (audio, video, and data channels) are encrypted using SRTP and DTLS. 3. **Signaling Security:** - Verify the use of strong authentication and integrity mechanisms for the signaling channel. - Verify that all signaling messages are validated for correctness and conform to expected formats. 4. **Data Integrity and Confidentiality:** - Verify the implementation of end-to-end encryption (E2EE) for WebRTC media streams where possible. - Verify the use of secure key exchange mechanisms (e.g., DTLS-SRTP) for negotiating encryption keys between peers. 5. **Privacy Protection:** - Verify that explicit user consent is obtained before accessing any media devices (e.g., camera, microphone) and users are notified when media streams are active. - Verify that the minimal set of permissions necessary for the application’s functionality is requested. 6. **Session Management:** - Verify that session initialization includes mutual authentication and integrity checks. - Verify the implementation of session timeout mechanisms to terminate idle WebRTC sessions. 7. **Logging and Monitoring:** - Verify that significant events such as session initiation, termination, and errors are logged securely. - Verify the monitoring of WebRTC sessions for anomalous behavior and appropriate action when anomalies are detected. 8. **Error Handling and Failover:** - Verify robust error handling to manage unexpected conditions during WebRTC sessions without leaking sensitive information. - Verify the provision of mechanisms for seamless failover in case of peer or network failure.

[tghosth]

Hi @sandrogauci,

This sounds really interesting.

A few comments:

• It would be good to make clear which requirements are relevant for someone implementing the WebRTC protocol themselves and which are relevant for someone utilizing someone else's implementation.
• Please try and focus on guidance which is WebRTC specific and doesn't duplicate.
• Where you have guidance that is more detailed, consider including high level guidance for ASVS and using the more detailed guidance to create an OWASP Cheat Sheet.

[sandrogauci]

hey @tghosth - I hope to start working on this tomorrow.

Your comments make total sense - most of our work has been for people implementing the WebRTC protocols themselves but most people will not be doing that and will use some existent SDK which uses some CPaaS. I'll give it further thought, but offhand, such recommendations would be specific to that SDK. Might be too specific for ASVS then? Not sure.

With regards to avoiding duplicates with other areas (e.g. Websocket) - definitely. WebRTC in fact doesn't rely on WS, but WS is one of the more common ways to do signalling.

Thanks for the tip on high level guidance vs more detailed guidance! Very useful, especially for an ASVS newbie like myself 🙂

[sandrogauci]

hi @tghosth - we went through our internal documents and came up with the following so far:

TURN server

• Verify that the TURN service allows access only to IP addresses that are not reserved for special purposes (e.g., internal networks, broadcast, loopback). Note that this applies to IPv4 and IPv6 addresses.
• Verify that the TURN service is not susceptible to resource exhaustion when legitimate users attempt to open a large number of ports on the TURN server.

Media

• Verify that the key for the DTLS certificate is private.
• Verify that the cipher suites for the DTLS exchange are considered strong.
• Verify that the media server is not susceptible to the DTLS ClientHello Race Condition vulnerability.
• Verify that the RTP injection attacks on new or existent media streams do not cause DoS or audio/video media insertion.
• Verify that the media server is able to handle a flood of SRTP packets from legitimate users.
• Verify that any audio and/or video recording mechanisms associated with the media server are able to handle a flood of SRTP packets from legitimate users.
• Verify that the media server is able to handle malformed SRTP packets.

Signalling

• Verify that the signalling server is able to handle signaling message flood attacks.
• Verify that the signalling server is able to handle malformed signaling messages.

---

Naturally there is more work to be done. Is this the right direction?

[sandrogauci]

Updating my comment as per @tghosth suggestion with some introductory text to make it clear to whom the WebRTC security requirements are especially relevant:

General introduction to WebRTC security requirements:

WebRTC (Web Real-Time Communication) has become a cornerstone technology for enabling real-time voice, video, and data communication in web applications. As the adoption of WebRTC grows across various sectors, it is imperative to ensure that security measures are integrated into these implementations. Here we aim to provide comprehensive security requirements tailored to the needs of different stakeholders involved in the WebRTC ecosystem.

The WebRTC market can be broadly categorized into three segments:

1. Product Developers: These are proprietary and open-source vendors that create and supply WebRTC products and solutions. Their focus is on developing robust and secure WebRTC technologies that can be used by others.

2. Communication Platforms as a Service (CPaaS): They offer APIs, SDKs, and the necessary infrastructure or platforms to enable WebRTC functionalities. CPaaS providers may use products from the first category or develop their own WebRTC software to offer these services.

3. Service Providers: These organizations leverage products from product developers or CPaaS providers, or develop their own WebRTC solutions. They create and implement applications for online conferencing, healthcare, e-learning, and other domains where real-time communication is crucial.

The security requirements outlined here are primarily focused on Product Developers, CPaaS and Service Providers who:

• Utilize open-source solutions to build their WebRTC applications.
• Use commercial WebRTC products as part of their infrastructure.
• Use internally developed WebRTC solutions or integrate various components into a cohesive service offering.

It is important to note that these security requirements do not apply to developers who exclusively use SDKs and APIs provided by CPaaS vendors. For such developers, the CPaaS providers are typically responsible for most of the underlying security concerns within their platforms, and a generic security standard like ASVS may not fully address their needs.

TURN server

TURN (Traversal Using Relays around NAT) servers play a crucial role in WebRTC applications by facilitating peer-to-peer connections in challenging network environments. However, they can also introduce security risks if not properly configured and secured. These requirements only apply to systems that host TURN servers as part of their WebRTC infrastructure.

Requirements:

• Verify that the TURN service allows access only to IP addresses that are not reserved for special purposes (e.g., internal networks, broadcast, loopback). Note that this applies to IPv4 and IPv6 addresses.
• Verify that the TURN service is not susceptible to resource exhaustion when legitimate users attempt to open a large number of ports on the TURN server.

Media handling

Media security is paramount in WebRTC applications, as it directly impacts the confidentiality, integrity and availability of audio and video communications. By addressing these security concerns, developers can safeguard the media streams in WebRTC applications, preventing eavesdropping, tampering, and denial-of-service attacks that could compromise user privacy and communication quality.

Requirements:

• Verify that the key for the DTLS certificate is private.
• Verify that the cipher suites for the DTLS exchange are considered strong.
• Verify that the media server is not susceptible to the DTLS ClientHello Race Condition vulnerability.
• Verify that the RTP injection attacks on new or existent media streams do not cause DoS or audio/video media insertion.
• Verify that the media server is able to handle a flood of SRTP packets from legitimate users.
• Verify that any audio and/or video recording mechanisms associated with the media server are able to handle a flood of SRTP packets from legitimate users.
• Verify that the media server is able to handle malformed SRTP packets.

Signalling

Signaling is a critical component of WebRTC applications, responsible for coordinating communication sessions between peers. The security of the signaling process is essential to prevent unauthorized access, eavesdropping, and service disruptions.

Requirements:

• Verify that the signalling server is able to handle signaling message flood attacks.
• Verify that the signalling server is able to handle malformed signaling messages.

[tghosth]

Hi @sandrogauci, this is looking really good :)

A few queries:

Verify that the key for the DTLS certificate is private.

This feels like a basic TLS thing, do you think it is necessary to mention it?

Verify that the cipher suites for the DTLS exchange are considered strong.

What is the action here? To configure the media server with strong cipher suites? Can you reword to focus on the action?

Verify that the RTP injection attacks on new or existent media streams do not cause DoS or audio/video media insertion.

Is there a specific mechanism we could mention which helps to prevent this?

Verify that the media server is able to handle a flood of SRTP packets from legitimate users.

Is there a specific mechanism we could mention which helps to prevent this?

Verify that any audio and/or video recording mechanisms associated with the media server are able to handle a flood of SRTP packets from legitimate users.

Could this be merged with the above?

Verify that the media server is able to handle malformed SRTP packets.

What would it use to handle these? Input validation?

Verify that the signalling server is able to handle signaling message flood attacks.
Verify that the signalling server is able to handle malformed signaling messages.

Again, it would be good to mention the basic mechanisms or techniques which would prevent these, e.g. input validation, rate limiting.

[sandrogauci]

Hi @tghosth thanks for the excellent feedback and the direction. I'll first answer your questions and then update my previous suggestions according to your feedback.

This feels like a basic TLS thing, do you think it is necessary to mention it?

it's indeed a valid question. While DTLS is essentially an extension of TLS for UDP, its application in WebRTC introduces unique security concerns that differ from traditional TLS:

• Signaling Dependency: DTLS in WebRTC only starts after signaling has exchanged necessary parameters.
• Certificate Interaction: Certificate checks in WebRTC DTLS require interaction between signaling and DTLS, similar to certificate pinning.
• ICE Requirement: Interactive Connectivity Establishment (ICE) is a prerequisite.
• Ephemeral Ports: DTLS in WebRTC often operates over ephemeral ports.
• Self-Signed Certificates: Many certificates in WebRTC DTLS are self-signed but are verified through fingerprints exchanged at the signaling level, which is acceptable in this context.
• Testing Complexity: Testing DTLS in WebRTC requires packet-level analysis and custom tools, unlike typical TLS tests.

For more some details, refer to the Introduction to WebRTC and DTLS for Security Professionals.

Also this is coming from having seen the following case: Slack DTLS uses a private key that is in the public domain, which may lead to SRTP stream hijack

Then:

Could this be merged with the above?

regarding your suggestion to merge the SRTP packet handling with recording mechanism checks:

• Separate Concerns: One check addresses handling resource-intensive codecs and general resource (e.g., CPU) abuse, while the other focuses on recording systems, which are often separate and can be toggled on and off.
• Recording System Focus: Keeping them separate ensures dedicated attention to recording systems, which might be overlooked otherwise.
• Recording Impact: Recording systems can generate overly large files when attacked, necessitating distinct security considerations.

Given the above, do you think we should keep them separate or merge them?

---

I have updated the previous notes/suggested requirements and tried to have a course of action in each of them as you suggested. Is this what you had in mind?

TURN server

• Verify that the TURN service allows access only to IP addresses that are not reserved for special purposes (e.g., internal networks, broadcast, loopback). Note that this applies to IPv4 and IPv6 addresses.
• Verify that the TURN service is not susceptible to resource exhaustion when legitimate users attempt to open a large number of ports on the TURN server.

Media handling

• Verify that the key for the DTLS certificate is private by ensuring it is not reused in existing products or open-source projects and confirming it is not distributed or leaked.
• Configure the media server to use and support strong cipher suites for the DTLS exchange, ensuring that the selected cipher suites are considered strong and secure.
• Verify that the media server is not susceptible to the DTLS ClientHello Race Condition vulnerability by checking if the media server is publicly known to be vulnerable or by performing the race condition test.
• Verify that SRTP authentication is checked at the media server to prevent RTP injection attacks from causing DoS or audio/video media insertion on new or existing media streams.
• Verify that the media server can handle a flood of SRTP packets from legitimate users by implementing rate limiting, validating timestamps, using synchronized clocks to match real-time intervals, and managing buffers to prevent overflow and maintain proper timing. If packets for a particular media session arrive too quickly, excess packets should be dropped.
• Verify that any audio and/or video recording mechanisms associated with the media server are able to handle a flood of SRTP packets from legitimate users by implementing rate limiting, validating timestamps, using synchronized clocks to match real-time intervals, and managing buffers to prevent overflow and maintain proper timing. If packets for a particular media session arrive too quickly, excess packets should be dropped.
• Verify that the media server can handle malformed SRTP packets by implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques.

Signalling

• Verify that the signaling server can handle signaling message flood attacks by implementing rate limiting at the signaling level.
• Verify that the signalling server is able to handle malformed signaling messages by implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques.

[tghosth]

Ok so happy to keep the DTLS private key requirement with the additional explanation and to keep the SRTP packet handling requirements separate.

Do you want to PR your requirements into this file in this branch.

I will have some further tweaks but I'd rather do them as part of the PR review.

[sandrogauci]

Ok so happy to keep the DTLS private key requirement with the additional explanation and to keep the SRTP packet handling requirements separate.

Excellent, I'll include that in.

Do you want to PR your requirements into this file in this branch.

Will do that, probably towards the end of this week.

I will have some further tweaks but I'd rather do them as part of the PR review.

That is great - thanks for the help and assistance!

[sandrogauci]

@tghosth created a PR ☝️ Happy to discuss anything. I gave my reasoning for how I set up the levels per requirement in d3ae9fe, but discussion obviously welcome.

[tghosth]

Thanks @sandrogauci, I think the levels will all be finalised at the end anyway.

I made some tweaks and some comments here, please could you take a look :)
#2012

[tghosth]

This was merged in with #2008.

I will close this issue for now!

Thanks @sandrogauci!!!

[sandrogauci]

This was merged in with #2008.

I will close this issue for now!

Thanks @sandrogauci!!!

Many thanks to you too and anyone who contributed!

I have opened #2032 because there was a small mistake introduced in one of the last commits that slipped us.

[tghosth]

Oops, thanks