Un meilleur job mieux payé ?

Deviens chef de projet, développeur, ingénieur, informaticien

Mets à jour ton profil pro

ça m'intéresse

Chrome : les développeurs Web se servant de boîtes de dialogue JavaScript
Sont invités à se tourner vers des alternatives par sécurité

Le , par Stéphane le calme, Chroniqueur Actualités
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.

Les ingénieurs de Chromium notent 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 ».

Changements à venir

Les ingénieurs ont d’abord rappelé que la capacité d'une page à générer une chaîne de caractères onbeforeunload a été supprimée de Chrome 51.

Les méthodes de boîtes de dialogue JavaScript alert(), confirm() et prompt() sont en cours de changement : au lieu d’être modales, elles seront tout simplement rejetées lorsque leur onglet sera changé. Un comportement qui est déjà effectif sur les canaux Canary et Dev.

À cause de ces changements, les ingénieurs recommandent aux développeurs web qui se servent des boîtes de dialogue de se tourner vers les alternatives qu’ils proposent afin de ne pas être affectés.

Source : Chromium, Malwarebyte

Voir aussi :

Chrome 57 limite l'activité des onglets inactifs à 1 % par cœur de processeur, quel impact sur sa consommation en énergie électrique ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de grunk grunk - Modérateur https://www.developpez.com
le 31/03/2017 à 9:54
Sur mobile c'est un enfer ces pub qui pop une alert() qui ne fait que revenir et dont tu ne peut pas te débarrasser !

J'utilise pas mal le confirm() dans les backend avant par exemple de supprimer quelque chose. C'est une méthode rapide à mettre en place pour ajouter un niveau de confirmation quand on à pas besoin de truc joli.
A la limite qu'il rend ces boites de dialogue moins contraignante c'est pas plus mal , tant que le fonctionnement général ne disparaît pas.
Avatar de Lcf.vs Lcf.vs - Membre éprouvé https://www.developpez.com
le 31/03/2017 à 11:51
Marrant, tiens, que la solution de Google soit de les supprimer... alors que Firefox a réglé ce problème depuis des années.

Les boîtes de dialogue y font partie de l'onglet et n'empêchent donc de fermer ce dernier, de passer à un autre onglet, etc.

On a même une checkbox permettant de ne plus voir d'autres boites de dialogue.
Avatar de Alvaten Alvaten - Membre éclairé https://www.developpez.com
le 31/03/2017 à 12:39
Pour obtenir l'entrée de l'utilisateur, l'élément HTML <dialog> doit être utilisé
Le problème c'est que seul eux et opéra supportent ce tag à l'heure actuel.
Avatar de Bigb Bigb - Membre actif https://www.developpez.com
le 31/03/2017 à 13:35
Ce n'est pas au développeur de résoudre ce problème, mais bien aux navigateurs. Chacun ses problèmes
Avatar de TiranusKBX TiranusKBX - Expert confirmé https://www.developpez.com
le 31/03/2017 à 13:38
@Lcf.vs
Quand on cherche la solution de facilité ça donne ce genre de chose
Avatar de shadypierre shadypierre - Membre actif https://www.developpez.com
le 31/03/2017 à 14:03
Citation Envoyé par grunk Voir le message
J'utilise pas mal le confirm() dans les backend avant par exemple de supprimer quelque chose. C'est une méthode rapide à mettre en place pour ajouter un niveau de confirmation quand on à pas besoin de truc joli.
Rapide peut être mais il s'agit bien souvent d'une très mauvaise pratique lorsque la suppression qui s'en suit est une requête GET.
Avatar de earhater earhater - Membre confirmé https://www.developpez.com
le 31/03/2017 à 14:58
J'utilise pas mal le confirm() dans les backend avant par exemple de supprimer quelque chose. C'est une méthode rapide à mettre en place pour ajouter un niveau de confirmation quand on à pas besoin de truc joli.
Rapide peut être mais il s'agit bien souvent d'une très mauvaise pratique lorsque la suppression qui s'en suit est une requête GET.
ça change pas que tu peux faire un confirm de la soumission de formulaire pour du POST ..
Avatar de Lcf.vs Lcf.vs - Membre éprouvé https://www.developpez.com
le 31/03/2017 à 15:14
Citation Envoyé par earhater Voir le message
ça change pas que tu peux faire un confirm de la soumission de formulaire pour du POST ..
Bah, pour ça, autant directement faire un appel ajax en console, alors
Avatar de jpiotrowski jpiotrowski - Membre régulier https://www.developpez.com
le 06/04/2017 à 21:44
Autre solution radicale : CTRL+ALT+SUP et tuer le navigateur ?
Avatar de mzerbo mzerbo - Candidat au Club https://www.developpez.com
le 06/04/2017 à 21:58
Personnellement, je pensais que c'était plutôt au navigateur de gérer ce genre de problèmes car à mon avis, il serait beaucoup plus simple que l'on change la manière dont l’interpréteur gere un alert plutôt que de demander à tous les développeurs d'arrêter de les utiliser surtout si on prend en compte les milliers de sites les utilisant
Offres d'emploi IT
Développeur java / jee H/F
Capgemini - Ile de France - Suresnes (92150)
Data scientist senior H/F
Safran - Ile de France - Magny-les-Hameaux (Saclay)
Responsable transverse - engagement métiers H/F
Safran - Ile de France - Corbeil-Essonnes (91100)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil