Quels sont les vecteurs d'attaque des mots de passe envoyés via http?


10

J'essaie de convaincre un client de payer pour SSL pour un site Web qui nécessite une connexion. Je veux m'assurer de bien comprendre les principaux scénarios dans lesquels quelqu'un peut voir les mots de passe envoyés.

D'après ce que je comprends, à n'importe quel saut le long du chemin, vous pouvez utiliser un analyseur de paquets pour voir ce qui est envoyé. Cela semble exiger que tout pirate (ou son malware / botnet) se trouve sur le même sous-réseau que n'importe lequel des sauts que prend le paquet pour arriver à destination. Est-ce correct?

En supposant qu'une certaine saveur de cette exigence de sous-réseau soit vraie, dois-je m'inquiéter de tous les sauts ou juste du premier? Le premier, je peux évidemment m'inquiéter s'ils sont sur un réseau Wifi public car n'importe qui pourrait écouter. Dois-je m'inquiéter de ce qui se passe dans les sous-réseaux que les paquets traverseront en dehors de cela? Je ne connais pas beaucoup le trafic réseau, mais je suppose qu'il circule dans les centres de données des principaux opérateurs et qu'il n'y a pas beaucoup de vecteurs d'attaque juteux, mais veuillez me corriger si je me trompe.

Y a-t-il d'autres vecteurs à craindre en dehors de quelqu'un qui écoute avec un analyseur de paquets?

Je suis un gestionnaire de réseau et de sécurité, alors n'hésitez pas à me redresser si j'utilise la mauvaise terminologie dans tout cela.


si le site contient des informations bancaires ou financières, des informations personnelles, SSL est un pré-requis pour l'étape de connexion. S'il peut être piraté facilement, il le sera.
Mitch Wheat

2
Je ne vois aucune raison de fermer cela. C'est lié à la programmation.

Toute personne visitant ce site à partir d'un point d'accès partagé verra ses identifiants pris, même si l'AP utilise le cryptage lui-même (car tout le monde a également la clé). Si les gens réutilisent leurs crédits sur d'autres sites, c'est un problème.
Aaron

Réponses:


3

Quelque chose à noter que d'autres n'ont pas mentionné ici est que certains navigateurs mettent en cache vos données de formulaire. Le comportement par défaut sur les sites SSL est généralement de ne rien mettre en cache sauf si vous avez choisi "enregistrer mon mot de passe". En règle générale, les champs de mot de passe ne sont pas mis en cache, mais j'ai vu quelques bizarreries (généralement les informations de carte de crédit, qui, je le sais, ne sont pas vraiment le sujet de la question).

L'autre chose à noter est que le cryptage SSL commence à la négociation TCP. Une fois sous SSL, vous ne pouvez pas distinguer HTTP sur SSL de FTP sur SSL (à part les hypothèses faites via le numéro de port).

Vous ne pouvez pas non plus distinguer une demande de connexion d'une demande "Je ne fais que naviguer", cela obscurcit le flux de pages des pirates potentiels et garantit également non seulement la sécurité de vos données de mot de passe, mais aussi votre historique de navigation / données de cookies / et tout autre les informations personnelles qui accompagnent votre compte.

Dans l'ensemble, si vous éliminez les attaques de l' homme du milieu du spectre, vous réduisez de nombreuses attaques potentielles, cela ne veut pas dire que votre site est "sûr". La politique de zonage devrait également vous aider à vous protéger contre les attaques XSS, car vous effectuerez un changement de zone si votre utilisateur est redirigé hors de votre site.


"hypothèses faites via le numéro de port"? Le port ne serait-il généralement pas 443 pour SSL (HTTP ou FTP)?
brickner

4

Les données sont vulnérables n'importe où le long de l'itinéraire, pas seulement la première ou la dernière étape. Il est tout à fait concevable qu'un système impliqué dans le transfert recherche des noms d'utilisateur, des mots de passe et d'autres données sensibles. Il s'ensuit donc que les données sensibles ne doivent voyager que sur un lien qui est sécurisé tout le long et bien sûr, c'est exactement à cela que sert SSL. Selon les données impliquées, il peut bien y avoir des lois locales qui dictent SSL.


Peut-il traverser des sous-réseaux auxquels les consommateurs ont accès ou passe-t-il simplement par les dorsales des principaux opérateurs, auquel cas nous devrions supposer que le pirate a craqué, par exemple le centre des opérations de niveau 3 (juste par exemple)?
KevinM

Normalement, je ne m'attendrais pas à ce qu'il passe par les réseaux de consommateurs, mais gardez à l'esprit que tout système peut être compromis. Bien que nous devrions pouvoir nous attendre à ce que les fournisseurs d'accès Internet et les systèmes de l'opérateur soient plus sûrs, nous savons également que beaucoup ont été compromis par le passé. Aucun système ou réseau n'est à l'abri du piratage, d'où la nécessité de choses comme SSL. Il pourrait même s'agir d'un employé du FAI qui recueille les informations circulant sur le réseau. Un simple robinet passif suffit.
John Gardeniers, du

1
Il peut également s'agir de votre agence gouvernementale préférée qui installe les robinets avec l'aide de votre FAI ... Si vous considérez qu'une attaque ou non vous appartient.
pehrs

2

Il existe des serveurs proxy qui peuvent stocker des données.

Mais il est également obligatoire de protéger les mots de passe des utilisateurs. De nombreux utilisateurs utilisent un ensemble limité de mots de passe, donc un site dangereux peut compromettre leur mot de passe de banque personnelle par exemple.


1
Oui, votre deuxième point est important. Je pense qu'il est approprié que les sites Web n'agissent pas comme s'ils étaient le centre du monde des utilisateurs.

1

Votre analyse est raisonnable, à mon humble avis.

La chose à noter, je suppose, est qu'il pourrait y avoir des caches sur votre chemin. Il se peut donc que la demande soit enregistrée quelque part (surtout si la connexion se fait via GET, ce qui serait terrible).

La chose à considérer est probablement que la plupart des accès au réseau ont lieu dans une zone où il y a beaucoup d'autres personnes sur le même réseau. Travail / Uni / Ecole en sont les principaux exemples. À la maison, vous pourriez dire que c'est moins risqué, car ce ne sont que les chemins vers le haut dont vous devez vous préoccuper.

Mais vraiment, il n'y a pas de question ici. Vous utilisez SSL lorsque vous vous connectez. L'argument le plus convaincant pour le gars sera probablement que cela rend votre site Web plus fiable, car - idéalement - le grand public ne se connecterait jamais à un site qui n'a pas d'écran de connexion basé sur SSL .

Mais soyons réalistes. Ce vecteur d'attaque n'est certainement pas la façon dont son système ou ses utilisateurs seront compromis.

HTH.


1

Je peux être d'accord avec les réflexions de KevinM pour répondre à ses propres questions, et John Gardeniers pointe dans la bonne direction. Je dois également être d'accord avec ce que Silky a dit, "idéalement - le grand public ne se connecterait jamais à un site qui n'a pas d'écran de connexion basé sur SSL.", Et souligner que ce n'est cependant pas le cas contemporain du tout.

Je suis en désaccord avec le ton soyeux (probablement involontaire), qui mène à la perception omniprésente que, "le grand public", est stupide. Le client de KevinM n'a clairement aucun concept d'un besoin de SSL, et c'est votre personne moyenne en bref. Ils ne sont pas stupides, ils ne savent tout simplement pas. Dire «vous en avez besoin», rendra la réponse «je vivrai x ans sans ça, et je vivrai x plus bien», ou peut-être même une pire réponse, «je déteste qu'on me dise ce dont j'ai besoin . " Donc sois prudent!

Votre inquiétude est légitime, Kevin. Votre client a besoin d'un certificat SSL. Je pense que votre véritable préoccupation devrait être de savoir comment en vendre un. Il ne s'agit pas seulement des connexions utilisateur, mais des connexions administrateur et opérateur qui bénéficieraient également d'être protégées par SSL.

Oui, il y a d'autres choses à craindre à cet égard, encore plus que le reniflage de paquets, comme XSS . Ils sont nombreux et bien documentés .


Merci Daniel. Je pense qu'il est important non seulement d'avoir des règles arbitraires, mais de comprendre ce qui donne naissance aux principes que nous avons. Je voulais donc m'assurer de pouvoir articuler ce droit. Heureusement, j'ai réussi à convaincre le client d'obtenir SSL.
KevinM

0

dans toute la route suivie par le paquet, si son over HTTP peut être reniflé et les données peuvent être vues ... même si vous utilisez HTTP dans un proxy comme TOR ... en utilisant la récolte-attaque, etc. on peut tromper le proxy pour faire fuir les paquets de données ... donc s'il y a quelque chose de proche de sensible (mots de passe, détails personnels, images privées, etc.) ... il ne convient que de les transférer via HTTPS.

Cela aussi, même HTTPS est vulnérable avec une mauvaise mise en œuvre et il existe plusieurs attaques SSL applicables par-dessus ... celles-ci peuvent néanmoins être évitées avec une mise en œuvre minutieuse.

Mais, utiliser HTTP pour du texte brut, c'est comme inviter même les enfants novices n / w à renifler les mots de passe.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.