Chrome : une faille des extensions vole les mots de passe

Le pire, c'est que c'est évident ce qu'il dit ce mec. Drôle que personne s'en soit rendu compte avant
Et pour corriger ça... dur dur... je sais pas comment ils vont s'y prendre parce que ça remet en question les capacités même des extensions.

Sinon j'aime bien le lien "Les meilleures extensions pour Google Chrome" en-dessous, pour l'instant faudrait plutôt toutes les désactiver

Ça me semble pas être une faille à proprement parler et j'imagine qu'on peut faire exactement la même chose sur tous les autres navigateurs qui proposent des extensions.
C'est simplement à l'utilisateur de faire attention à ce qu'il installe sur sa machine

Impossible à détecter !

A moins que l'extension soit open-source et que l'utilisateur "averti" y jette un coup d'oeil... mais tout ce qui est malicieux est caché en général...

Je dis peut être une bêtise, mais il me semble que les extensions c'est du javascript donc on a accès à la source.
Enfin bref, je voulais surtout dire passer par des éditeurs de confiance comme pour tout les autres soft

Peut être serait il temps alors de créer un système d'authentification différent de simple champ ...

Potentiellement oui. C'est même étonnant que ce soit si évident et pourtant jamais relevé avant.

Sinon c'est déjà largement plus facile à détecter que de détecter les problèmes dans les logiciels propriétaires au code fermé

OpenID...

Au contraire, je dirais qu'il est facile de détecter ce genre de choses avec un pare-feu de type zone alarm ou little snitch donnant l'adresse des connexions sortantes.
Si vous connectez sur facebook et que vous voyez chrome aller sur www.givemeyourpasswd.com, vous vous doutez qu'il y a anguille sous roche.

C'est clair qu'il faut faire attention aux plug-ins et logiciel tiers.

Bonne journée.

Là c'est juste une preuve de concept, étant donné que l'extension à accès à tout le DOM, je pense qu'il peut aussi très bien aussi envoyer le mot passe en message privé sur Facebook. Comme ça pas de connexion suspecte et à moins de faire du Wireshark c'est invisible

Je suis sûr qu'il y en a qui me diront qu'ils testent chacune des extensions qu'ils installent mais comment le font-ils ??? en installant l'extension sur son navigateur habituel puis en checkant les échanges...
Il faut donc s'y connaitre et avoir une vraie procédure pour tester chacune des extensions...

Et c'est la gros problème. Je ne dis aps que c'est impossible mais c'est que tout ce que vous dites n'est pas faisable par plus de 90% des personnes qui utilisent un navigateur moderne...
Donc à mon humble avis le problème reste le même !




C'est bien vrai !

Pour le blaireau de base, il ne faut pas qu'il utilise d'autres extensions que celles présentes sur le site de Google. (Un faux mail de facebook leur demandant leur login et passe fonctionne aussi bien )
Après c'est de la responsabilité de Google de proposer des extensions fiables.

Ce que je veux dire c'est que techniquement, il est facile de détecter ce genre de choses.
Voir même, si l'extension touche à l'objet XMLHttpRequest et dans quelles conditions.
Les extensions ne sont pas du code compilé, on peut même lancer un debugger pas à pas.

Sous Firefox c'est la même chose, je peux ajouter des éléments dans les pages changeant les action des balises form.

C'est le concept d'un plug-in, c'est de modifier des choses.
Je pense que Google et Mozilla ont la responsabilité de tester les plug-ins qu'ils diffusent.
Il doivent même avoir des outils pour le faire.

Après comme je le dis, il faut faire gaffe à ne pas installer n'importe quoi.

Ce n'est que mon avis ...

ps : C’est bien trouvé le coup du message privé en n'oubliant pas de supprimer le message envoyé.

Google a simplement oublié d'empêcher les extensions d'avoir accès au champ de type password. Ce n'est pourtant pas dur à mettre en place.

Le champ password c'est pas suffisant. Surtout quand l'extension peut remplacer le champ réel par un faux qui récupère le pass...
Là c'est une faille phénomènale, et je vois vraiment pas comment ça peut être corrigé sans virer les extensions tout court.

C'est déjà une sécurité qui fonctionne dans la grande majorité des cas ; si le navigateur empêche l'accès aux données des champs de type "password" et la modification du document et de son comportement lorsqu'il s'agit de tels champs.

Selon comment est programmée la gestion des extensions Chrome, cela pourrait se limiter à l'ajout de deux instructions conditionnelles dans le code.

Il ne faut pas oublier les claviers virtuels et l'ajax. Le contre coup serait de contourner les adsbocker avec un champs password.

il faut peut-être accorder different degrès de confiance au plugins.

ça commence mal pour cette nouvelle possibilité !

La modification du document, c'est 99% des extensions.

Oui, mais je parle d'empêcher de modifier les objets DOM et les propriétés liés aux champs password.

Oui mais ce qu'on essaye de vous dire c'est que ca ne suffit pas.
Il faut aussi interdire l'ajout de script qui serait susceptible de changer cet objet. (ce n'est pas gagné)
Interdire aussi les objet mettant une div devant. (pas gagné non plus)
...
J'en passe et des meilleurs.
Je pense qu'on peut arriver à interdire toute modification du document.

Et oui, car même sans l'accès aux champs password, tu peux toujours remplacer ce champ password par un autre...

C'est très problématique ce machin...

Et puis pour les sites qui ne sont pas en HTTPS, il y a encore la possibilité de récupérer le mot de passe dans les trames HTTP ...
Sous Chrome je sais pas si c'est possible, mais sous Firefox il y a des extensions comme LiveHTTPHeaders qui savent lire les trames.

Je ne suis pas tellement étonné par un tel hack. J'ai été très surpris quand j'ai découvert que Chrome ne gérait pas de master-password pour protéger sa base de mots de passe enregistré. Ca fait de Chrome de toute façon une passoire sécuritaire pour tous les PC quand on voit la quantité de mots de passe que nous laissons en général sauvegardés dans le navigateur...

Il me semble que chrome laisse le système gérer les mots de passes (c'est le cas sous mac os X). Le master password est donc le passe de session. Voir même stocké dans une puce TPM.
Contrairement à Firefox qui utilise sa propre base d'où ce password.
Sous linux, il faudrait que je creuse la question.

Sur Firefox les mots de passe sont aussi en clair...

Et donc quel est le résultat 6 mois après ?
Je découvre la faille.