Une redirection affichant le mot de passe en texte brut est-elle une vulnérabilité de sécurité?
Il y a quelques jours, j'ai essayé de me connecter au site Web d'un fournisseur bien connu SaaS. J'ai utilisé un gestionnaire de mots de passe sur mon navigateur (donc l'utilisateur/pass était correct) et le plugin NoScript qui avait des autorisations limitées accordées au site, donc certains JS ont été bloqués. L'ensemble de l'échange était sur HTTPS.
La réponse a été une redirection vers le site de connexion avec une URL comme ci-dessous et le login_password les données avaient également été remplies à la valeur de l'entrée password.
.../[email protected]&login_password=REDACTED&remember_me=on
Serait-ce considéré comme une approche faible et une mauvaise pratique à soulever auprès du support client, ou cela devrait-il être signalé comme une vulnérabilité de sécurité?
Mise à jour
La société a répondu avec un correctif provisoire qui empêche la reproduction du problème d'origine.
Certainement problématique - et mérite d'être signalé.
Si le HTTPS est correctement protégé avec HSTS et préchargement , les acteurs de la menace observant le trafic ne pourront pas voir le GET Contenu. Mais comme HSTS est encore quelque peu rare (et s'ils mettent des mots de passe en clair dans un GET, ils ne sont probablement pas au courant d'autres meilleures pratiques comme HSTS), le risque d'interception/rétrogradation est probablement quelque peu élevé.
Indépendamment de cela, quelle que soit la santé de la configuration HTTPS, les serveurs HTTP distants enregistrent presque toujours le contenu GET complet dans les journaux du serveur - de sorte que ces mots de passe en clair sont probablement également enregistrés sur le serveur.
[Modifier: et réponse de vakus couvre le reste des vecteurs d'attaque de manière beaucoup plus approfondie!]
Cela devrait être signalé immédiatement.
Il existe une multitude d'attaques possibles qui pourraient entraîner la compromission des comptes d'utilisateurs.
Le mot de passe affiché en tant que paramètre GET n'est pas seulement une vulnérabilité selon OWASP , il existe de nombreuses façons de les abuser.
Des vulnérabilités courantes permettent le vol de mots de passe protégés via des vecteurs d'attaque tels que l'injection SQL. Les mots de passe protégés peuvent également être volés à partir d'artefacts tels que les journaux, les vidages et les sauvegardes.
(Citation et lien de mars Ho commentaire de)
J'irais même jusqu'à envisager un autre service, car une telle politique montre un manque de compétence.
Voici quelques faits saillants qui peuvent être inclus dans le rapport
Fichier journal
Le mot de passe soumis par le paramètre GET sera enregistré dans un fichier journal. Cela signifie qu'un administrateur du service peut désormais afficher vos mots de passe en texte brut. C'est aussi mauvais que de stocker des mots de passe en texte brut dans la base de données. Rien ne garantit aux utilisateurs que l'administrateur ou la personne privilégiée ne deviendra pas un voyou et n'utilisera pas les mots de passe des utilisateurs pour accéder à leurs autres services. Et comme nous le savons tous, la réutilisation des mots de passe est plus que courante.
Cela signifie également que si le système est compromis, l'attaquant n'a besoin que de lire les fichiers journaux plutôt que de casser la base de données. Il s'agit d'une vulnérabilité énorme qui entraînerait la compromission de nombreux comptes d'utilisateurs sur de nombreuses plates-formes.
ne chose similaire est arrivée à Twitter récemment , où les mots de passe étaient stockés en texte brut dans l'un des fichiers journaux internes. Twitter a invité tous les utilisateurs à modifier leurs mots de passe, y compris sur d'autres sites Web où les utilisateurs ont utilisé le même mot de passe, même s'il n'y avait aucune preuve de compromis ou d'abus de ce bogue. Cela montre que cela peut avoir un impact sérieux sur les utilisateurs si le serveur était compromis.
Cueillette des yeux de l'épaule
Quiconque se trouve à proximité pourrait voir votre mot de passe en texte clair et le noter. Ce mot de passe pourrait ensuite être utilisé pour compromettre d'autres services, car les mots de passe sont souvent réutilisés entre les services.
Historique du navigateur
Les mots de passe seraient stockés dans le cadre de l'historique du navigateur Web, ce qui signifie que toute personne ayant accès à votre ordinateur et à votre navigateur Web pourra se connecter à votre compte sans connaître le mot de passe. Cela ne fait qu'empirer si vous utilisez un ordinateur public.
À la suite de cela, toute personne ayant accès à l'historique peut désormais également copier votre mot de passe et votre connexion, ce qui permet à nouveau de compromettre vos autres services.
[~ # ~] https [~ # ~]
Vous avez dit que le site Web fonctionne avec HTTPS. Il n'y a cependant aucune garantie que le site Web utilise le préchargement et HSTS .
HSTS forcera un navigateur Web à charger le site Web via une connexion HTTPS.
Si le site Web n'utilise pas HSTS, il se peut que le site Web ne soit pas mis à niveau vers une connexion HTTPS. Cela peut être fait via SSL Strip, qui transformera tous les liens HTTPS en HTTP. Si le site Web utilise HSTS, le navigateur Web tentera automatiquement de charger le site Web via HTTPS et, s'il n'est pas en mesure de, refusera de se connecter par HTTP. Cependant, même si le site Web utilise HSTS, si le site Web n'a jamais été ouvert auparavant sur le navigateur Web cible, l'attaque SSL Strip fonctionnerait, car le navigateur Web ne saurait pas encore que ce site Web devrait uniquement être chargé via HTTPS.
Pour éviter cela, un site Web utiliserait le préchargement. Pour le préchargement, le navigateur Web aurait une base de données intégrée de sites Web qui doivent être chargés via HTTPS et ne doivent jamais être chargés par HTTP. Cela empêcherait efficacement un HTTPS attaque de rétrogradation.
Audits de sécurité
Le fait que les mots de passe soient stockés dans le cadre du fichier journal montre que l'entreprise n'effectue probablement pas d'audits de sécurité, ou s'ils le sont, qu'ils ne sont pas très fortement axés sur la sécurité en tant qu'entreprise.
Référent HTTP
Comme mentionné dans les commentaires de M. Llama
Les paramètres GET peuvent également apparaître dans les en-têtes de référence HTTP. Toutes les ressources hors site chargées à partir de la page peuvent également être expédiées vos informations d'identification via l'en-tête du référent.
Partage de liens
Si, pour une raison quelconque, vous devez donner un lien vers le site Web à quelqu'un d'autre, par exemple collègue, vous êtes plus que probable de le copier et de l'envoyer à cette personne. Cela donnerait à nouveau à cette personne l'accès à votre compte et à vos informations de connexion et de mot de passe, qui peuvent être utilisées pour accéder à des comptes sur d'autres plates-formes.
Araignées de recherche
Les araignées de recherche suivent essentiellement chaque lien possible sur un site Web et l'indexent. Bien que cela soit moins probable, une araignée de recherche comme Google ou Bing pourrait indexer un lien exposé et l'afficher dans le cadre de la recherche sur le site Web. Cela signifierait que les gens pourraient se connecter à votre compte depuis Google ou Bing.
Je voudrais aller aussi loin que possible pour contacter l'entreprise. L'impact sur la sécurité est énorme et affectera de nombreux utilisateurs.
J'envisagerais même de changer le fournisseur SaaS si possible, et si la société ne se conformait pas au rapport, ils devraient être publiquement honteux pour toute infraction au mot de passe.