Discussion :

[mapmip]

bonjour,
la boucle localhost (ip 127.0.0.1) du protocole http est interne à l'ordinateur à ce que j'ai compris.
Si je fais http://monlogin:monpassword@localhost:8983/solr

est-ce que monlogin et monpassword peuvent être interceptées par un sniffer ou quelque chose comme ca ?

ma question est relative à ce doc de securisation de l'accès à la page d'admin de apache solr :
http://2bits.com/articles/configurin...ntication.html

Merci d'avance

[Neckara]

Bonjour,

est-ce que monlogin et monpassword peuvent être interceptées par un sniffer ou quelque chose comme ca ?

Si les données circulent en HTTP et non en HTTPS, oui.
Mais il faut que le sniffer soit sur ton ordinateur et ai quelques droits spécifiques sous Linux (root ou appartenant au groupe wireshark (?) ).
Sous Windows, je pense qu'il faut posséder les droits administrateurs (?).

Si tu es sur ton ordinateur personnel, il y a donc peu de risques.
Une personne malveillante ayant des droits administrateur dessus pourra faire bien pire (sniffer, keylogguer, etc.).

Si tu es sur un ordinateur d'entreprise/école, il y a peut être un peu plus de risques.

[mapmip]

si je passe en https, "monlogin" et "monpassword" qui se trouvent dans mon url seront cryptés ?

[Neckara]

Installe whireshark et test.

Tu vas demander à ton DNS où trouver localhost, il va te dire 127.0.0.1
Ensuite, tu vas contacter 127.0;0.1 sur le port 8983.

Après, ton identifiant/mot de passe va être envoyé dans un en-tête "autorisation", donc en HTTPS je pense.

[Blo0d4x3]

Il ne me semble pas que les paramètres de l'url seront chiffrés.
Passe les plutôt en POST, comme ca c'est sur qu'ils le seront.

[Neckara]

Il ne me semble pas que les paramètres de l'url seront chiffrés.
Passe les plutôt en POST, comme ca c'est sur qu'ils le seront.

HTTPS, c'est du HTTP over SSL, c'est à dire qu'on va faire passer tous les paquets HTTP dans une couche SSL.
Tous les paquets HTTP seront donc chiffrés y compris les paramètres URL qui seront présent dans ces paquets.

Le problème de machin:user@localhost, c'est de savoir si l'authentification est gérée par le protocole HTTP(S) ou non.
D'après mon dernier message, cela semble être le cas.

Je n'ai pas de pages demandant une authentification, donc je ne peux pas trop tester directement (et j'ai autre chose à faire que de m'installer un serveur http(s) ).
En revanche, j'ai testé sur google et je n'ai vu que des paquets en TLS donc à priori, tout est bien chiffré.

Mais la meilleure façon d'en être sûr est de tester soit-même.


Attention à ne pas oublier que le mot de passe apparaîtra en clair dans l'historique du navigateur.
A voir aussi si après authentification si le mot de passe est enlevé de l'URL ou non. En effet, une personne pourrait alors lire votre de passe en regardant votre écran.

Après, oui, la solution de l'utilisation de paramètre POST permettrait de ne pas afficher le mot de passe dans votre URL sur votre navigateur et je ne pense pas que le navigateur conserve les paramètres POST dans son historique.
Par contre, il vous faudra créer un formulaire.
Après, cette méthode ne marchera pas si vous utilisez un htaccess pour authentifier l'utilisateur (je suppose que la première méthode marchera dans ce cas (?) ).

[razmous]

Bonjour,

En général, ce type de requêtes est sensé tourné sur un serveur en localhost, et donc pas d'envoi de requête à travers le réseau, Il n'y a pas de risque.
Le seul risque est lié au serveur lui même. Si quelqu'un prend la main sur le serveur, ce n'est pas l'URL qui l'empêche d'avoir le mot de passe, il est "probablement" dans les log, et d'ailleurs il a bien plus de données précieuse que ce login/mdp.

Cordialement

[abel.cain]

Bonjour,


Si les données circulent en HTTP et non en HTTPS, oui.
Mais il faut que le sniffer soit sur ton ordinateur et ai quelques droits spécifiques sous Linux (root ou appartenant au groupe wireshark (?) ).
Sous Windows, je pense qu'il faut posséder les droits administrateurs (?).

Si tu as un adversaire qui a les droits d'admin ou équivalent, tu as perdu.

Parce qu'avec les droits de super-utilisateurs je peux prendre ton identité sur le PC, c'est à dire utiliser ton compte.

Je peux utiliser ptrace sous linux, ou /proc et aller naviguer dans tes processus. Ou bien dans ceux du serveur.

Je peux utiliser kill et mettre en pause n'importe quel processus pour l'analyser, faire un dump mémoire, etc.

Idem sous Windows sauf que bien sûr l'API à utiliser est différente.

Approche alternative : avec les droits d'admin je remplace chaque programme par une version backdoorée : le navigateur Web ET le serveur Web pour faire bonne mesure!

Approche alternative : si le client HTTPS utilise seulement RSA ou DSA (et non RSA-DHE, RSA-ECDHE), je n'ai qu'à enregistrer le trafic avec tcpdump (pour équivalent) et ensuite décoder la session en utilisant la clef secrète du serveur.

Donc que tu utilises HTTP ou HTTPS, ça change les efforts à faire pour attaquer, mais pas la possibilité d'une attaque, en général.

Bien sûr, rendre une attaque plus difficile peut être ton but; n'importe qui ayant des notions élémentaire de réseau peut utiliser Wireshark pour afficher des sessions HTTP, pour attaquer du HTTPS il faut avoir un peu plus de compétences.

EDIT (pour ne pas être désagréable)

[Neckara]

Ben si tu as un adversaire qui a les droits d'admin ou équivalent, tu as perdu, hein.

J'ai bien précisé :

ou appartenant au groupe wireshark

Donc il n'a pas nécessairement tous les droits sur la machine.

J'ai aussi précisé, pour nuancer mes propos :

Une personne malveillante ayant des droits administrateur dessus pourra faire bien pire (sniffer, keylogguer, etc.)

C'est bien de répondre quelques mois plus tard, mais tu pourrais faire l'effort de lire les autres réponses plus attentivement.

[abel.cain]

J'ai bien précisé :
Donc il n'a pas nécessairement tous les droits sur la machine.

J'ai aussi précisé, pour nuancer mes propos :




C'est bien de répondre quelques mois plus tard, mais tu pourrais faire l'effort de lire les autres réponses plus attentivement.

1) Je voulais préciser les façons d'attaquer une session HTTPS en local.
2) Je n'ai pas fait attention aux dates.

Il me semble que j'ai ajouté un peu d'information sans insulter personne.

Désolé de t'avoir froissé, ce n'était pas mon but.

[Neckara]

Désolé de t'avoir froissé, ce n'était pas mon but.

Évite de "reprendre" (citer) des personnes en disant "ben, ... hein" (surtout l'insistance avec le "hein").
Le est aussi à éviter si tu ne veux froisser personne.

Si tu ne voulais froisser personne, tu aurais pu le faire de la sorte :

Une personne malveillante ayant des droits administrateur dessus pourra faire bien pire (sniffer, keylogguer, etc.)

En effet, d'ailleurs un attaquant pourrait : [...]

Là tu confirmes les dire de celui que tu cites puis tu complètes ses propos.

Alors qu'avec "ben", tu introduis déjà une logique d'opposition et avec l'insistance du "hein"... .

[abel.cain]

Évite de "reprendre" (citer) des personnes en disant "ben, ... hein" (surtout l'insistance avec le "hein").
Le est aussi à éviter si tu ne veux froisser personne.

Si tu ne voulais froisser personne, tu aurais pu le faire de la sorte :

Là tu confirmes les dire de celui que tu cites puis tu complètes ses propos.

Alors qu'avec "ben", tu introduis déjà une logique d'opposition et avec l'insistance du "hein"... .

Noté.

C'était de l'humour...