Dans son application Whiteboard, Zoom a corrigé une faille XSS (cross-site scripting) qui affectait les versions desktop et web.

Zoom Whiteboard permet aux utilisateurs d'ajouter et de modifier divers objets tout en travaillant ensemble en temps réel sur un canevas partagé. L'application de bureau et le navigateur exécutent tous deux du code JavaScript dans Whiteboard.

Whiteboard prend en charge plusieurs types d'objets, notamment le texte, les formes, le texte enrichi, les images et les notes autocollantes.

Il utilise Protocol Buffer (protobuf), une norme de balisage neutre en termes de langage et de plate-forme pour la sérialisation des données structurées, pour stocker et transporter les objets. Il met à jour le tableau blanc en temps réel et diffuse les objets protobuf à tous les clients en utilisant WebSocket.

Lorsqu'un objet protobuf est reçu, le client le convertit en un composant React et l'insère dans l'interface utilisateur.

Les attributs HTML des objets du tableau blanc sont tous automatiquement nettoyés par React. Quelques-uns des objets autorisent toutefois certaines balises HTML. Les créateurs de certains produits ont nettoyé les entrées des utilisateurs et éliminé les balises interdites à l'aide de leurs propres routines regex personnalisées.

Eugene Lim, le chercheur qui a découvert la faille, a observé qu'il pouvait contourner la vérification de nettoyage, diffuser un code JavaScript arbitraire à tous les autres clients et lancer une attaque XSS avec une chaîne HTML bien préparée.

"Les messages WebSocket sont envoyés au format protobuf. Il est donc difficile d'écrire une preuve de concept facile à reproduire pour les triagers, car ils doivent intercepter la requête WebSocket et modifier correctement le message protobuf avant que la requête ne soit abandonnée", explique Lim

Il a donc créé un script de preuve de concept de bout en bout qui utilise le presse-papiers pour construire et envoyer la charge utile XSS afin de contourner ce problème.

Selon le chercheur, deux problèmes rendent difficile l'identification et la correction de ces failles. Premièrement, la profondeur et l'étendue des API Web JavaScript qui offrent davantage de fonctionnalités.

La deuxième raison est le chevauchement croissant entre les applications Web et les applications natives/de bureau.

La vulnérabilité réelle de [Zoom] n'a pas été détectée par les techniques de balayage de code, a-t-il affirmé, car l'entrée de l'utilisateur passait par une dépendance tierce.

"Il faut donc être très conscient des composants tiers que vous utilisez et de la manière dont vous les utilisez", a déclaré Lim. "De plus, les regex sont très délicats à réaliser soi-même, il peut donc être préférable de s'appuyer sur des bibliothèques comme DOMPurify."