16 Security Considerations (セキュリティ考慮事項)
16 Security Considerations (セキュリティ考慮事項)
RTSP サーバーと HTTP サーバーの構文と用法の類似性のため, [H15] に概説されたセキュリティ考慮事項が適用される。特に次に注意すること:
認証機構: RTSP と HTTP は共通の認証方式を共有するため, 認証に関して同じ指針に従うべきである。クライアント認証の問題は [H15.1], 複数認証機構のサポートは [H15.2] を参照。
サーバーログ情報の悪用: RTSP と HTTP サーバーはおそらく類似のログ機構を持つため, ログの内容を保護しサーバーユーザーのプライバシーを守る点で同様に慎重であるべきである。サーバーログに関する HTTP サーバー推奨事項は [H15.3] を参照。
機微情報の転送: RTSP 経由で転送される情報が HTTP で通常転送される情報より機微度が低いという理由はない。したがって, データのプライバシーとユーザーのプライバシー保護に関するすべての注意は RTSP クライアント, サーバー, プロキシの実装者に適用される。詳細は [H15.4] を参照。
ファイル名とパス名に基づく攻撃: RTSP URL は不透明なハンドルでファイルシステムの意味を必ずしも持たないが, 多くの実装がリクエスト URL の一部をファイルシステム呼び出しに直接写像すると予想される。そのような場合, ファイルシステムは [H15.5] の注意 (パス要素中の ".." のチェックなど) に従うべきである (SHOULD)。
個人情報: RTSP クライアントはしばしば HTTP クライアントと同種の情報 (ユーザー名, 位置など) に接するため, 同様に扱うべきである。さらなる推奨は [H15.6] を参照。
Accept ヘッダーに関するプライバシー問題: RTSP にも HTTP と同じ "Accept" ヘッダーが多く存在するため, その使用に関する [H15.7] の注意に従うべきである。
DNS スプーフィング: RTSP セッションは HTTP セッションより一般的に接続時間が長いと想定されるため, RTSP クライアントの DNS 最適化は少ないかもしれない。それでも [H15.8] の推奨は, マッピングの単一回の使用を超えて DNS から IP へのマッピングに依存しようとする実装に依然として関連する。
Location ヘッダーとスプーフィング: 単一サーバーが互いを信頼しない複数組織をサポートする場合, 当該組織の管理下で生成されたレスポンスの Location と Content-Location ヘッダーの値を検査し, 権限のないリソースを無効化しようとしていないことを確認しなければならない。 ([H15.9])
現在の HTTP 仕様 (本書執筆時点で RFC 2068 [2]) の推奨に加え, 将来の HTTP 仕様がセキュリティ問題に関する追加の指針を提供しうる。
以下は RTSP 実装向けの追加考慮事項である。
集中型 DoS 攻撃: 本プロトコルは遠隔制御型拒否サービス攻撃の機会を提供する。攻撃者は SETUP リクエストで宛先として 1 つ以上の IP アドレスを指定しトラフィックフローを開始しうる。この場合攻撃者の IP アドレスが分かることもあるが, それが追加攻撃の防止や攻撃者特定に常に役立つわけではない。したがって RTSP サーバーは, サーバーがクライアントの身元を (RTSP 認証機構 (望ましくはダイジェスト認証以上) による既知ユーザーのデータベース照合など, 他の安全な手段で) 検証した場合にのみ, RTSP で開始されるトラフィックフローについてクライアント指定の宛先を許可すべきである (SHOULD)。
セッション・ハイジャック: トランスポート層接続と RTSP セッションに関係がないため, 悪意のあるクライアントがランダムなセッション識別子でリクエストを発行し, 注意していないクライアントに影響を与えうる。サーバーは大きくランダムで連番でないセッション識別子を用い, この種の攻撃の可能性を最小化すべきである (SHOULD)。
認証: サーバーは basic と digest [8] 認証の両方を実装すべきである (SHOULD)。制御メッセージにより厳格なセキュリティが必要な環境では, RTSP 制御ストリームを暗号化してよい。
ストリームの問題: RTSP はストリーム制御のみを提供する。ストリーム配送の問題は本節および本メモの他の部分では扱わない。RTSP 実装は RTP, IP マルチキャスト, RSVP, IGMP など他のプロトコルに依存することが多く, それらおよびその他適用仕様で提起されるセキュリティ考慮に対処すべきである。
持続的に疑わしい動作: RTSP サーバーは, セキュリティリスクと判断される行為を 1 回受信したらエラーコード 403 (Forbidden) を返すべきである (SHOULD)。またサーバーは弱点や侵入点を探る試みに注意し, ローカルセキュリティポリシーに違反すると判断されるクライアントについては任意に切断し以降のリクエストを無視してもよい (MAY)。