Une simple page web peut-elle compromettre ton navigateur ?

Pourquoi un clic n'est pas toujours nécessaire

Une page peut charger des scripts, images, polices et médias pendant une navigation ordinaire. Selon ses réglages et le contenu de la page, le navigateur peut exécuter des scripts utilisant des API graphiques ou multimédias et WebAssembly. L'analyse et le traitement de ces contenus offrent une voie possible vers une faille, même si tu n'as cliqué sur aucune pièce jointe ni accordé de nouvelle autorisation.

Pour réussir, une attaque a besoin d'une faille précise et d'un déclencheur qui l'atteint. Les cibles possibles comprennent le moteur JavaScript, le code de rendu et le traitement des médias. Le simple chargement d'une page ne donne aucun privilège système à son script. Une exploitation réussie peut en revanche transformer une faille en exécution de code dans le processus concerné, sous réserve de son cloisonnement et des autres contrôles.

Les navigateurs modernes séparent les sites et limitent les processus de rendu, comme l'explique ladocumentation de Chrome sur l'isolation des sites. Compromettre ce processus ne donne pas automatiquement accès à tout l'appareil ; il peut falloir une autre faille pour franchir le cloisonnement ou obtenir plus de droits. L'analyse de Google sur une campagne de 2024décrit une faille du moteur de rendu de Chrome enchaînée avec une sortie du cloisonnement. L'attaque visait des versions d'Android précises et non corrigées, pas tous les visiteurs.

Les composants que les attaques peuvent viser

Moteurs JavaScript. V8 et SpiderMonkey comprennent des compilateurs et une gestion complexe de la mémoire. Une faille peut permettre un comportement imprévu dans un processus du navigateur. Ce processus est normalement limité par le cloisonnement du navigateur : son code ne s'exécute pas avec des droits illimités sur le système d'exploitation.

Traitement graphique. WebGL et WebGPU rendent des fonctions graphiques accessibles par des API contrôlées par le navigateur. Des failles peuvent exister dans leur implémentation ou dans les pilotes, mais les programmes graphiques ne sont pas envoyés au matériel sans vérification. Une faille graphique ne prouve pas, à elle seule, une sortie du cloisonnement.

Traitement des médias et des images.Les navigateurs décodent des fichiers complexes provenant de pages qu'ils ne contrôlent pas. Une faille du décodeur peut être exploitable, mais ses conséquences dépendent du défaut et du processus concerné. Le cloisonnement du navigateur et du système peut en limiter l'effet. Un exemple pris dans une messagerie ne démontre pas l'existence d'une faille dans le navigateur.

WebAssembly et Web Workers. Ils permettent aux sites d'exécuter du code ou de travailler dans des contextes distincts, dans les limites fixées par le navigateur. Leur simple utilisation n'est pas une attaque. Une faille dans leur implémentation ou dans un composant associé peut néanmoins ouvrir une autre voie.

Comment un contenu piégé arrive jusqu'à toi

Le contenu contrôlé par l'attaquant doit encore parvenir au navigateur. MITRE cite notamment les publicités malveillantes, les sites compromis, les ressources tierces modifiées et les scripts ou cadres injectés. Leur fréquence varie selon la campagne ; aucun canal n'est dominant dans toutes les attaques de ce type.

Une publicité malveillante peut placer du contenu indésirable dans un emplacement publicitaire. Dans une attaque ciblant un groupe de visiteurs, l'attaquant compromet plutôt un site que ce groupe fréquente. Aucun des deux scénarios ne garantit que chaque visiteur sera touché : la page peut d'abord vérifier l'appareil et le navigateur, ou demander une autre action. Pour le cas publicitaire, lis notre guide sur les publicités malveillantes.

Dans un cas documenté en 2024, des sites gouvernementaux mongols compromis chargeaient un cadre caché contrôlé par l'attaquant. Le rapport de l'équipe Threat Analysis Group de Googledécrit des chaînes d'exploitation différentes, envoyées à certains visiteurs sous iOS et Android utilisant des versions vulnérables. Les failles avaient déjà été corrigées : les appareils visés n'avaient pas reçu ou appliqué les correctifs. Cet exemple montre qu'un site de confiance peut servir de vecteur, pas que chaque visite sur un site compromis aboutit à une infection.

Le délai entre correctif et installation

Un correctif publié ne protège pas un navigateur qui utilise encore une version vulnérable. Les délais varient selon l'éditeur, la plateforme, la prise en charge de l'appareil et la politique de mise à jour. Annoncer un nombre fixe d'heures ou de semaines serait trompeur. Le cas étudié par Google en 2024 montre que des failles déjà corrigées restaient exploitables sur certains appareils non mis à jour.

Un attaquant peut viser une faille connue après la mise à disposition d'un correctif : on parle parfois de faille « n-day ». Il peut aussi exploiter une faille avant l'existence d'un correctif, dite « zero-day ». Le temps nécessaire pour mettre au point une attaque et la durée d'exposition des utilisateurs varient beaucoup. En pratique, garde à jour ton navigateur et ton système, et vérifie si une mise à jour attend encore d'être appliquée.

Le téléchargement automatique aide, mais l'installation d'une mise à jour peut nécessiter un redémarrage. Leguide de mise à jour de Chromeexplique comment vérifier si une relance est en attente. Un appareil administré peut suivre la politique de déploiement de son organisation : vérifie la version en cours plutôt que de supposer qu'un correctif téléchargé est déjà actif.

Réduire l'exposition et contenir les dégâts

Des habitudes de navigation prudentes réduisent l'exposition, mais un site familier peut charger du contenu compromis. Garde le navigateur à jour, utilise ses protections intégrées et envisage de bloquer les scripts ou publicités indésirables quand c'est pertinent. Un antivirus ou une protection du poste peut détecter une charge malveillante ou un comportement suspect, sans garantie. Le cloisonnement du navigateur et l'isolation des sites ajoutent d'autres limites si quelque chose tourne mal.

Avec un navigateur distant comme Browser.lol, le code des pages s'exécute dans un conteneur, loin de ton navigateur local. Cela change le premier environnement qu'une attaque rencontre ; tu peux mettre fin à la session quand tu n'en as plus besoin. Cela ne prouve pas que ton appareil ou tes comptes sont en sécurité : fichiers téléchargés, identifiants saisis, presse-papiers, transferts de fichiers et infrastructure du service sont d'autres voies possibles. Maintiens à jour les navigateurs locaux et distants, et manipule les fichiers avec prudence. Pour distinguer les failles corrigées des failles inconnues, lis notre guide sur les failles zero-day.