Safeguard
Application Security•

ASVS 5.0 V17.2.3: Verify SRTP Authentication at the Media Server

ASVS V17.2.3 requires the media server to check SRTP authentication so injected RTP packets cannot disrupt or alter streams. Test steps included.

Safeguard Security Team
3 min read

ASVS 5.0 V17.2.3 requires that SRTP authentication is checked at the media server, so RTP injection attacks cannot cause denial of service or insert audio or video into a stream. It is a Level 2 requirement.

SRTP adds an authentication tag to each packet. If the server does not verify the tag, anyone who can send UDP to the media port can slip packets into a call.

Why it matters

Plain RTP has no integrity. An attacker who learns a port and SSRC can send packets that play as noise, replace speech, or flood the decoder. The authentication tag and replay protection in SRTP exist to drop these packets before they reach the application.

How to implement it

Use a maintained SRTP implementation, such as libsrtp, and keep tag verification on. Drop packets whose tag fails, and apply replay protection with a sensible window. Never provide a debug flag that disables authentication in production builds. Accept media only from the address and port pair learned through the authenticated ICE exchange, and rate limit packets that fail verification so they cost little CPU.

How to test it

Set up a call, then send crafted RTP from a second host to the media port using a packet tool such as scapy or a custom UDP sender:

  1. Send plain RTP with a valid looking header and no tag. Expect drops.
  2. Send SRTP with a corrupted tag. Expect drops and a failure counter to rise.
  3. Replay a captured valid packet. Expect replay rejection.

Listen on the call to confirm nothing was inserted, and check server CPU stays flat.

Replay and ordering

SRTP packets carry sequence numbers and an index derived from a rollover counter. Replay protection keeps a sliding window of recently seen indexes and rejects duplicates. Use a window large enough for network reordering, but not so large that old packets are accepted. Libraries like libsrtp provide this, so enable it rather than building your own.

Count and alert. A steady stream of authentication failures from one address suggests someone is probing, and you may want to block that source at the firewall for a time. Keep the counters low cost, so an attacker cannot turn the monitoring into the denial of service.

Common mistakes

  • Using an SRTP profile with authentication disabled for debugging, then shipping it.
  • Counting failures but not dropping the packets.
  • Accepting media from any source address.

Quick check

Does encryption alone stop injection?

No. The authentication tag and replay check are what reject forged packets.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.