Ben Dickson 22 décembre 2022 à 12:00 UTC
Mis à jour : 22 décembre 2022 à 12 h 03 UTC
La plate-forme de visioconférence corrige une vulnérabilité de script intersite
Zoom a corrigé un bogue de script intersite (XSS) qui fonctionnait à la fois dans les versions de bureau et Web de son application Whiteboard.
Zoom Whiteboard permet aux utilisateurs de collaborer en temps réel sur un canevas partagé en ajoutant et en modifiant différents objets. Le tableau blanc exécute du code JavaScript à la fois dans le navigateur et dans l’application de bureau.
Échapper à l’assainissement
Le bogue XSS dans Zoom Whiteboard était découverte par le chercheur en sécurité Eugene Lim (aussi connu sous le nom ‘raton laveur‘). Lim se concentre sur le chevauchement entre le Web, le mobile, le bureau et d’autres plates-formes, c’est ainsi qu’il s’est intéressé à enquêter sur Zoom Whiteboard.
Le tableau blanc prend en charge plusieurs types d’objets, notamment le texte, les formes, le texte enrichi, les images et les notes autocollantes.
Pour stocker et transférer des objets, il utilise Protocol Buffer (), une norme de balisage indépendante du langage et de la plate-forme pour la sérialisation des données structurées. Il utilise WebSocket pour diffuser des objets sur tous les clients et fournir des mises à jour en temps réel sur le tableau blanc.
En savoir plus sur les dernières nouvelles sur les vulnérabilités de sécurité Web
Une fois reçu, le client transforme l’objet en son composant React correspondant et l’insère dans l’interface utilisateur.
React nettoie automatiquement tous les attributs HTML contenus dans les objets du tableau blanc. Cependant, quelques-uns des objets autorisent certaines balises HTML. Pour certains objets, les développeurs ont utilisé des fonctions regex personnalisées pour nettoyer les entrées de l’utilisateur et supprimer les balises non autorisées.
Lim a découvert qu’avec une chaîne HTML bien conçue, il pouvait contourner le contrôle de nettoyage et envoyer du code JavaScript arbitraire à tous les autres clients et organiser une attaque XSS.
Armer le presse-papiers
Exploiter le bogue nécessiterait un effort compliqué de la part de l’attaquant.
“Les messages WebSocket sont envoyés au format. Cela rend difficile la rédaction d’une preuve de concept facile à reproduire pour les trieurs, car ils doivent intercepter la demande WebSocket et modifier correctement le message avant que la demande ne soit abandonnée », a déclaré Lim. La gorgée quotidienne.
Pour surmonter ce défi, il a développé un script de preuve de concept de bout en bout qui utilisait le presse-papiers pour créer et livrer la charge utile XSS.
Les enjeux des applications hybrides
Lim pense qu’il y a deux facteurs qui rendent difficile la recherche et la correction de tels bogues. Le premier est l’étendue et la profondeur des API Web JavaScript qui prennent en charge des fonctionnalités supplémentaires.
“De WebRTC (appel vidéo) à WebGL (graphiques 2D/3D), il y a beaucoup plus que vous pouvez faire dans un navigateur de nos jours que simplement afficher une alerte. Cela augmente la surface d’attaque et le potentiel de contournements », a-t-il déclaré.
Et deuxièmement, le chevauchement croissant entre les applications Web et natives/de bureau.
“Les développeurs doivent sécuriser leurs applications sur plusieurs plates-formes, ce qui augmente la complexité, car JavaScript dans React sur Safari peut fonctionner légèrement différemment de React Native avec Hermes sur Android”, a déclaré Lim.
Vérifiez vos dépendances tierces
Enfin, Lim a mis en garde contre les failles des dépendances tierces.
“Les outils d’analyse de code n’ont pas détecté le véritable [Zoom] vulnérabilité parce que l’entrée de l’utilisateur passait par une dépendance tierce », a-t-il déclaré.
En règle générale, les analyses de code dans les pipelines CI/CD n’installent pas de dépendances tierces et s’exécutent uniquement sur le code source du projet.
“Le point à retenir ici est d’être très conscient des composants tiers que vous utilisez et de la façon dont vous les utilisez”, a déclaré Lim. “De plus, les regex sont très difficiles à faire soi-même, il peut donc être préférable de s’appuyer sur des bibliothèques comme DOMPurify.”
A NE PAS MANQUER Comment devenir un testeur d’intrusion : 2e partie – « Monsieur le piratage » John Jackson sur la vertu de la « curiosité sans fin »
