IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

268PARTAGES

13  0 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Lcf.vs
Membre éclairé 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.
8  0 
Avatar de BakaOnigiri
Membre averti https://www.developpez.com
Le 09/08/2021 à 14:55
Ce qui me dérange énormément c'est la manière dont Google se prend comme le dieu qui à droit de vie ou de mort sur l'html, sans même aller proposer les modifications au W3C. Que cette fonctionnalité date d'un autre age et puisse être considérée comme dangereuse, OK. Mais il serait bon de proposer une mise à jour des spécifications de la norme. En fait, Chrome ne respecte plus cette normal si ils cachent les popup de l'appel "alert", et c'est très grave.

Ces derniers temps Google ne cherche plus à convaincre, ils sont les rois et font ce qu'ils veulent. Ce n'est pas anodin, et devrait inquiéter au plus haut point.
6  0 
Avatar de Kulvar
Membre éclairé https://www.developpez.com
Le 09/08/2021 à 19:00
La chose intelligente serait de proposer une version modernisée.

La fonction retourne une promise. Le bouton annuler rejette la promise. Non bloquant pour le navigateur.
4  0 
Avatar de Bigb
Membre averti 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
2  0 
Avatar de 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
1  0 
Avatar de earhater
Membre éprouvé 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 ..
1  0 
Avatar de mzerbo
Membre habitué 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
1  0 
Avatar de levolutionniste
Membre régulier https://www.developpez.com
Le 07/04/2017 à 17:21
Google veut nous forcer la main mais j'espère bien qu'ils vont échouer. S'il y a une pétition contre, faites-la circuler svp.
1  0 
Avatar de 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.
0  0 
Avatar de Alvaten
Membre éprouvé 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.
0  0