V53: WebRTC
管理目標
Web リアルタイム通信 (Web Real-Time Communication, WebRTC) は Web アプリケーションでのリアルタイム音声、映像、データ通信を可能にする基礎技術となっています。WebRTC の採用がさまざまな分野に広がるにつれて、セキュリティ対策がこれらの実装に統合されているようにすることが不可欠です。ここでは WebRTC エコシステムに関わるさまざまな関係者のニーズに合わせた包括的なセキュリティ要件を提供することを目指しています。
WebRTC 市場は三つのセグメントに大別できます。
製品開発者: WebRTC 製品やソリューションを作成および提供するプロプライエタリおよびオープンソースのベンダーです。他者が使用できる堅牢で安全な WebRTC テクノロジの開発に重点を置いています。
サービスとしての通信プラットフォーム (Communication Platforms as a Service, CPaaS): WebRTC の機能を実現するために必要な API, SDK, インフラストラクチャやプラットフォームを提供します。CPaaS プロバイダは第一カテゴリの製品を使用するか、独自の WebRTC ソフトウェアを開発して、これらのサービスを提供できます。
サービスプロバイダ: これらの組織は製品開発者や CPaaS プロバイダの製品を活用したり、独自の WebRTC ソリューションを開発します。オンライン会議、ヘルスケア、e ラーニングなど、リアルタイム通信が重要な領域に対してアプリケーションを作成および実装します。
ここで説明するセキュリティ要件は主に以下のような製品開発者、CPaaS、サービスプロバイダを対象としています。
オープンソースソリューションを利用して WebRTC アプリケーションを構築する。
インフラストラクチャの一部として商用 WebRTC 製品を使用する。
内部で開発した WebRTC ソリューションを使用するか、さまざまなコンポーネントを統合して、まとまりのあるサービスを提供する。
これらのセキュリティ要件は CPaaS ベンダーが提供する SDK や API だけを使用する開発者には適用しない ことに注意することが重要です。そのような開発者としては、一般的に CPaaS プロバイダがプラットフォーム内の基本的なセキュリティの懸念のほとんどに責任があり、ASVS のような汎用的なセキュリティ標準では開発者のニーズに完全に対応できないかもしれません。
V53.1 TURN サーバ
Traversal Using Relays around NAT (TURN) サーバは厳しいネットワーク環境でのピアツーピア接続を容易にすることで WebRTC アプリケーションにおいて重要な役割を果たします。しかし、適切に構成および保護していない場合、セキュリティリスクをもたらす可能性もあります。
これらの要件は WebRTC インフラストラクチャの一部として TURN サーバをホストするシステムにのみ適用します。
53.1.1
[追加] Traversal Using Relays around NAT (TURN) サービスは特別な目的 (内部ネットワーク、ブロードキャスト、ループバックなど) のために予約されていない IP アドレスへのアクセスのみを許可している。これは IPv4 と IPv6 の両方のアドレスに適用することに注意する。
2
v5.0.be-53.1.1
53.1.2
[追加] 正規のユーザが TURN サーバ上で多数のポートを開こうとした際に、Traversal Using Relays around NAT (TURN) サービスはリソース枯渇の影響を受けない。
3
v5.0.be-53.1.2
V53.2 メディア
メディアセキュリティは音声および映像通信の機密性、完全性、可用性に直接影響するため、WebRTC アプリケーションにおいて最も重要です。これらのセキュリティ上の懸念に対処することで、開発者は WebRTC アプリケーションのメディアストリームを保護し、ユーザのプライバシーや通信品質を損なう可能性のある盗聴、改竄、サービス拒否攻撃を防ぐことができます。
これらの要件は、選択転送ユニット (Selective Forwarding Unit, SFU)、多地点制御ユニット (Multipoint Control Unit, MCU)、レコーディングサーバ、ゲートウェイサーバなど、独自の WebRTC メディアサーバをホストするシステムにのみ適用します。これらのサーバはアプリケーション内でメディアストリームの処理、ルーティング、操作、保存する責任を担っています。ピア間でメディアを管理および配信するため、これらのメディアサーバのセキュリティは非常に重要であり、セキュリティが不適切であると、メディアストリームへの認可されていないアクセス、傍受、操作につながる可能性があります。
特に、レート制限、タイムスタンプの検証、同期クロックを使用したリアルタイムインターバルの一致、オーバーフローを防いで適切なタイミングを維持するためのバッファ管理など、フラッド攻撃に対する保護を実装する必要があります。特定のメディアセッションのパケットがあまりにも速く到着する場合、過剰なパケットをドロップすべきです。入力バリデーションを実装し、整数オーバーフローを安全に処理し、バッファオーバーフローを防止し、その他の堅牢なエラー処理技法を採用することで、不正なパケットからシステムを保護することも重要です。
中間メディアサーバを介さずに、Web ブラウザ間のピアツーピアメディア通信のみに依存するシステムは、これらの特定のメディア関連セキュリティ要件から除外されます。ただし、そのようなシステムでも、通信の全体的なセキュリティを確保するために、本章で説明している他の要件に従うべきです。
53.2.1
[追加] データグラムトランスポート層セキュリティ (Datagram Transport Layer Security, DTLS) 証明書の鍵は非公開であり、既存の製品やオープンソースプロジェクトで再利用されておらず、配布や漏洩がないことを確認している。
2
v5.0.be-53.2.1
53.2.2
[追加] メディアサーバは、強力で安全な DTLS 暗号スイートと DTLS-SRTP 保護プロファイルを使用およびサポートするように構成されている。
2
v5.0.be-53.2.2
53.2.4
[追加] セキュアリアルタイムトランスポートプロトコル (Secure Real-time Transport Protocol, SRTP) 認証はメディアサーバで確認されており、リアルタイムトランスポートプロトコル (Real-time Transport Protocol, RTP) インジェクション攻撃によるサービス拒否状態や、メディアストリームへの音声または映像メディアの挿入を防止している。
2
v5.0.be-53.2.4
53.2.7
[追加] 不正な SRTP パケットに遭遇した場合でも、メディアサーバは受信メディアトラフィックの処理を継続できる。
2
v5.0.be-53.2.7
53.2.5
[追加] 正規のユーザからセキュアリアルタイムトランスポートプロトコル (Secure Real-time Transport Protocol, SRTP) パケットが大量送信されている間も、メディアサーバは受信メディアトラフィックの処理を継続できる。
3
v5.0.be-53.2.5
53.2.3
[追加] メディアサーバは "WebRTC DTLS ClientHello Race Condition" 脆弱性の影響を受けておらず、メディアサーバが脆弱性を持つことを公表しているかどうかを確認し、競合状態テストを実行している。
3
v5.0.be-53.2.3
53.2.6
[追加] 正規のユーザからセキュアリアルタイムトランスポートプロトコル (Secure Real-time Transport Protocol, SRTP) パケットが大量送信されている間も、メディアサーバに関連付けられた音声や映像のレコーディングメカニズムは受信メディアトラフィックの処理を継続できる。
3
v5.0.be-53.2.6
53.2.8
[追加] DTLS 証明書は SDP フィンガープリント属性と照合され、チェックに失敗した場合はメディアストリームを終了して、メディアストリームの真正性を確保している。
3
v5.0.be-53.2.8
V53.3 シグナリング
シグナリングは WebRTC アプリケーションの重要なコンポーネントであり、ピア間の通信セッションを調整する役割を担います。シグナリングプロセスのセキュリティは、認可されていないアクセス、盗聴、サービスの中断を防ぐために不可欠です。入力バリデーションを実装し、整数オーバーフローを安全に処理し、バッファオーバーフローを防止し、その他の堅牢なエラー処理技法を採用することで、システムを保護することが重要です。
これらの要件は、WebRTC インフラストラクチャの一部としてシグナリングサーバをホストするシステムにのみ適用します。
53.3.1
[追加] フラッド攻撃中でも、シグナリングサーバは受信シグナリングメッセージの処理を継続できる。これはシグナリングレベルでレート制限を実装することで実現できる。
2
v5.0.be-53.3.1
53.3.2
[追加] 不正なシグナリングメッセージに遭遇した場合でも、シグナリングサーバはシグナリングメッセージの処理を継続できる。
2
v5.0.be-53.3.2
参考情報
詳しくは以下の情報を参照してください。
WebRTC DTLS ClientHello DoS については セキュリティ専門家を対象とした Enable Security のブログ投稿 と、関連する WebRTC 開発者を対象としたホワイトペーパー に詳しく記載されています。
Last updated
Was this helpful?