Cross-site scripting : sécuriser les gestionnaires de favoris
Imaginez que vous travaillez depuis chez vous et que vous devez accéder à quelque chose sur le réseau de votre entreprise. Vous ouvrez la même page VPN que d’habitude, vous vous connectez comme toujours et vous poursuivez votre travail. L’adresse du site appartient à votre entreprise et la page fait partie du système que votre employeur vous a demandé d’utiliser. Rien ne vous donne de raison évidente de vous demander ce qui se passe en arrière-plan.
GlobalProtect, de Palo Alto Networks, est un produit couramment utilisé par les entreprises pour fournir un accès VPN à leurs réseaux privés depuis n’importe où. Beaucoup de personnes connaissent les VPN comme des outils utilisés à la maison, mais GlobalProtect est conçu pour les entreprises. Les employés se connectent par l’intermédiaire de leur entreprise et GlobalProtect utilise un portail en ligne pour configurer leur connexion au réseau de l’entreprise.
En 2025, des chercheurs ont publié une faille de cross-site scripting dans cette partie de GlobalProtect accessible depuis le navigateur. Pour exploiter cette faille contre quelqu’un, un attaquant devait d’abord construire un lien empoisonné vers le véritable site VPN. Ce lien pouvait transporter des informations contrôlées par l’attaquant en plus de l’adresse elle-même, en utilisant le même mécanisme général que les sites emploient normalement pour transmettre des termes de recherche, des identifiants ou d’autres valeurs d’une page à l’autre.
Ce lien empoisonné doit encore parvenir jusqu’à une personne. Un attaquant aurait généralement besoin de phishing ou d’une autre forme d’ingénierie sociale pour inciter l’utilisateur à cliquer : un e-mail qui semble provenir du travail (voir : usurpation d’adresse e-mail), un message affirmant qu’un réglage VPN doit être vérifié, une conversation avec un faux support ou tout autre prétexte crédible pour cliquer.
Lorsque la victime ouvre le lien, elle peut tout de même arriver sur le véritable site VPN de l’entreprise. GlobalProtect lit les informations transportées dans l’URL empoisonnée et les insère dans la page qu’il renvoie au navigateur. Ce comportement n’est pas inhabituel en soi : les sites web lisent constamment des valeurs présentes dans les liens pour décider quoi afficher.
Le problème vient de la manière dont cette valeur est insérée dans la page. Les informations contrôlées par l’attaquant devraient rester du simple texte, un identifiant à vérifier ou un réglage général, autrement dit rien de plus puissant que ce qui serait saisi dans un champ de formulaire. Mais si le site les insère de façon à ce que le navigateur les interprète comme du HTML, les caractères fournis par l’attaquant peuvent cesser d’être traités comme du texte et commencer à être traités comme des instructions qui modifient la page et peuvent faire exécuter du JavaScript. La partie empoisonnée est entrée par le lien, puis le site de confiance l’a accidentellement transformée de données en code.
Jira nous donne un autre exemple du même problème par un chemin différent. En 2021, Atlassian a publié une faille permettant à des données liées à un projet et contrôlées par un attaquant d’être enregistrées et laissées en place. Plus tard, lorsqu’un administrateur ouvrait la page Associated Projects concernée, le navigateur pouvait interpréter cette valeur stockée comme du contenu exécutable.
C’est ce qu’on appelle une XSS stockée : l’attaquant place d’abord le contenu malveillant, le site le conserve, puis quelqu’un d’autre le déclenche plus tard simplement en chargeant la page sur laquelle il apparaît.
Il existe d’autres formes de XSS, mais la liste est longue et la majorité des détails ne concernent réellement que les développeurs. Dans un monde parfait, les développeurs empêcheraient ces attaques dès le départ, mais des erreurs se produisent dans la réalité. Les utilisateurs doivent donc faire attention aux liens qu’ils ouvrent et au risque que représentent le phishing et l’ingénierie sociale.
Nous arrivons ainsi à l’idée fondamentale du cross-site scripting, généralement abrégé XSS. Des informations qui auraient dû rester de simples données deviennent du code exécutable dans un site web auquel les gens font confiance.
Les navigateurs essaient normalement de garder les sites web séparés les uns des autres. Une page d’un site ne devrait pas pouvoir lire directement des informations privées d’un autre site ni utiliser la session connectée de cet autre site. XSS contourne cette protection d’une autre manière : c’est le site vulnérable lui-même qui provoque l’exécution de code contrôlé par l’attaquant dans sa propre page.
Une fois que le navigateur exécute ce code comme faisant partie de la page de confiance, les conséquences deviennent très concrètes. Il peut parfois lire des informations déjà affichées, observer ou modifier des champs de formulaire, remplacer des boutons et des liens, envoyer des informations ailleurs et bien plus encore. Le navigateur peut joindre automatiquement la session connectée de l’utilisateur à ces requêtes, ce qui signifie que le code malveillant peut effectuer des actions avec le compte de l’utilisateur sans connaître son mot de passe.
Si la personne qui déclenche le code malveillant est connectée en tant qu’administrateur, le code peut parfois utiliser la même autorité. Selon ce que le site permet, cela peut vouloir dire changer le mot de passe du compte, créer une clé API ou un jeton d’accès, ou ajouter un autre administrateur. L’attaquant peut ne pas avoir besoin de connaître le mot de passe de l’administrateur, puisque le navigateur est déjà connecté et autorisé à effectuer ces actions.
Une attaque XSS ne s’arrête pas nécessairement au site web où elle a commencé. Le service compromis peut être connecté à d’autres systèmes ou contrôler des informations qui seront ensuite ouvertes ailleurs. Une XSS réussie peut donc devenir un tremplin pour une autre attaque.
Un gestionnaire de favoris est un exemple particulièrement intéressant, car son rôle consiste à stocker des liens et à les présenter plus tard aux utilisateurs. Du code malveillant ayant accès à un compte de favoris pourrait modifier des liens enregistrés, en ajouter de nouveaux, modifier des Collections partagées ou placer des URL spécialement construites pour viser des vulnérabilités dans d’autres services. Si ces liens sont synchronisés ou partagés avec d’autres personnes, l’attaquant peut même obtenir un nouveau mécanisme de diffusion. Le second site aurait toujours besoin de sa propre faiblesse pour qu’une autre XSS réussisse, mais compromettre le gestionnaire de favoris pourrait donner à l’attaquant un endroit de confiance depuis lequel préparer et distribuer ces attaques.
À ce stade, les gestionnaires de favoris deviennent un cas de sécurité intéressant en eux-mêmes. Leur rôle est justement d’accepter des liens fournis par des personnes, de les enregistrer, de les synchroniser, de les importer et parfois de les partager avec quelqu’un d’autre. Une fonction Collections va encore plus loin : un lien créé ou contrôlé par une personne peut finir devant le navigateur d’une autre.
Cela signifie que les liens ne peuvent pas toujours être traités comme de simples chaînes de texte sans importance. Un gestionnaire de favoris peut sembler être une application relativement simple à construire, mais dès qu’il accepte des liens contrôlés par les utilisateurs et les déplace entre des comptes, des imports ou des Collections partagées, le traitement des URL devient une véritable frontière de sécurité. Les petits gestionnaires et ceux qui viennent d’être créés doivent y réfléchir avec autant de sérieux que les plus grands.
Les favoris JavaScript rendent cette frontière particulièrement évidente. Les navigateurs les prennent en charge depuis longtemps. Au lieu d’enregistrer une destination ordinaire comme https://example.com, un bookmarklet enregistre du JavaScript et l’exécute lorsque la personne ouvre volontairement le favori. Ils peuvent être extrêmement utiles pour modifier une page, extraire des informations ou lancer une automatisation.
Le système de favoris intégré au navigateur a lui aussi déjà été exploité par le passé, mais généralement au moyen d’un mécanisme très différent, souvent lié à un logiciel malveillant. Dans ce cas, la menace vient d’un logiciel qui a déjà obtenu un accès au navigateur. Un gestionnaire de favoris web doit résoudre un autre problème, car du JavaScript ou des liens empoisonnés peuvent arriver par plusieurs chemins autrement légitimes. Cela vient-il du propriétaire du compte ? Le contenu a-t-il été importé ? Vient-il d’une Collection partagée ? A-t-il été collé depuis un site non fiable ?
C’est un sujet auquel nous avons beaucoup réfléchi chez WebCull. Refuser tout simplement de prendre en charge les favoris JavaScript est une réponse de sécurité facile, et pendant longtemps c’était une décision tout à fait raisonnable. Mais les bookmarklets sont aussi réellement utiles. J’utilise de plus en plus WebCull dans mes propres flux de développement et d’automatisation, et de petits morceaux de JavaScript peuvent être un moyen extrêmement puissant de relier un favori à une action.
Au lieu de traiter les favoris JavaScript comme des liens ordinaires, WebCull les place donc derrière un système de sécurité distinct. Le JavaScript dans vos propres favoris est désactivé par défaut. Le JavaScript fourni par des Collections publiques dispose d’une autorisation entièrement séparée, elle aussi désactivée par défaut. Activer l’une n’active pas l’autre.
Lorsque l’une de ces autorisations est désactivée et que vous ouvrez volontairement un favori JavaScript, WebCull s’arrête et vous propose un choix. Vous pouvez annuler, utiliser Exécuter une fois sans laisser l’autorisation activée, ou autoriser explicitement cette catégorie de JavaScript pour de futures ouvertures volontaires. Si vous activez l’autorisation, les favoris suivants de cette même catégorie de confiance pourront s’exécuter lorsque vous les ouvrirez volontairement sans nouvel avertissement. L’activation est donc une vraie décision de sécurité, pas une préférence cosmétique.
Les favoris JavaScript ne sont jamais autorisés à s’ouvrir automatiquement, même après l’activation de l’autorisation correspondante. Dans l’application web WebCull, un bookmarklet autorisé s’exécute dans la page WebCull actuelle. C’est précisément pourquoi nous considérons cette fonction comme puissante et marquons ces contrôles Moins sécurisé.
La frontière des Collections publiques est encore plus importante parce que le code peut avoir été fourni par quelqu’un d’autre, et qu’un propriétaire ou collaborateur de la Collection peut modifier plus tard ce qui y est enregistré. C’est pourquoi le JavaScript provenant des Collections publiques dispose de sa propre autorisation au lieu d’hériter de celle des favoris que vous contrôlez vous-même.
C’est également un bon point à examiner lorsque vous évaluez n’importe quel gestionnaire de favoris ou outil de collection de liens. Demandez ce qui se passe lorsqu’une personne enregistre un favori javascript:. Demandez si des liens partagés peuvent devenir du code exécutable, si du JavaScript peut s’ouvrir automatiquement et si le code fourni par quelqu’un d’autre est séparé de celui que vous avez enregistré vous-même. Un outil qui stocke des informations privées et accepte des liens contrôlés par des utilisateurs doit traiter ces frontières comme une partie de son modèle de sécurité, pas comme un cas marginal.
Pour les personnes qui utilisent le web, les liens empoisonnés restent l’avertissement le plus pratique à garder en tête. Ils sont volontairement construits pour exploiter une faiblesse dans un vrai site web et sont souvent diffusés par phishing ou par une autre forme d’ingénierie sociale conçue pour rendre le clic normal. Le danger n’est pas que les liens ordinaires soient intrinsèquement dangereux. Un lien malveillant peut pointer vers un vrai site tout en transportant des informations contrôlées par l’attaquant destinées à déclencher une faille. Si quelqu’un vous demande de coller ou d’exécuter du code, c’est un énorme signal d’alerte. Même cliquer sur des liens provenant d’une source non fiable est quelque chose qu’il vaut mieux éviter.
Si vous pensez avoir ouvert un lien empoisonné, ne vous fiez pas à l’apparence de la page. Une attaque XSS réussie peut être totalement invisible pendant que du code s’exécute en arrière-plan avec l’accès dont votre navigateur dispose déjà. Si vous avez des raisons de croire qu’un lien était malveillant, suivez les instructions de sécurité ou de récupération du compte du service concerné. Se déconnecter des sessions actives, examiner l’activité récente du compte et changer les identifiants qui ont pu être exposés sont des précautions raisonnables lorsqu’elles s’appliquent. Si le problème est réellement une faille XSS, seul l’opérateur du site peut corriger la vulnérabilité elle-même.
Les failles GlobalProtect et Jira mentionnées plus haut ont été divulguées publiquement. Leurs rapports publics n’ont pas documenté d’exploitation confirmée dans des attaques réelles ; elles servent donc d’exemples concrets de la façon dont ces attaques peuvent fonctionner, et non de récits d’incidents connus. La fiche de prévention du Cross Site Scripting d’OWASP fournit une référence technique beaucoup plus approfondie pour les personnes qui développent des sites web.
Si vous utilisez des favoris JavaScript dans WebCull, consultez la documentation sur les favoris JavaScript. Elle explique les autorisations séparées, l’option Exécuter une fois et les vérifications de confiance à effectuer avant d’en ouvrir un.