En effet. Je viens de vérifier à l'instant. Pour cette partie je me suis trompé, je n'avais pas compris la situation.
Mais ça confirme mon histoire de Man in the Middle et l'intérêt des certificats.
Dans le cas où tout va bien, le formulaire est envoyé vers une page en HTTPS. Pas de problèmes, le certificat est approuvé. Je suis un utilisateur lambda, je ne regarde pas la code source de la page qui est également très remplit, limite indigest. Même moi, je n'ai pas regardé le code source de la page (bad practice pour moi
).
Dans le cas où tout va mal : je suis sur ton réseau, wired ou pas et je vois les trames circuler. J'ai fait un petit proxy en python adapté à mon besoin : je peux récupérer les pages web de PH, en modifiant ce form d'une manière ou une autre afin de rediriger le résultat vers mon propre serveur/ordinateur.
Maintenant que j'ai ce proxy, je vais attaquer le réseau. ARP cache poisonning par exemple, simple à mettre en place et efficace (cf Scapy). Je me fait passer pour la passerelle ou le routeur...
Du coup, la connexion d'un ordinateur du réseau passera forcément par mon ordinateur. Lorsque l'utilisateur souhaitera se connecter à PH, il tombera sur ma copie de page contrefaite. Mais qu'ais-je fait ?
J'ai modifié le formulaire pour que les données soient envoyées sur mon propre serveur, en HTTP même pas en HTTPS, comme ça il n'y aura pas d'alertes sur un possible certificat auto-signé.
Pour finir, j'ai deux solutions pour que l'utilisateur ne s'aperçoive de rien : je vais soit utiliser mon propre certificat, mais l'utilisateur aura une erreur, soit je vais le renvoyer sur une page d'erreur de connexion :
https://my.planethoster.net/
et le laisser naviguer tranquillement après cela...
Du coup j'ai obtenu tout ce dont j'avais besoin...
Cette manoeuvre aurait pu être évitée si l'utilisateur avait été forcé de passer par une page web liée à un certificat SSL, celui de PH. Evidemment, avec une attaque MiM, on peut très bien essayer d'utiliser son propre certificat, mais maintenant les navigateurs sont très bien faits afin de prévenir l'utilisateur de ce genre de manoeuvre.
Autre désavantage de faire du POST transparent avec HTTPS, l'utilisateur est moins sensibilisé aux problèmes de sécurité liés au sniffing du réseau...
D'où ma proposition d'une page dédiée in fine...
J'ai essayé de présenter un exemple bateau. Il y a des subtilités que je n'ai peut être pas présentées. C'est ce que je ferai si j'étais un attaquant...
Et ne me dites pas qu'il y a peu de chances qu'un attaquant recherche des trames spécifiques à PH: l'attaquant ne cherchera pas que ça...
Enfin, ce ne sont que mes idées
Ça s'adapte à plein de situations sympas
(obtenir le cookies et l'identifiant de session => Facebook).
Il n'empêche AsTr0 excuse-moi pour ma méprise tout à l'heure
La morale de l'histoire: surfez avec un serveur VPN (celui de votre entreprise, de votre université...), ne faites confiances qu'aux pages web en HTTPS pour saisir vos identifiants, et à défaut, lisez le source...
