8. Security Considerations (Considérations de sécurité)

8. Security Considerations (Considérations de sécurité)

L'IETF a publié des documents séparés [RFC8827] [RFC8826] décrivant l'architecture de sécurité pour WebRTC dans son ensemble. Le reste de cette section décrit les considérations de sécurité pour ce document.

Bien que formellement l'interface JSEP soit une API, il est préférable de la considérer comme un protocole Internet, le JavaScript de l'application étant considéré comme non fiable du point de vue de l'implémentation JSEP. Ainsi, le modèle de menace de [RFC3552] s'applique. En particulier, JavaScript peut appeler l'API dans n'importe quel ordre et avec n'importe quelles entrées, y compris des entrées malveillantes. Ceci est particulièrement pertinent lorsque nous considérons le SDP qui est passé à setLocalDescription. Bien qu'une utilisation correcte de l'API exige que l'application transmette un SDP dérivé de createOffer ou createAnswer, rien ne garantit que les applications le fassent. L'implémentation JSEP DOIT être préparée à ce que JavaScript transmette des données erronées à la place.

Inversement, le programmeur d'application doit être conscient que le JavaScript n'a pas un contrôle complet du comportement du point de terminaison. Un cas qui mérite une mention particulière est que l'édition des candidats ICE hors du SDP ou la suppression des candidats en mode trickle n'a pas le comportement attendu: les implémentations effectueront toujours des vérifications à partir de ces candidats même s'ils ne sont pas envoyés à l'autre côté. Ainsi, par exemple, il n'est pas possible d'empêcher le pair distant d'apprendre votre adresse IP publique en supprimant les candidats réflexifs serveur. Les applications qui souhaitent dissimuler leur adresse IP publique DOIVENT plutôt configurer l'agent ICE pour utiliser uniquement des candidats relais.