16 Security Considerations (Considérations de sécurité)
16 Security Considerations (Considérations de sécurité)
En raison de la similarité de syntaxe et d'usage entre les serveurs RTSP et HTTP, les considérations de sécurité décrites dans [H15] s'appliquent. En particulier, veuillez noter ce qui suit :
Mécanismes d'authentification : RTSP et HTTP partagent des schémas d'authentification communs et doivent donc suivre les mêmes prescriptions en matière d'authentification. Voir [H15.1] pour l'authentification client, et [H15.2] pour la prise en charge de plusieurs mécanismes.
Abus des journaux serveur : Les serveurs RTSP et HTTP auront vraisemblablement des mécanismes de journalisation similaires et doivent donc protéger le contenu de ces journaux avec la même vigilance, préservant la vie privée des utilisateurs. Voir [H15.3] pour les recommandations HTTP sur les journaux.
Transfert d'informations sensibles : Rien n'indique que les informations transférées via RTSP soient moins sensibles que celles transmises habituellement via HTTP. Toutes les précautions concernant la confidentialité des données et des utilisateurs s'appliquent donc aux implémentations de clients, serveurs et proxies RTSP. Voir [H15.4].
Attaques fondées sur les noms de fichiers et de chemins : Bien que les URL RTSP soient des identifiants opaques sans sémantique de système de fichiers, on prévoit que de nombreuses implémentations traduiront des parties des URL directement en appels système. Dans ce cas, les systèmes de fichiers DEVRAIENT suivre les précautions de [H15.5], par ex. vérifier la présence de « .. » dans les composants de chemin.
Informations personnelles : Les clients RTSP ont souvent accès aux mêmes informations que les clients HTTP (nom d'utilisateur, localisation, etc.) et doivent être traités avec le même soin. Voir [H15.6].
Confidentialité et en-têtes Accept : Comme de nombreux en-têtes « Accept » sont communs à RTSP et HTTP, les mises en garde de [H15.7] sur leur usage doivent être suivies.
Falsification DNS : Compte tenu des durées de connexion généralement plus longues pour RTSP que pour HTTP, les optimisations DNS côté client RTSP devraient être moins fréquentes. Néanmoins, les recommandations de [H15.8] restent pertinentes pour toute implémentation cherchant à faire durer une correspondance DNS-IP au-delà d'une seule utilisation.
En-têtes Location et falsification : Si un serveur unique dessert plusieurs organisations qui ne se font pas confiance, il doit vérifier les valeurs des en-têtes Location et Content-Location dans les réponses générées sous le contrôle de ces organisations afin qu'elles ne tentent pas d'invalider des ressources hors de leur autorité. ([H15.9])
Outre les recommandations de la spécification HTTP en vigueur (RFC 2068 [2] à la rédaction du présent document), les spécifications HTTP futures pourront fournir des indications supplémentaires.
Voici des considérations supplémentaires pour les implémentations RTSP.
Attaque par déni de service concentrée : Le protocole permet une attaque par déni de service à distance. L'attaquant peut lancer des flux vers une ou plusieurs adresses IP en les indiquant comme destination dans des requêtes SETUP. L'adresse IP de l'attaquant peut être connue, ce qui ne suffit pas toujours à prévenir d'autres attaques ou à identifier l'auteur. Un serveur RTSP NE DEVRAIT autoriser des destinations imposées par le client pour les flux initiés via RTSP que s'il a vérifié l'identité du client, par ex. via les mécanismes d'authentification RTSP (de préférence digest ou plus fort) contre une base d'utilisateurs connus, ou par d'autres moyens sûrs.
Détournement de session : L'absence de lien entre connexion de transport et session RTSP permet à un client malveillant d'émettre des requêtes avec des identifiants de session aléatoires affectant des clients innocents. Le serveur DEVRAIT utiliser un identifiant de session long, aléatoire et non séquentiel pour limiter ce risque.
Authentification : Les serveurs DEVRAIENT implémenter l'authentification basic et digest [8]. Lorsqu'une sécurité renforcée des messages de contrôle est requise, le flux de contrôle RTSP peut être chiffré.
Problèmes de flux : RTSP ne couvre que le contrôle de flux. La livraison des flux n'est pas traitée ici ni ailleurs dans ce mémo. Les implémentations RTSP s'appuient souvent sur RTP, multidiffusion IP, RSVP, IGMP, etc., et doivent tenir compte des aspects de sécurité de ces spécifications.
Comportement durablement suspect : Les serveurs RTSP DEVRAIENT renvoyer le code d'erreur 403 (Forbidden) dès un comportement jugé risqué pour la sécurité. Ils DEVRAIENT aussi détecter les sondages visant à trouver des faiblesses et PEUVENT déconnecter et ignorer les clients jugés en infraction avec la politique de sécurité locale.