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

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