16 Security Considerations (Sicherheitsaspekte)
16 Security Considerations (Sicherheitsaspekte)
Wegen der Ähnlichkeit in Syntax und Verwendung zwischen RTSP- und HTTP-Servern gelten die in [H15] dargelegten Sicherheitsaspekte. Insbesondere beachten Sie:
Authentifizierungsmechanismen: RTSP und HTTP teilen sich gängige Authentifizierungsschemata und sollten daher dieselben Vorgaben zur Authentifizierung befolgen. Siehe [H15.1] für Fragen der Client-Authentifizierung und [H15.2] zur Unterstützung mehrerer Authentifizierungsmechanismen.
Missbrauch von Server-Protokolldaten: RTSP- und HTTP-Server werden vermutlich ähnliche Protokollierungsmechanismen haben und sollten die Protokollinhalte gleichermaßen schützen, um die Privatsphäre der Nutzer zu wahren. Siehe [H15.3] für HTTP-Empfehlungen zu Server-Protokollen.
Übertragung sensibler Informationen: Es gibt keinen Grund anzunehmen, dass über RTSP übertragene Informationen weniger sensibel sind als üblicherweise über HTTP. Daher gelten alle Vorsichtsmaßnahmen zum Schutz von Daten- und Nutzerprivatsphäre für Implementierer von RTSP-Clients, -Servern und -Proxies. Siehe [H15.4].
Angriffe auf Basis von Datei- und Pfadnamen: Obwohl RTSP-URIs undurchsichtige Handles ohne Dateisystemsemantik sind, wird erwartet, dass viele Implementierungen Teile der Anfrage-URIs direkt in Dateisystemaufrufe übersetzen. In solchen Fällen SOLLTEN Dateisysteme die in [H15.5] genannten Vorsichtsmaßnahmen befolgen, z. B. auf „..“ in Pfadkomponenten prüfen.
Personenbezogene Daten: RTSP-Clients haben oft Zugriff auf dieselben Informationen wie HTTP-Clients (Benutzername, Standort usw.) und sollten entsprechend behandelt werden. Siehe [H15.6].
Datenschutz und Accept-Header: Da viele dieselben „Accept“-Header in RTSP wie in HTTP existieren, sollten dieselben in [H15.7] genannten Vorbehalte beachtet werden.
DNS-Spoofing: Angesichts typisch längerer Verbindungszeiten bei RTSP im Vergleich zu HTTP dürften DNS-Optimierungen in RTSP-Clients seltener vorkommen. Dennoch bleiben die Empfehlungen in [H15.8] relevant für Implementierungen, die eine DNS-zu-IP-Zuordnung über eine einmalige Nutzung hinaus verwenden wollen.
Location-Header und Spoofing: Unterstützt ein Server mehrere einander misstrauende Organisationen, MUSS er die Werte von Location- und Content-Location-Headern in unter Kontrolle dieser Organisationen erzeugten Antworten prüfen, damit keine Ressourcen außerhalb ihrer Befugnis ungültig gemacht werden. ([H15.9])
Zusätzlich zu den Empfehlungen der aktuellen HTTP-Spezifikation (RFC 2068 [2] zum Zeitpunkt dieser Veröffentlichung) können künftige HTTP-Spezifikationen weitere Hinweise liefern.
Folgendes ergänzt die Überlegungen für RTSP-Implementierungen.
Konzentrierter Denial-of-Service-Angriff: Das Protokoll ermöglicht einen ferngesteuerten DoS-Angriff. Ein Angreifer kann Datenströme zu einer oder mehreren IP-Adressen lenken, indem er sie in SETUP-Anfragen als Ziel angibt. Die IP des Angreifers mag bekannt sein, was jedoch nicht immer zur Abwehr weiterer Angriffe oder zur Identifikation reicht. Ein RTSP-Server SOLLTE client-spezifizierte Ziele für RTSP-initiierte Ströme nur erlauben, wenn er die Client-Identität verifiziert hat, z. B. über RTSP-Authentifizierung (vorzugsweise Digest oder stärker) gegen eine Datenbank bekannter Nutzer oder andere sichere Mittel.
Session-Hijacking: Da Transportverbindung und RTSP-Sitzung nicht gekoppelt sind, kann ein bösartiger Client Anfragen mit zufälligen Sitzungskennungen senden und unbeteiligte Clients treffen. Der Server SOLLTE ein großes, zufälliges und nicht fortlaufendes Sitzungskennzeichen verwenden.
Authentifizierung: Server SOLLTEN Basic- und Digest-Authentifizierung [8] implementieren. Wo die Steuernachrichten stärker geschützt werden müssen, kann der RTSP-Steuerstrom verschlüsselt werden.
Stream-Fragen: RTSP bietet nur Stream-Steuerung. Stream-Lieferung wird hier und im übrigen Memo nicht behandelt. RTSP-Implementierungen stützen sich typischerweise auf RTP, IP-Multicast, RSVP, IGMP usw. und sollten die dortigen Sicherheitsaspekte berücksichtigen.
Anhaltend verdächtiges Verhalten: RTSP-Server SOLLTEN bei einem einzelnen als Sicherheitsrisiko eingestuften Verhalten den Fehlercode 403 (Forbidden) zurückgeben. Sie SOLLTEN auch auf Sondierungen nach Schwachstellen achten und DÜRFEN Clients, die gegen lokale Sicherheitsrichtlinien verstoßen, trennen und ignorieren.