hpsmartyz Posté(e) le 23 mai 2009 Posté(e) le 23 mai 2009 Bonjour, il est possible d'accéder à une page sécurisée par htaccess/htpasswd en tapant directement le login/pass dans l'url du navigateur: https://login:pass@www.monsite.com/mapartiesécurisée je voudrais savoir si ces identifiants passent alors en clair sur le réseau. merci
hpsmartyz Posté(e) le 27 mai 2009 Auteur Posté(e) le 27 mai 2009 petit up, pour les connaisseurs merci
lagaffe Posté(e) le 27 mai 2009 Posté(e) le 27 mai 2009 Désolé, j'avais loupé ce post ... Non ils ne passent pas en clair (car ils sont "encapsulé" dans l'https), par contre si quelqu'un d'autre que toi reprend ta session ou ton historique de navigation (voir même si tu passes par un proxy), il pourra se logguer, sans connaitre le login/password vu qu'ils sont en clair dans l'URL. Pour ma part je préfére les taper, mais après chacun voit.
Diaoul Posté(e) le 27 mai 2009 Posté(e) le 27 mai 2009 Je crois que ça n'a rien à voir avec le https Un peu de lecture : http://www.securiteinfo.com/conseils/htaccess.shtml En gros, le navigateur fait 2 requêtes : Un GET tout con sans les infos Un GET avec les infos d'authentification encodées par le navigateur mais décodables ! Regarde donc le lien que je t'ai passé, tu devrais pouvoir contourner le problème en utilisant le hashage En tout cas, ce sera nettement plus sécurisé. Edit : oups pas vu le s de https ^^
stevanovich Posté(e) le 27 mai 2009 Posté(e) le 27 mai 2009 Bonjour, Je pense que la question de hpsmartyz était de savoir s'il y avait un moyen de sniffer le login et le password via la requête donnée dans le premier post . Sujet, très intéressant .... Mais je ne connais pas précisément la réponse, n'ayant jamais vraiment tenté l'expérience .... je ne m'aventurerai pas à emmettre des suppositions fausses... (Mais j'ai des doutes ) Cordialement.
hpsmartyz Posté(e) le 27 mai 2009 Auteur Posté(e) le 27 mai 2009 merci pour l'intérêt que vous avez porté à ma question. j'ai poussé un peu mes recherches. @stevanovich, tu as bien compris ma question @Diaoul, la page que tu m'indiques parle d'http et non d'https @lagaffe, @phi. Il semble que la balance penche plutôt pour la réponse de lagaffe. en https la transmission des données se fait après l'établissement d'un canal crypté et il semble que toute l'url soit cryptée par la suite. En fait seuls le nom du serveur et le port sont bien sûr envoyés en clair afin d'établir la session tls/ssl. Donc oui c'est "safe" du point de vue intermédiaire mais pas du tout du point de vue des hosts et serveurs. Un peu de lecture: http://stackoverflow.com/questions/499591/...-urls-encrypted http://stackoverflow.com/questions/830074/...-url-parameters http://stackoverflow.com/questions/893959/...e-from-sniffing http://stackoverflow.com/questions/73536/a...ncrypted-by-ssl http://www.ourshop.org/resources/ssl_step1.html
Diaoul Posté(e) le 27 mai 2009 Posté(e) le 27 mai 2009 Comment ça pas du point de vu des hosts et serveurs ? Je ne vois pas d'où pourrait venir la faille. Edit : Je complète ma réponse en signalant que dans https://login:pass@www.monsite.com/mapartiesécurisée, la partie login:pass ne fait à mon avis pas parti de la requête GET, ni POST d'ailleurs. Edit 2 : Je viens de tester avec un petit serveur en java que j'ai lancé en local, voici le contenu de la socket pour l'URL http://login:pass@localhost:5001/ lue par le serveur et envoyée par mon navigateur favoris, Firefox : GET / HTTP/1.1 Host: localhost:5001 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Aucune trace de login:pass Donc ce doit être pareil en https, y'a pas de raison. L'explication : FF attends la réponse du serveur : "Hey identifie toi" avant de lui balancer les identifiants et login. Ceux ci seront de toutes façon vraisemblablement crypté, https oblige.
Marcellusio Posté(e) le 28 mai 2009 Posté(e) le 28 mai 2009 Pour moi quand on tape l'URL comme hpsmartyz, il y a l'url qui est pas crypté puis quand la connexion est établie les login et mdp sont transmis en HTTPS mais il est certain qu'il y a pas de sécurité du coté client ou serveur où l'on peut avoir les informations en clair. C'est petre meme à regarder avec un analyseur de trames et voir si les différents navigateurs réagissent de la meme manière. Tu veux savoir cette information pour quoi faire hpsmartyz ? L'HTTPS ne sert qu'à protéger les informations entre le serveur et le client mais ne protège rien sur le serveur ni le client.
hpsmartyz Posté(e) le 28 mai 2009 Auteur Posté(e) le 28 mai 2009 bonjour excuse je n'avais pas lu correctement mais lorsque tu fais https://login:pass@www.monsite.com/mapartiesécurisée cela voyage en clair sur le réseau, l'ouverture du canal crypté s'effectuant lors de l'envoi du certificat par le serveur et la reconnaissance de sa validité par le client. dans ton cas il vaut mieux https://www.monsite.com/mapartiesécurisée pour ouvrir le canal sécurisé puis attendre l'ouverture de la boite de dialogue pour saisir le ID/PASS du htaccess justement, phi, il semble que seul le nom d'hote transite en clair sur le réseau. le reste de l'url serait crypté
hpsmartyz Posté(e) le 28 mai 2009 Auteur Posté(e) le 28 mai 2009 bah partout ou j'ai regarder il est dit que cela n'est pas securisé par contre je viens d'éditer mon post si tu fait cela a travers un lien a cliquer qui est déjà sur une page HTML en protocole HTTPS alors le lien suivi sera crypté :-) ce n'est pas sécurisé car cela laisse des traces dans l'historique du navigateur sur l'hote, des traces dans les logs sur le serveur, mais qu'en tout cas il n'y aurait pas moyen de sniffer le login/pass au milieu sur le réseau. L'un dans l'autre je pense que ce n'est pas très propre et que remplir les champs d'un pop-up de login n'est pas suffisament compliqué pour avoir recours à cette solution.
Marcellusio Posté(e) le 28 mai 2009 Posté(e) le 28 mai 2009 ce soir ou durant le weekend, je ferai une capture avec un sniffeur pour voir de quelle manière les informations passent. Oui je pense que de rentrer les informations dans le pop-up est bien mieux niveau sécurité.
hpsmartyz Posté(e) le 28 mai 2009 Auteur Posté(e) le 28 mai 2009 ce soir ou durant le weekend, je ferai une capture avec un sniffeur pour voir de quelle manière les informations passent. Oui je pense que de rentrer les informations dans le pop-up est bien mieux niveau sécurité. merci Marcellusio, je suis preneur de ton retour d'expérience.
stevanovich Posté(e) le 28 mai 2009 Posté(e) le 28 mai 2009 ce soir ou durant le weekend, je ferai une capture avec un sniffeur pour voir de quelle manière les informations passent. Oui je pense que de rentrer les informations dans le pop-up est bien mieux niveau sécurité. Bien vu Cordialement.
Marcellusio Posté(e) le 30 mai 2009 Posté(e) le 30 mai 2009 Bonjour ! me voila de retour apres plusieurs essais en http et https. alors dans un mode ou l'autre on ne voit pas les mots de passe en clair, que ca soit dans l'url ou pas. ce qu'il y a de moins sécuritaire c'est de devoir marquer le login et le mot de passe dans l'url. C'est pour cette raison que d'utiliser la popup me parait bien mieux. j'ai meme fait des essais IE8 et firefox et les résultats sont similaire. Les moments où j'arrive a avoir les mots de passe sont quand je me log sur une page internet en http avec un simple formulaire. Donc en résumé le htaccess est bien protégé avec de l'http ou de l'https et il est conseillé d'utilisé la popup
Diaoul Posté(e) le 30 mai 2009 Posté(e) le 30 mai 2009 Comment ça pas du point de vu des hosts et serveurs ? Je ne vois pas d'où pourrait venir la faille. Edit : Je complète ma réponse en signalant que dans https://login:pass@www.monsite.com/mapartiesécurisée, la partie login:pass ne fait à mon avis pas parti de la requête GET, ni POST d'ailleurs. Edit 2 : Je viens de tester avec un petit serveur en java que j'ai lancé en local, voici le contenu de la socket pour l'URL http://login:pass@localhost:5001/ lue par le serveur et envoyée par mon navigateur favoris, Firefox : GET / HTTP/1.1 Host: localhost:5001 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Aucune trace de login:pass Donc ce doit être pareil en https, y'a pas de raison. L'explication : FF attends la réponse du serveur : "Hey identifie toi" avant de lui balancer les identifiants et login. Ceux ci seront de toutes façon vraisemblablement crypté, https oblige. Bonjour ! me voila de retour apres plusieurs essais en http et https. alors dans un mode ou l'autre on ne voit pas les mots de passe en clair, que ca soit dans l'url ou pas. ce qu'il y a de moins sécuritaire c'est de devoir marquer le login et le mot de passe dans l'url. C'est pour cette raison que d'utiliser la popup me parait bien mieux. j'ai meme fait des essais IE8 et firefox et les résultats sont similaire. Les moments où j'arrive a avoir les mots de passe sont quand je me log sur une page internet en http avec un simple formulaire. Donc en résumé le htaccess est bien protégé avec de l'http ou de l'https et il est conseillé d'utilisé la popup C'est marrant, j'ai dis la même chose 6 posts plus haut
stevanovich Posté(e) le 1 juin 2009 Posté(e) le 1 juin 2009 C'est marrant, j'ai dis la même chose 6 posts plus haut Le principal est d'avoir la confirmation et l'information, 2 fois certe, mais dans le même sens . Il a peut-être "zappé" ton post ... Chose qui m'arrive de temps en temps ... Cordialement.
hpsmartyz Posté(e) le 1 juin 2009 Auteur Posté(e) le 1 juin 2009 merci de vos retours mais je reste un peu dubitatif. Qu'avez vous utilisé pour récupérer ces données? Si rien n'apparait cela ne veut pas dire que cela ne passe pas en clair, il se pourrait simplement que l'outil n'affiche pas les infos, non?
Marcellusio Posté(e) le 2 juin 2009 Posté(e) le 2 juin 2009 je ne sais pas ce qu'a utilisé Diaoul et je n'ai pas zapé son post. Moi j'utilise wireshark anciennement nommé ethereal. On y voit les trames en hexa et décodé par le logiciel avec les ip sources et de destinations. voici le wiki du logiciel : ici et une image pour vous donner une idée :
Diaoul Posté(e) le 2 juin 2009 Posté(e) le 2 juin 2009 Pour ma part, j'ai fait codé un serveur en java et je t'ai affiché le contenu de la socket transmise par Firefox au serveur lue par le serveur lorsque l'URL demandée par le navigateur est du type "http://user:pwd@host.tld:port/" Donc lors de la première requête HTTP faite par Firefox, aucune trace de "user" ni "pwd" dans la socket, c'est à dire, aucune trace sur le réseau. Je peux faire le même essai en HTTPS, ça ne changera pas grand chose, sinon peut être des headers propres au HTTPS en plus de ceux du HTTP. Voilou
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.