L'historique du navigateur est-il un facteur important lorsque l'on considère la sécurité?
J'ai découvert quelque chose que je considère comme une vulnérabilité majeure dans un produit SaaS qui inclut le nom d'utilisateur et le mot de passe dans la chaîne de requête de l'URL lors de l'inscription et à chaque tentative de connexion.
Le support technique du service m'a dit qu'ils considéraient la vulnérabilité comme insignifiante, car la seule façon de l'exploiter est d'accéder à l'historique du navigateur de l'utilisateur.
Étaient-ils corrects dans leur décision? Je suis relativement nouveau dans le domaine de la sécurité de l'information, mais cela ressemble toujours à de la paresse de leur part.
J'ai parcouru cette question , mais après avoir lu la réponse la plus votée, je suis maintenant encore plus préoccupé par le fait que cela soit ignoré, car les données sont envoyées via GET et les informations d'identification sont affichées en texte brut.
Oui, c'est une vulnérabilité. Vous pouvez les diriger vers des corps d'août tels que
OWASP Top 10
- CWE
- Exposition des informations via les chaînes de requête dans la demande GET https://cwe.mitre.org/data/definitions/598.html
- Informations d'identification insuffisamment protégées https://cwe.mitre.org/data/definitions/522.html
- StackExchange
Le problème commun est que les informations d'identification sont stockées côté client en clair (historique du navigateur) et côté serveur (journaux de connexion du serveur Web) et il existe plusieurs méthodes pour accéder à ces données.
Oui, c'est de la paresse de leur part. Ils ne pensent qu'à leur code et oublient le côté client et l'infrastructure.
Les secrets n'appartiennent pas aux URL. Les URL apparaissent dans les historiques du navigateur, dans les caches de proxy, dans les journaux du serveur, sont envoyées aux fournisseurs de services analytiques et peuvent apparaître dans de nombreux autres endroits où vous ne souhaitez pas que des informations secrètes apparaissent. L'utilisation de HTTPS (ils font utilisent HTTPS, non?) Empêche uniquement la mise en cache du proxy, aucune des autres.
Les utilisateurs peuvent également copier et coller des URL autour sans remarquer que leurs informations de connexion sont toujours en eux.
Par conséquent, les enregistrements et les connexions doivent utiliser la méthode HTTPS POST avec les informations de connexion dans le corps du message.
Première règle de sécurité des produits: ne faites jamais confiance au fournisseur qui dit qu'un problème de sécurité n'est pas pertinent.
Je ne reproduirai pas déjà les réponses techniques données. Je veux les développer et souligner que l'évaluation qui les conduit à évaluer le problème comme non pertinent est basée sur hypothèses qui peuvent ou non tenir le coup dans l'environnement client. Sans une solide compréhension de votre environnement ils ne peuvent pas faire cet appel. C'est comme un constructeur automobile qui dit que conduire son nouveau modèle à 250 km/h est parfaitement sûr - il est probablement sur la piste d'essai, mais sur la plupart des routes du monde réel, ce ne serait pas le cas (qualité de la route et trafic).
Cela devient clair une fois que vous comprenez à quel point défectueux leur évaluation est. Mis à part l'historique du navigateur, un paramètre GET apparaîtra également dans les fichiers journaux du proxy et il peut être envoyé par erreur lorsque quelqu'un veut partager un lien, pour ne nommer que les deux autres moyens les plus évidents par lesquels ce secret pourrait fuir grâce à sa mauvaise décision d'ingénierie .
Compte tenu à la fois de la vulnérabilité elle-même et de leur mauvais raisonnement et de leur mauvaise gestion, je douterais sérieusement de leur capacité à fabriquer des produits sécurisés. Je voudrais leur faire savoir sans ambiguïté et réévaluer le produit à la lumière de ces nouvelles informations.
Tu as raison. Il y a deux choses ici:
- Informations d'identification dans l'URL
- Mise en cache dans le navigateur
Les informations d'identification ne doivent jamais être exposées dans l'URL. Les URL sont enregistrées à de nombreux endroits, par exemple un serveur proxy, des pare-feu, etc. Je serais ravi de voler ces informations si j'étais l'administrateur du pare-feu ou quelque chose du genre. Maintenant à leur point que l'attaquant aurait besoin d'accéder au navigateur. Et si l'utilisateur utilisait un ordinateur public? Diraient-ils toujours que c'est insignifiant? S'ils le font, mec, vous devez cesser d'utiliser leurs services.