PEBKAC #4814

Lors d'un passage sur un site de vente au enchères, je tombe sur la page d'un concours. Pour participer, il suffit de taper son identifiant et son mot de passe du site. Seulement, je constate que la page est en HTTP et non en HTTPS. Donc le mot de passe circule "en clair". Je leur signale ce souci de sécurité.

Un peu plus tard, j'obtiens une réponse : "Lorsque vous participez au concours, vous devez saisir votre nom d'utilisateur et votre mot de passe afin que votre participation soit validée ; cependant, tout cela est sécurisé, comme lorsque vous souhaitez valider une offre lors d'une enchère".
Vive la sécurité. PEBKAC.

PEBKAC #4814 proposé par Krynn le 17/01/2012 | 25 commentaires | 👍🏽 👎🏽 +290

Les notions de sécurité, surtout en réseau, sont pas claires pour tout le monde...
Mais faut être initié pour capter un peu ce qu'il peut se passer entre ton ordinateur et...ailleurs (un lambda n'en sait pas plus...).

Commentaire #29599 écrit par Cartman34 le 28/03/2012 à 19h11 | 👍🏽 👎🏽

Je sais que les formulaires flash ou java peuvent être en http alors que la page est en https. L'inverse est peut être envisageable non?

Commentaire #29606 écrit par Hum. le 28/03/2012 à 21h45 | 👍🏽 👎🏽

Il est aussi possible de hasher (crypter) le mot de passe avant l'envoi. L'HTTPS n'est pas forcément nécessaire pour tous les sites WEB. La plupart des forums fonctionnent sur ce principe.

Commentaire #29726 écrit par OzoneGrif le 28/03/2012 à 22h19 | 👍🏽 👎🏽

Bête type, la faille a déjà été divulguée.

Commentaire #29729 écrit par Paulli le 28/03/2012 à 22h42 | 👍🏽 👎🏽

@OzoneGrif : Hasher le mot de passe coté client ? Et pour ceux qui n'ont pas JavaScript ?

Commentaire #29730 écrit par Rudloff le 28/03/2012 à 22h52 | 👍🏽 👎🏽

Y'a aucun intérêt à hasher le mot de passe coté client, suffit que le pirate envoie le mot de passe hashé et rebelote, le même problème.
A la rigueur si tu mixes avec l'identifiant, que tu y inclues le temps actuel et un jeton d'accès... là ca devient délicat.

Commentaire #29731 écrit par Cartman34 le 28/03/2012 à 23h11 | 👍🏽 👎🏽

@Cartman34 : Au final, c'est s'embêter beaucoup pour rien alors que HTTPS n'est pas si difficile à mettre en place.

Commentaire #29734 écrit par Rudloff le 28/03/2012 à 23h26 | 👍🏽 👎🏽

@Hum L'inverse est envisageable et est même très répandu. C'est une erreur qui figurait encore il y a peu sur des mauvais sites comme Facebook ou Hotmail.

Avoir la page en HTTP et le formulaire pointant vers du HTTPS sécurise l'envoie, mais ne protège pas d'une attaque Man In The Middle qui peut capter la page, modifier ce fameux "https" en "http", et ensuite capter le mot de passe lors de l'envoie du formulaire.

C'est pour cela qu'il n y a qu'une seule configuration valable : absolument tout en HTTPS.

Commentaire #29743 écrit par Hart le 29/03/2012 à 09h55 | 👍🏽 👎🏽

@Hart
Le https n'empêche pas l'attaque man-in-the-middle :
http://sebsauvage.net/rhaa/index.php?2010/11/08/19/54/41-je-suis-conte[...]

Commentaire #29744 écrit par 1138 le 29/03/2012 à 10h09 | 👍🏽 👎🏽

Alors je viens d'aller vérifier sur facebook, je retire ce que j'ai dit, ils autorisent encore les pages HTTP. J'ai pu voir un beau mot de passe en clair passer dans les paquets. C'est magnifique.

@1138 Oui, bien sûr, aucune protection n'est parfaite, mais ça limite tout de même une partie des problèmes. Mieux vaut avec que sans.

Cela dit c'est en effet un gros problème.

Commentaire #29746 écrit par hfbav le 29/03/2012 à 10h29 | 👍🏽 👎🏽

Okay, je suis tellement doué que j'ai tapé le captcha dans la case pseudo...

Commentaire #29751 écrit par Hart le 29/03/2012 à 10h47 | 👍🏽 👎🏽

@Hart C'est pas grave, c'est du HTTPS ... *ironique*

@1138 Je crois que ce cas peut être simplement représenté par:
Poste client - Requête > Entreprise - Requête > Internet
Poste client < Certificat - Entreprise < Certificat - Internet

Ce que fait l'entreprise, c'est demandé un certificat à google, l'utiliser et donner le sien au poste client.
Ensuite, quand l'entreprise (en fait son proxy) reçoit les requetes HTTPS, elle les décrypte avec son certificat et les rencrypte avec celui de google pour retransmettre la requête à google.

Commentaire #29754 écrit par Cartman34 le 29/03/2012 à 11h09 | 👍🏽 👎🏽

C'est lourd, ça nuit à l'anonymat des transactions mais ça filtre tout, seulement pour faire ça faut avoir un contrôle total sur le réseau afin que les postes clients considèrent le proxy de l'entreprise comme "tout internet".

Commentaire #29755 écrit par Cartman34 le 29/03/2012 à 11h10 | 👍🏽 👎🏽

Bref au final si ça se trouve le mec en face à raison et il n'y a pas PEBKAC quoi...

Commentaire #29757 écrit par Hum. le 29/03/2012 à 12h28 | 👍🏽 👎🏽

@Cartman34
Bien sûr, l'homme du milieu ne peut pas être n'importe où. Mais, comme le signale Seb Sauvage dans mon lien ci-dessus :

« Maintenant pensez aux pays qui n'ont qu'un ou deux FAI nationaux, et dont les FAI (ou les gouvernements, c'est selon) possèdent un certificat racine installé dans tous les navigateurs (C'est le cas de la Chine, la Turquie, Taïwan...). Vous imaginez les possibilités ? Je vais le dire clairement: La possibilité de lire tout trafic HTTPS par substitution de certificat sans lever d'alerte. »

Commentaire #29764 écrit par 1138 le 29/03/2012 à 17h26 | 👍🏽 👎🏽

@1138 : En sécurité il faut faire confiance à au moins une personne. Si dans votre cercle de confiance ce situe l'attaquant vous êtes fini.

le protocole ssl protège en effet du MITM; mais uniquement s'il n'est pas dans le groupe de confiance (certificats de confiance). C'est là ou le plugin certpatrol est intéressant. Notamment pour cloisonner les cercles de confiance.

Commentaire #29765 écrit par but2ene le 29/03/2012 à 18h30 | 👍🏽 👎🏽

@Cartman34 : Je n'avais pas envie de détailler, mais effectivement la technique est de génèrer une clef unique lors de la création du compte, et tu stocke cette clef côté client aussi longtemps que possible (dans un cookie) afin d'éviter tout nouveau transfert. Cette clef de hashage est privé, ce qui rend l'inversion difficile. A cela tu ajoutes l'adresse IP de la machine cliente... niveau sécurité c'est comfortable.

@Rudloff : Si tu n'as pas de Javascript, tu n'as plus de Hashage (sauf en passant en mode Kerberos... C'est encore autre chose). Désactiver Javascript n'est pas une bonne idée.

Commentaire #29767 écrit par OzoneGrif le 29/03/2012 à 21h01 | 👍🏽 👎🏽

Moi ce qui me fait rire, c'est que les gens qui désactivent le Javascript sont les premiers à crier après les plugins flash...

Et non on ne peut pas tout gérer en HTML c'est balot!!!

Commentaire #29777 écrit par Hum. le 30/03/2012 à 12h01 | 👍🏽 👎🏽

@OzoneGrif : Il faut surtout ajouté un challenge généré aléatoirement par le serveur afin d'éviter le rejeu.

Mais rien n'empêche l'injection de code dans le client. Ca devient facile de tout récupérer, une fois notre script ou code html injecté. Suffit d'être topologiquement plus proche que le serveur pour répondre avant lui ou un simple DNS poisoning.

Commentaire #29784 écrit par but2ene le 30/03/2012 à 14h04 | 👍🏽 👎🏽

@Hum : La plupart des choses peuvent être faites coté serveur. Un bon site devrait être utilisable sans JavaScript ou Flash (ce qui n'empêche pas d'utiliser JS pour rendre l'utilisation plus agréable pour ceux qui l'ont).

Commentaire #29788 écrit par Rudloff le 30/03/2012 à 16h43 | 👍🏽 👎🏽

@Rudloff : On peut effectivement faire beaucoup de choses côté serveur, mais bonjour les allers-retours entre les deux machines :(
Après c'est un compromis entre sécurité et confort d'utilisation.

Commentaire #29791 écrit par Acorah le 31/03/2012 à 00h00 | 👍🏽 👎🏽

Heu oui ça peut être fait côté serveur, je suis le premier à râler quand une page ne gère pas l'historique à cause d'un vieux script tout moisi.

Pour le JavaScript, le nombre d'échange d'informations est identique du côté client. C'est plus niveau serveur où l'on envoi globalement moins d'infos puisque le document peut être modifié dynamiquement.

Sans JavaScript ce qu'on appelle le 2.0 (lol) on peut s'assoir dessus...

Le flash (et les applets java) c'est différent dans le sens où l'utilisateur télécharge son application puis après interagit avec.

Commentaire #29802 écrit par Hum. le 02/04/2012 à 03h08 | 👍🏽 👎🏽

Enfin, on est plus à l'ère où les ordinateurs personnels ont la puissances de calculs d'une moule asthmatique (mon téléphone à un processeur à 1 GHz c'est juste ~1000 fois plus puissant qu'un commodore 64 vieux de 30 ans mais c'est un autre sujet... :P).

Il peut être intéressant d'un point de vue réseau, charge serveur de laisser le client (avec tout les risques que ça peut impliquer suivant la sensibilité du calcul...) effectuer une partie des calculs.

Commentaire #29803 écrit par Hum. le 02/04/2012 à 03h15 | 👍🏽 👎🏽

Alors oui quand on fait un site pour une baraque à frite, on s'en tape un peu de ces considérations, mais quand on doit mettre en place des applications web ou que l'on a un trafic conséquent ces outils peuvent être intéressants et bénéfiques.

L'informatique c'est comme les armes, l'alcool et la drogue, c'est pas parce que quelque chose peut être potentiellement mal utilisé qu'elle le sera.

M'enfin, c'est typique de notre époque, si quelqu'un peut faire mal quelque chose avec, alors c'est mauvais. C'est vraiment une vision étriquée de la réalité...

Commentaire #29804 écrit par Hum. le 02/04/2012 à 03h27 | 👍🏽 👎🏽

@hum : Certes mais quand je vois les économies de batterie quand je désactive le flash. Sur les sites où je surf le flash est au 3/4 utilisé pour de la pub.

@XSS : lol t'as pas remarqué que les < et > étaient convertie en < et >

Commentaire #29808 écrit par but2ene le 02/04/2012 à 09h20 | 👍🏽 👎🏽