En 1995, JavaScript a fait ses débuts sur la scène du développement Web, notamment avec ses méthodes :- alert() : qui permet d'afficher dans une boîte toute simple composée d'une fenêtre et d'un bouton OK le texte qu'on lui fournit en paramètre. Elle sert à avertir l’utilisateur ;
- confirm() : qui est similaire à la méthode alert(), mais propose en plus du bouton OK l’option « Annuler ». Elle sert à confronter l’utilisateur à un choix ;
- prompt() : qui fournit un moyen simple de récupérer une information provenant de l'utilisateur, on parle alors de boîte d'invite.
En 2017, les ingénieurs de Chromium ont noté que « bien qu'elles (les méthodes) correspondent au JavaScript de cette époque, leur API synchrone est problématique pour les navigateurs modernes. Étant donné que le moteur JavaScript doit être mis en pause jusqu'à ce qu'une réponse utilisateur soit obtenue, les dialogues JavaScript sont modaux. Et parce que les dialogues sont modaux, ils sont souvent (et malheureusement) utilisés pour nuire à nos utilisateurs ».
Les dialogues modaux enlèvent aux utilisateurs la possibilité d’interagir avec la page sans répondre au préalable à la boîte de dialogue. Il n’est même pas possible de fermer par exemple l’onglet sans avoir répondu à la boîte de dialogue.
Une propriété qui a par exemple été utilisée en 2013 pour piéger des utilisateurs dans une boucle infinie jusqu’à ce que de l’argent soit versé. Les attaquants se sont fait passer pour le « Cyber Department » du FBI, indiquant aux cibles que le navigateur du système a été saisi et enregistré et que l'utilisateur devra payer des frais de 300 $.
Pour que la demande paraisse plus légitime, l'avis affichait alors l’adresse IP de la victime ainsi que des informations comme sa ville et son État. Les cibles étaient invitées à payer en entrant les codes équivalents à une recharge de ce montant sur Green Dot MoneyPak (service de carte prépayée) dans le navigateur.
Si l’utilisateur essaye de fermer la fenêtre, un avis apparaîtra, prétendant que le navigateur est verrouillé, que les données seront détenues et des procédures criminelles seront engagées contre lui, sauf s’il paie. Néanmoins, si l’utilisateur s’obstine à cliquer sur OK, un autre avis va s’afficher, lui demandant s’il est sûr de vouloir quitter la page avec des options pour quitter ou rester sur la page. Si l’utilisateur clique sur quitter, l'avertissement initial apparaîtra à nouveau et le processus recommence.
Sur mobile, le phénomène est encore plus prononcé. L’année dernière, les chercheurs en sécurité de Malwarebytes ont indiqué avoir rencontré des pop-up indiquant que le dispositif Android d’un utilisateur était infecté. Une fois que l’utilisateur appuyait sur OK à la première boîte de dialogue, il était redirigé vers une page qui affichait une seconde boîte de dialogue lui indiquant qu’il s’agissait d’un Trojan et lui proposant de l’éliminer. En arrière-plan, les utilisateurs se faisaient voler des informations.
Les chercheurs ont précisé que les utilisateurs peuvent désactiver JavaScript. Cependant, cela va également désactiver les fonctionnalités dépendantes de JavaScript sur d’autres sites. Aussi, pour résoudre cet abus de JavaScript dans le navigateur, l'équipe Chromium de Google a publié une proposition visant à éradiquer les boîtes de dialogue JavaScript.
Les alternatives
L’équipe assure qu’il en existe plusieurs pour remplacer ces trois méthodes JavaScript qui lancent des boîtes de dialogue. Pour notifier à l'utilisateur des événements (par exemple, les sites de calendrier), l'API Notifications devrait être utilisée. Pour obtenir l'entrée de l'utilisateur, l'élément HTML <dialog> doit être utilisé. Pour les PoC XSS, la console.log de devtool (document.origin) peut être utilisée.
Ils ont ajouté « qu’en ce qui concerne onbeforeunload, il convient de noter que ce n'est déjà plus fiable. Comme l'indique Ilya Grigorik, « Vous ne pouvez pas compter sur les évènements pagehide, beforeunload et unload sur les plateformes mobiles ». Si vous devez enregistrer l'état, vous devez utiliser l'API Page Visibility ».
Google Chrome désactivera des fonctions telles que alert() et confirm() dans les frame d'origine croisée
Google Chrome désactivera des fonctions telles que alert() et confirm() dans les frame d'origine croisée. Comme il s'agit d'un changement profond, les développeurs sont encouragés à mettre à jour leurs applications et leurs outils de débogage avant la mise à jour. S'exprimant sur Twitter, Emily Stark de l'équipe Google Chrome explique :
« Si vous êtes un fan de alert(), vous avez peut-être entendu parler d'un changement qui a brièvement touché le canal Chrome Stable cette semaine (il a été temporairement désactivé pour le moment pendant que la casse est corrigée).
« Tout d'abord, si vous êtes concerné par ce changement, vous pouvez vous inscrire au "reverse origin trial", qui est une extension de quelques mois qui vous permet de vous désinscrire du changement. Une politique d'entreprise est également disponible. Nous espérons voir les développeurs passer à des boîtes de dialogue avec des contenus Web qui pourraient être fournies par des bibliothèques et pourraient utiliser async/wait pour une bonne ergonomie.
« Si c'est vraiment nécessaire, les frame pourraient à la place envoyer des messages à leurs fenêtres parents pour utiliser alert() en leur nom, car ce changement n'affecte que les frame intégrés d'origine croisée - mais ce n'est pas idéal car même les alert() de niveau supérieur ont des caractéristiques sous-optimales.
« Deuxièmement, si vous vous demandez pourquoi ce changement se produit, vous pouvez en savoir plus sur la liste de diffusion Chromium blink-dev@, mais la problématique est*que alert() et ses amis sont souvent utilisés pour l'usurpation d'identité et les escroqueries qui profitent du fait que la provenance du message est ambiguë. Il est très facile d'utiliser alert() pour faire croire à un utilisateur que son navigateur lui dit quelque chose alors qu'en fait le message provient d'un site Web malveillant.
« Ceci est exacerbé pour les boîtes de dialogue d'origine croisée où le navigateur ne peut même pas attribuer proprement le message à un site Web particulier ; de nombreux utilisateurs n'ont pas de modèles mentaux précis lorsqu'une origine est intégrée dans une autre ».
Membre de l'équipe d'ingénierie Chrome, Emily Stark explique entre autres que l'équipe désactive alert() pour protéger les utilisateurs contre les arnaques.
Certains se plaignent que cela a déjà affecté les didacticiels de programmation et les sites d'apprentissage Javascript qui mettent en sandbox le code fourni par l'utilisateur dans des frame d'origine croisée. Pour les personnes concernées par les modifications, Chrome conseille ce qui suit*:
- Obtenir une prolongation de quelques mois en s'inscrivant à «*reverse origin trial » afin de pouvoir temporairement désactiver le changement.
- Consulter la politique de l'entreprise.
Cette décision a suscité la polémique :
- Un ingénieur de Discord a critiqué le fait qu'un changement aussi important se produise sans discussion approfondie sur le sujet :
« Ignorant si l'alerte d'origine croisée doit être supprimée, le fait qu'un changement de rupture puisse toucher le canal stable d'un navigateur majeur sans communication approfondie au préalable montre que le processus est interrompu. Nous devrions être douloureusement conscients des changements en rupture bien avant qu'ils ne surviennent ». - Un autre utilisateur de Twitter a fait écho au sentiment de plusieurs lorsqu'il a affirmé que cette décision ne ferait que nuire à ceux qui ne peuvent pas facilement mettre à jour les sites tout en encourageant les attaquants à utiliser la fonctionnalité de pseudo-alerte.
Source : Emily Stark
Et vous ?
Êtes-vous concernés par ce changement ? Que pensez-vous de la décision de Google et des motivations évoquées ? Partagez-vous le point de vue des développeurs qui estiment qu'une discussion plus profonde était nécessaire avant une telle décision ?Voir aussi :
Google Chrome n'affichera plus les indicateurs de sites Web sécurisés alors que l'entreprise continue ses efforts pour obtenir un Web 100 % HTTPS Google Chrome 92 est livré avec une détection de phishing « jusqu'à 50 fois plus rapide », grâce à des améliorations apportées à sa technologie de traitement d'image Chrome 94 va ajouter le mode HTTPS-First et Google prévoit de remplacer l'icône de cadenas affichée lorsqu'un site se charge via HTTPS, l'éditeur estime qu'il prête à confusion 
