Des scripts trompent les navigateurs pour récupérer des données, le Français AdThink nous répond

Des scripts trompent les navigateurs pour récupérer des données, le Français AdThink nous répond

Gestionnaire es-tu là ?

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

03/01/2018 9 minutes
64

Des scripts trompent les navigateurs pour récupérer des données, le Français AdThink nous répond

Des chercheurs de l’université de Princeton se sont penchés sur des scripts capables d’extraire des identifiants depuis les formulaires d’authentification à travers les gestionnaires de mots de passe intégrés aux navigateurs. L'une des entreprises concernées, Adthink, nous a répondu à ce sujet.

Gunes Acar, Steven Englehardt et Arvind Narayanan font partie du Center for Information Technology Policy de l’université de Princeton. Ils connaissent bien les attaques de type XSS (cross-site scripting), qui existent depuis plus d’une décennie. Mais au-delà des risques en matière de sécurité, le principe pose également un problème pour la vie privée quand il est exploité par certaines entreprises, notamment dans le domaine publicitaire.

Les chercheurs ont analysé en particulier deux scripts d'Adthink et OnAudience. Intégrés dans une page web, ils placent des formulaires invisibles d’authentification, destinés à faire réagir les gestionnaires de mots de passe natifs des navigateurs. De là, les scripts extraient l’identifiant, souvent une adresse email, et peuvent même (en théorie) récupérer les mots de passe.

À la clé un suivi très précis des habitudes de navigation à travers l'ensemble des sites utilisant le même script.

Fonctionnement du mécanisme

Le principe général se base sur les gestionnaires de mots de passe intégré aux navigateurs, pas ceux utilisés sous la forme d'une extension. Chrome, Edge, Firefox, Opera ou Safari possèdent cette fonctionnalité, que les utilisateurs affectionnent particulièrement. Et pour cause : elle évite d’avoir à se rappeler des mots de passe qui, idéalement, sont complexes à écrire et uniques à chaque service visité.

Adthink et OnAudience sont des scripts que les concepteurs de sites peuvent intégrer directement dans leurs pages. Ils ne sont alors pas considérés comme de tierces parties. Ils appellent un formulaire d’authentification associé au domaine principal, provoquant une action du gestionnaire intégré de mots de passe, qui remplit alors les champs proposés.

Dans leur page de démonstration, les chercheurs prouvent leurs dires : l'identifiant et le mot de passe peuvent être récupérés. Pour le second, seul Chrome réclame une action supplémentaire, sous la forme d'un simple clic n'importe où sur la page.

Les scripts créent une empreinte (hash) de l’identifiant, généralement un pseudo ou une adresse email. Or, dans ce dernier cas, l’internaute utilise très souvent la même et n'en change que très rarement. De fait, le hash d’une adresse devient une information fiable pour bâtir un profil de navigation. Ce dernier ne peut bien sûr se construire qu'à travers les sites utilisant les scripts d'un même acteur.

scripts navigateurs princeton

Le comportement des navigateurs

Tous les navigateurs considèrent les scripts comme des éléments intégraux des sites web visités, puisque le code est directement présent dans celui des pages. Les protections mises en place contre les éléments tiers ne fonctionnent donc pas.

Comme le soulignent les chercheurs, les navigateurs sont ici ballotés entre la sécurité et la facilité d'utilisation. Le consensus est de faire confiance aux éléments intégrés de premier niveau, et de faire plus attention aux contenus tiers appelés par les pages, notamment via des iframes. Certaines protections existent, mais elles dépendent des développeurs web, comme l’attribut HTTPOnly, bloquant l’accès des scripts aux cookies définis comme critiques pour la sécurité.

Cela étant, le comportement des navigateurs n’est pas le même sur le remplissage automatique. Chrome par exemple remplit l’identifiant, mais pas le mot de passe, à moins que l’utilisateur ne déclenche lui-même l’action. Firefox et les autres remplissent ce champ sans interaction. Ce qui donne une éventuelle piste de solution.

Les chercheurs insistent : le concept n’a rien de nouveau dans le fond, mais l’utilisation pour des scripts liés au profilage – et donc à la publicité – est plus récente. En tant que telle, elle pose un souci potentiel de sécurité, et très clairement de respect de la vie privée.

Adthink évoque un script expérimental

Adthink, l'une des deux entreprises abordées par les chercheurs, est justement française. Jonathan Métillon, directeur de l'innovation et de la communication, nous a ainsi expliqué que le script en question « était expérimental et est d'ailleurs déjà désactivé. Il avait été mis en place par des personnes qui ne travaillent plus chez nous ».

Le responsable nous affirme surtout que ce script ne comptait que « pour une infime fraction des données que l'on reçoit. Nous faisons surtout de la consolidation de profil sur la base des données que nos clients nous envoient spontanément ». Interrogé sur les catégories parfois très personnelles d'informations prises en charge (âge, taille, poids, adresse, identité sexuelle et autre), il nous indique que les scripts d'Adthink sont tout simplement « utilisés chez une grande variété de clients, dont des sites de rencontres ».

Jonathan Métillon insiste : « Nous n'avons pas de données personnelles. Nous ne possédons que des hashs d'adresses email, pas les adresses elles-mêmes ». La CNIL considère néanmoins tout identifiant unique, comme l'empreinte d'une adresse email, comme une donnée à caractère personnelle. Il confirme cependant que même si le script en question a été retiré et qu'il ne récupérait pas le mot de passe, « l'opération est tout à fait possible, et entre de mauvaises mains, ce genre de technique pourrait fait des dégâts ».

La finalité de ces profils se devine aisément : le ciblage publicitaire. Le directeur nous certifie que tout client utilisant ses scripts doit l'indiquer dans ses conditions d'utilisation et fournir un opt-out, en application des recommandations de la CNIL. Par ailleurs, Adthink travaille actuellement à se mettre en conformité avec les futurs RGPD et ePrivacy, qui doivent tous deux prendre effet en mai.

Des solutions immédiates et d'autres à venir

Mais même en comptant le retrait du script, le choix d'Adthink ne peut pas être généralisé à tous les acteurs. Comme l'indiquent les chercheurs, il ne s'agit que de deux scripts parmi d'autres. D'ailleurs, représentent-ils l’avenir du ciblage publicitaire ? Pas si sûr.

Pour contourner ce problème, le changement le plus « simple » à introduire pour les navigateurs serait de casser le remplissage automatique, par exemple en proposant une fonction qui nécessite un clic avant que les données ne soient affichées dans les champs correspondants. Du point de vue de l'utilisateur, la mesure passerait sans doute mal, tant les éditeurs cherchent à réduire les frictions, mais elle aurait le mérite d'être plus protectrice.

À plus longue échéance, l’API Credential Management en préparation au W3C pourrait elle aussi résoudre le souci, puisqu’elle adopte le même comportement que décrit précédemment : une action de l’utilisateur est requise. L’interface n’en est cependant qu’au statut de brouillon et il faudra encore que les navigateurs l’implémentent quand elle sera prête, ce qui aurait le mérite de rationaliser les usages.

Notez à ce sujet que la situation ne concerne bien que les gestionnaires de mots de passe intégrés et non les tiers, disponibles à travers des extensions comme 1Password (qui a d'ailleurs réagi dans les commentaires du compte-rendu des chercheurs pour le signaler), Dashlane ou Lastpass.

Ces produits enregistrent bien les identifiants, mais nécessitent tous une action de l’internaute pour remplir les champs du formulaire. Si vous êtes d’ailleurs utilisateur de l’une de ces solutions, une mesure à prendre peut être de couper le gestionnaire intégré au navigateur, tous proposant cette option.

Le fond du problème : un pistage toujours plus intense de l’utilisateur

Pour le chercheur Arvind Narayanan, le cœur du souci réside dans le choix des scripts opéré par certains sites : « Ces problèmes apparaissent en partie parce que les opérateurs de sites web ont été négligents en intégrant des scripts tiers sans en comprendre les implications ». Des entreprises ou développeurs se seraient donc fait séduire par des prestataires vantant les mérites de solutions promettant un profilage toujours plus poussé des visiteurs.

Même si tout porte à croire que le comportement de ces scripts n’est pas dangereux dans le sens « sécurité » du terme (du moins tant qu'ils se contentent de l'identifiant et ne récupèrent pas les mots de passe), ils ont un impact potentiel sur la vie privée. Le cas est à replacer dans un contexte plus global de réflexion sur la publicité et le ciblage précis des internautes qui l’accompagne, et la question du consentement.

Les actualités dans ce domaine sont particulièrement nombreuses depuis quelques mois, avec par exemple Mozilla, les approches différentes d'Apple et Google, ou encore nos propres choix en la matière. Trop nombreux sont encore les sites à se baser sur des méthodes ayant un point commun : elles cherchent à obtenir des données quitte à « tricher ».

On entend ici par tricherie la récupération d’informations que l’utilisateur n’aurait pas données de lui-même, ou pour lesquelles il n’a pas donné son accord. Le comportement de ces scripts n’est guère différent dans l’absolu de ceux abordés le mois dernier, qui permettaient pour rappel à des sites d’enregistrer toutes les frappes au clavier. Bien évidemment sans le consentement de l'internaute, et sans le prévenir.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Fonctionnement du mécanisme

Le comportement des navigateurs

Adthink évoque un script expérimental

Des solutions immédiates et d'autres à venir

Le fond du problème : un pistage toujours plus intense de l’utilisateur

Commentaires (64)


Et après on nous dira que les bloqueurs de pub/tracker c’est mal, ca tue le web gratuit…



N’empêche que ca protège des “gentils” scripts de récupération de données persos. <img data-src=" />


Le gros problème ici c’est firefox qui donne gentiment toutes les infos sans rien demander à l’utilisateur…


J’ai fait le test avec Chrome, uBLock Origin et Disconnect&nbsp; activés, et les deux n’ont pas empêché la récupération des identifiants et mot de passe.


Les mecs sont justes en train de scier toujours plus frénétiquement la branche sur laquelle ils sont assis…



A force d’intégrer toujours plus de putasseries de ce genre (formulaire cachés, mineurs BT, etc), au final, le marché de la pub en ligne va juste se concentrer autour d’Apple, Google et MS (qui possèdent leur propre navigateur et leur propre régie pub) et tout le reste va être bloqué par défaut.

Et là, tout le monde aura perdu…



Parce que les pires pratiques ne viennent pas forcément des GAFA quoiqu’on en dise mais bien des plus petites régies qui abusent clairement à tous les niveaux. Par contre, ce sont les GAFA qui concentrent le plus d’informations et quand elles seront les dernières dans le game, on sera définitivement baisés car on aura aucune échappatoire.


L’article précise bien que les scripts ne sont pas considéré comme des scripts tiers, donc pas comme des trackers, donc uBLock Origin et Disconnect ne voient rien. C’est encore plus inquiétant.


Dois-je en déduire que l’utilisation d’un logiciel type lastpass ou dashlane suffit à empêcher ceci? Puisqu’ils ne stockent pas les infos dans le navigateur…&nbsp;


Il est beau le web de nos jours …



Branchez une dynamo à la tombe de ses créateurs, vous aurez de l’énergie à l’infinie. <img data-src=" />



Bande de connards, pas d’autre réaction qui me vient en tête.








rivaldo32 a écrit :



Dois-je en déduire que l’utilisation d’un logiciel type lastpass ou dashlane suffit à empêcher ceci? Puisqu’ils ne stockent pas les infos dans le navigateur…







oui



Si le logiciel rempli automatiquement les champs le même souci est présent (un script en js peut lire le champ une fois qu’il est rempli) j’utilise Kaspersky Password Manager et il rempli les champs automatiquement d’ailleurs :/&nbsp;


En effet il remplit les champs automatiquement. Donc si le script récupère les infos dans les champs alors le stockage hors navigateur ne protège en rien…&nbsp;


Dans Firefox, about:config, il y a cette clé qu’on peut passer à false : signon.autofillForms

Pas encore testé si ça peut résoudre le problème par contre.


Dans la démo, le 3rd-party script est chargé depuis un site qui n’est pas blacklisté par uBLock. <img data-src=" />



“Jonathan Métillon, directeur de l’innovation et de la communication, nous a ainsi expliqué que le script en question « était

expérimental et est d’ailleurs déjà désactivé. Il avait été mis en

place par des personnes qui ne travaillent plus chez nous ».



Le responsable nous affirme surtout que ce script ne comptait que « pour

une infime fraction des données que l’on reçoit. Nous faisons surtout

de la consolidation de profil sur la base des données que nos clients

nous envoient spontanément »



&nbsp;

Traduction: “c’était juste pour voir, et puis on le fait plus, d’ailleurs on peut pas vraiment dire que c’était nous, c’était des anciens salariés, et puis c’était pas si grave”

<img data-src=" />


La seule solution c’est d’utiliser des Dashlane et autres keepass, bref des manager de mot de passe. Mais ce n’est pas la panacée non plus, je connais un site qui (parce qu’il est mal codé je pense) arrive a injecter le formulaire de login à chaque page, même logué, et arrive a faire réagir les gestionnaire de mot de passe et leur faire injecter les infos dans le formulaire.



Au vu de cette news je vais investiguer. Si vous voulez le site contactez moi par MP. Ce n’est pas un site de boule ou de pirate ou illégal, pas du tout. C’est un bête site marchand.


Plus qu’à désactiver l’autofill sur Kee, dommage c’était pratique :(


Je ne ne sais pas comment Youtube a gardé mes recherches d’hier ? (ce n’est pas normal)








Sputnik93 a écrit :



Traduction: “c’était juste pour voir, et puis on le fait plus, d’ailleurs on peut pas vraiment dire que c’était nous, c’était des anciens salariés, et puis c’était pas si grave”

<img data-src=" />







Traduction : “c’était juste pour voir mais comme le type qui l’a monté s’est barré, on a plus personne pour continuer l’expérimentation donc c’est en pause mais vous inquiétez pas, on va pas lâcher l’affaire. Au pire, on revendra l’idée à d’autres pires que nous…”



« […] directeur de l’innovation et de la communication, nous a ainsi expliqué que le script en question « était expérimental et est d’ailleurs déjà désactivé. Il avait été mis en place par des personnes qui ne travaillent plus chez nous ». » (article Next inpact)





  • en deux mots : méthodes agiles

  • en 2 explications : expérimentation avortée - les initiateurs de la mauvaise idée ne sont plus là



    &nbsp;Nous voilà rassurés <img data-src=" />


C’est faux, Firefox ne remplit plus le Champs ID et MDP depuis plusieurs versions dont la dernière








KP2 a écrit :



Traduction : “c’était juste pour voir mais comme le type qui l’a monté s’est barré, on a plus personne pour continuer l’expérimentation donc c’est en pause mais vous inquiétez pas, on va pas lâcher l’affaire. Au pire, on revendra l’idée à d’autres pires que nous…”





Traduction : “Bon, on s’est fait gauler, mais on met ça sur le dos d’un ex-employé inexistant. Mais vous inquiétez pas,&nbsp; on a bien l’intention de vous la mettre profond si vous baissez la garde, ou si personne ne gueule trop fort…”









silent screamer a écrit :



Traduction : “Bon, on s’est fait gauler, mais on met ça sur le dos d’un ex-employé inexistant. Mais vous inquiétez pas,  on a bien l’intention de vous la mettre profond si vous baissez la garde, ou si personne ne gueule trop fort…”







“…de toute façon, dans 1 mois, plus personne n’en parlera et on pourra continuer tranquille”









Eldok a écrit :



Dans Firefox, about:config, il y a cette clé qu’on peut passer à false : signon.autofillForms

Pas encore testé si ça peut résoudre le problème par contre.





Par défaut, cette clé est sur false. Étonnement, elle était forcée sur true chez moi.

Une fois la clé remis sur false, la page de démonstration n’arrive plus à sniffer l’Id et le mdp.



facebook traquait/traque les utilisateurs via son bouton de partage disséminé un peu partout sur l’internet. Même les utilisateurs n’ayant pas de compte.&nbsp;



Donc niveau putasserie ils se mettent bien. Google je t’en parle pas. Reste Apple et MS qu’ont le bénéfice du doute.&nbsp;








KP2 a écrit :



Les mecs sont justes en train de scier toujours plus frénétiquement la branche sur laquelle ils sont assis…



A force d’intégrer toujours plus de putasseries de ce genre (formulaire cachés, mineurs BT, etc), au final, le marché de la pub en ligne va juste se concentrer autour d’Apple, Google et MS (qui possèdent leur propre navigateur et leur propre régie pub) et tout le reste va être bloqué par défaut.





Pour pas changer.

Par rapport à d’autres, je me suis mis assez tard au blocages des pubs et trackers …

Vu les pratiques actuelles, je ne suis pas prêt de désactiver le brol …



Ceci étant, pour la pratique dont parle l’article : Je suis tranquille : Je n’utilise plus le gestionnaire du navigateur depuis un moment, keepass et je rempli manuellement (certes c’est plus long et moins pratique) et je suis tranquille (au moins pour ça).<img data-src=" />









1for-matik a écrit :



Par défaut, cette clé est sur false. Étonnement, elle était forcée sur true chez moi.





Elle est à “true” par défaut sur la dernière ESR de Firefox (version 52). Donc ça a du changer dans une version récente.

&nbsp;Et ce que tu dis semble indiquer que la valeur reste à “true” quand on a un profil qui date d’avant cette modif et qu’on met à jour <img data-src=" />



&nbsp;Ton profil Firefox date de quelle version, et tu es en quelle version ?



A voir si quelqu’un d’autre peut confirmer ou non.

&nbsp;



Une grosse amende, de la taule pour les responsables… À non ça va pas le faire désolé


L’adresse mail que j’utilise pour chaque compte est unique. A partir de là, même si ça fonctionnait ( je ne laisse pas le navigateur mémoriser ce que je frappe), ça ne servirait à rien pour me tracer.




Traduction: “c’était juste pour voir, et puis on le fait plus, d’ailleurs on peut pas vraiment dire que c’était nous, c’était des anciens salariés, et puis c’était pas si grave”





Si eux ne le font plus, d’autres le font toujours…



list of sites from Alexa top 1 million which embed scripts that abuse built-in password managers.








1for-matik a écrit :



Par défaut, cette clé est sur false. Étonnement, elle était forcée sur true chez moi.

Une fois la clé remis sur false, la page de démonstration n’arrive plus à sniffer l’Id et le mdp.







Thanks pour le tips !

<img data-src=" />







rg54 a écrit :



Et ce que tu dis semble indiquer que la valeur reste à “true” quand on a un profil qui date d’avant cette modif et qu’on met à jour <img data-src=" />

 Ton profil Firefox date de quelle version, et tu es en quelle version ?



A voir si quelqu’un d’autre peut confirmer ou non.







A mon avis, tu as la bonne explication. J’ai un profil assez ancien et j’étais à true aussi…

C’est dommage que Mozilla soit conservateur sur les paramètres de ce genre. Surtout quand la valeur est restée par défaut. Au pire, ils devraient quand même poser la question lors de la MAJ…





les opérateurs de sites web ont été négligents



Oups, j’ai ajouté un tracker malveillant par mégarde…

Peut-être qu’ils ne savaient pas ce qu’ils intégraient, mais de là à en être sûr…









superkoinkoin a écrit :



J’ai fait le test avec Chrome, uBLock Origin et Disconnect  activés, et les deux n’ont pas empêché la récupération des identifiants et mot de passe.





uBlock Origin permettait de bloquer une partie des scripts intégrés (script:contains(…)), malheureusement Mozilla n’a pas porté la fonction nécessaire dans les WebExtensions !



Attention, il y en a deux : une signon.autofillForms (sur True par défaut) et une signon.autofillForms.http (sur False par défaut).



Firefox 57.0.2 64bits.


Il est possible de bloquer le remplissage automatique des formulaires sur Opera. ;)&nbsp;


Idem sous Firefox.




«&nbsp;Ces problèmes apparaissent en partie parce que les opérateurs de

sites web ont été négligents en intégrant des scripts tiers sans en

comprendre les implications&nbsp;»





C’est pas faute de signaler ces dérives pourtant… Mais les décideurs veulent juste la même chose que le concurrent, qui lui ne s’embarasse pas avec ces questions ! Donc on développe n’importe quoi viteuf’, on ajoute des scripts en pagaille “parce que ça a l’air sympa”, et tant qu’on n’a pas touché le sol, “jusqu’ici tout va bien” <img data-src=" />


&nbsp;Idem ici. Dommage c’était pratique. Ensuite, la dernière version est plutôt bien fichue, elle affiche un petit icône pour saisir le login et le mdp dans le formulaire, mais bon ça fait toujours 2 clics de plus. <img data-src=" />



En tout cas, merci NI pour l’info. <img data-src=" />


Pour désactiver le remplissage automatique dans Firefox :





  • dans la barre d’adresse écrire about:config

  • rechercher : signon.autofillForms

  • mettre la valeur à False.




A ce niveau là, ce n’est plus de la triche ou du ciblage, mais limite de l’espionnage, voire du vol d’information à caractères personnelles… Jusqu’où va-t-on permettre le cible pour raison publicitaire ? Surtout que tout cela se fait à l’insu de l’utilisateur: qui peut dire ce qui se passe vraiment sur une page web sans aller voir le code source et y étudier les trop nombreux fichiers js ?


Le mode de navigation privée n’a pas l’effet, mais il n’en reste pas moins que les identifiants sont enregistrés quel que soit le mode de navigation ! Il suffit donc d’une fois, et about:config s’impose. Merci à NXI pour ces news tout aussi INformatives qu’ahurissantes techniquement. <img data-src=" />


Ouai, en gros ça rend encore plus dangereux le XSS. J’fais bien de pas enregistrer ma CB je me dis, avec le temps…


Suite à cette faille, je me suis posé une question.

Imaginons que je veuille me connecter à un site. Sur la page de connexion, il y a les deux champs textes à remplir (Login et mot de passe). Je les remplis, avant de cliquer sur connecter.

Qui me dit que sur la page de connexion, il n’y a pas là aussi un script qui scrute ces deux champs pour récupérer mon login et mon mot de passe ?


D’où l’intérêt de la navigation privée systématiquement :

1-ca évite toute information retenue dans le navigateur

2-ca entraine nos neurones à retenir les mots de passe !


Fait !

Merci <img data-src=" />


Il n’y a pas une loi récente contre l’intrusion dans un système informatique avec de sévères peines de prison à la clé? <img data-src=" />



En taule les publicitaires <img data-src=" />


Bon ben je crois que je vais passer à un gestionnaire de mot de passe en 2018


Avec l’extension lastpass il est possible de désactiver le remplissage automatique.








JD a écrit :



Pour désactiver le remplissage automatique dans Firefox :

dans la barre d’adresse écrire about:config

rechercher : signon.autofillForms

mettre la valeur à False.





La manip équivalente dans les navigateurs basés sur Chromium, dont Vivaldi, est d’activer&nbsp;vivaldi://flags/#fill-on-account-select et relancer le brouteur.



Ce genre de script ne peut pas être considéré autrement que comme un malware. <img data-src=" />


Merci, je la cherchais justement et difficile de trouver l’info.



Et merci au passage à ceux qui ont donné la méthode sur les différents brouteurs et ne se sont pas contenté de dire “si on peut”. <img data-src=" />


Pour moi ça le résoud, ça ne récupère plus les données sauvegardées par le gestionnaire de mot de passe.

Firefox Developer 58.0b13


Merci Ra-mon, cela fonctionne, mais seulement après avoir redémarré le navigateur.

Pour Chrome bien entendu c’est&nbsp;chrome://flags/#fill-on-account-select qu’il faut mettre à Enabled (pas vivaldi://)


Pas de problèmes chez moi avec firefox 57.03, ghostery et noscript


Pas de trace c’est déjà une très bonne trace.


Rien.

Quand tu donnes ton login/mdp à un site web, c’est que tu lui fais confiance pour les gérer… ce dont il est plus ou moins digne. Mais c’est logique que quand tu t’authentifies, il sache qui tu es (et puisse te tracer comme tel).



Ce qui est vicieux ici, c’est qu’il se débrouille pour savoir qui tu es même lorsque tu n’es pas authentifié et tu n’as rien saisi.


Je suis le seul à penser qu’il n’y a pas réellement de faille dans ce cas ?

&nbsp;

Que le mot de passe se rentre tous seul ou pas, tous les scripts inclus dans une page (third party ou non) ont accès aux mot de passe que l’on rentre pour se connecter.



C’est aux sites que revient la responsabilité de ne pas inclure de js third party qui ne sont pas de confiance.



Car même si on rentre le mot de passe à la main, tous les scripts de la pages y ont accès, donc vraiment je ne vois rien de surprenant dans cette démonstration…

&nbsp;

Ou alors j’ai raté quelque chose!

&nbsp;


Bah pour le coup, c’est que c’est retro actif. Le script n’a pas eu besoin d’être la quand tu t’es loggé. Mais sinon en effet, ca me semble pas porter beaucoup plus loin.



edit : J’ajoute aussi qu’il n’a pas besoin d’etre présent sur la page de login, et ca pour le coup, c’est pas rien


Cela dépend de ta config. Il y a maintenant 2 valeurs :

signon.autofillForms&nbsp; par défaut à true (vrai)

signon.autofillForm.httppar défaut à false (faux)

&nbsp;

Donc par défaut si tu ne touches à rien, les formulaires https sont remplis mais pas ceux en http. Les scripts dont il est question étant intégrés par le site visité, il est probable que cela fonctionne si ceux-ci sont en https.


D’un autre côté, est-il normal que des navigateurs remplissent des champs de formulaire cachés ? Je pense que le vrai problème est là.








Zerdligham a écrit :



Rien.

Quand tu donnes ton login/mdp à un site web, c’est que tu lui fais confiance pour les gérer… ce dont il est plus ou moins digne. Mais c’est logique que quand tu t’authentifies, il sache qui tu es (et puisse te tracer comme tel).



Ce qui est vicieux ici, c’est qu’il se débrouille pour savoir qui tu es même lorsque tu n’es pas authentifié et tu n’as rien saisi.





Je pensais plus au script d’un annonceur , qui serait intégrer à la page de connexion, pas au site lui-même. Un peu comme présenté dans l’article.

Une publicité est affichée sur la page de connexion, mais cette publicité scrute le champs login et mot de passe, pour les envoyer sur les serveurs de l’annonceur.

L’annonceur pourrait ainsi récupérer ton login et ton mot de passe, sans même utiliser de faille.



Vu le nombre d’API qui sont utilisées aujourd’hui pour faire tout et n’importe quoi sur un site, rien n’empêcherait ces API de scruter tous les champs login et mot de passe de tous les sites qui les utilisent, afin de se monter une base de données : Site, login, mot de passe.



hum encore un article à balancer au prochain qui viendra pleurnicher sur le fait que les vilains internautes font tout pour éviter de se faire traquer et ensuite matraquer à coup de pub.



Avec beaucoup de chances, peut-être que ça donnera au législateur européen un électrochoc, et que celui-ci imposera des règles strictes afin de garantir le droit à l’utilisateur de choisir de partager ses données personnelles.




Jonathan Métillon, directeur de l’innovation et de la communication, nous a ainsi expliqué que le script en question « était expérimental et est d’ailleurs déjà désactivé. Il avait été mis en place par des personnes qui ne travaillent plus chez nous ».



En quoi le fait que ça a été mis en place par des personnes qui ne sont plus là change quoi que ce soit à la responsabilité de la société ? Ces personnes devaient être encadrées et donc les responsables ont laissé faire ou peut-être même encouragé. Bref, la société est responsable et devrait s’excuser platement.



Lui-même présent depuis 2013 à des postes de management devrait faire profil bas.



Mais quand je lis son appel à candidatures sur son profil LinkedIn, je suis sans illusion :





Adthink.com is looking for:



* Traders / Media Buyers

* Business Developers

* Product Managers



Accepting only smart and ambitious people with excellent analytical thinking and/or fabulous negotiation talent. Extremely incentivized package with multiple bonuses! Connect to me now to join Adthink.com



Bref, il pense que le fric sera leur motivation, fric fait sur l’exploitation des données personnelles.


Salut,

Je ne trouve pas ton deuxième paramètre dans about:config. Problème de frappe ?


Sur quelle version de firefox es-tu ? (certains com, dont celui auquel tu réponds d’ailleurs, laissent à penser que le 2eme est plus ou moins récent)



En version 57.0.3, en tapant juste signon dans la barre de recherche j’ai :

signon.autofillForms

signon.autofillForms.http



en ligne 2 et 3, respectivement


Toutes les news sur les publicités me font dire que ce sont des menaces capables :





  • de collecter des données de manière malveillante ou non afin de mettre en place un profilage;

  • et surtout de diffuser des scripts évolués (potentiellement malveillants) par l’intermédiaire de sites considérés comme étant de confiance.







    Interdiction des scripts publicitaires… “It’s the only way to be sure” comme disait Ripley.


effectivement tu as raison.



J’ai donc modifié le “signon.autofillForms” en false pour être tranquille.



Merci pour l’info ;)