Bonjour Marc,
j'ai lu le descriptif de votre requete, et la chose qui me vient à l'esprit est : C'est pas la faute du webmail!
Il me semble que le "bug" vienne du fait que l'identifiant de session php soit passé dans la barre d'adresse, et que le fait de récupérer ce lien (adresse + php sessid) permette de retrouver les préférences (et l'identité) du propriétaire de la session.
La solution est peut etre de fermer sa session en sortant du webmail??
A suivre...
Ca me paraitrait étonnant.
cf : http://linuxfr.org/~Flyounet/12540.html(...)
C'est au webmail de ne pas transmettre adresse + php sessid dans l'adresse. La configuration sur le navigateur ne permet pas de changer ce paramètre à ma connaissance. On avait évoqué l'authentification forcée par cookie qui me semble être la seule solution.
En fait, je crois que ca vient simplement de la config de php, qui place le SID dans tous les liens de la page à renvoyer.
Cependant, il est vrai que le webmail doit assurer la sécurité des données, c'est pourquoi il devrait y avoir dans ce cas un gestion des sessions associées aux IPs correspondantes.
Ca reduirait le risque pour les personnes "externes".
Je pense tout haut là:
IMP transforme les trucs qui ressemblent à des liens http en liens http cliquables (en rajoutant <a href=...).
A l'heure actuelle, le lien en question est la copie exacte du lien du mail, si on a un mail comme ca:
Ce qui fait que quand on clique sur le lien, on passe d'abord par la page redirect.php qui n'a pas l'id de session dans les paramètres et qui redirige vers l'url passé en paramètre. Ce qui fait que le referer passé à linuxfr.org sera http://webmail.free.fr/redirect.php?url=http://www.linuxfr.org/(...) et fini les soucis...
je n'ai jamais dit que c'etait de la faute de untel ou qui que ce soit d'autre. Je pense que c'est un probleme de configuration du serveur, de Horde ou de IMP.
D'autre part j'ai vu qu'il y avait sur le site de IMP des messages de mise en garde sur les vulnérabilités des anciennes versions, je suppose que le FAI en question a fait son travail. Si ce n'est pas le cas, qu'il le fasse ou qu'il demande du renfort aupres des personnes (ou groupes) compétents.
LA solution et la seule est de ne plus gerer les sessions (php, Horde ou IMP) via les URL mais par de vrais cookies. C'est le fonctionnement par defaut de php. Pourquoi cela a été désactivé, c'est a analyser, mais je vois bien une variable de configuration dans IMP a ce sujet.
La gestion des sessions via URL n'est pas spécialement vulnérable sauf s'il y a un site dynamique avec des pages et des liens externes. Dans ce cas, le referer est transmis avec la requete HTTP. Il ne reste plus qu'aux visiteurs malicieux a mettre le code qui va bien pour profiter de cette petite vulnérabilité.
C'est généralement un lien externe ou une simple image pointant vers un script php. C'est le fameux vol de session, si je ne me trompe pas.
Je pense que cette analyse est suffisante pour que Free.fr soit en mesure de corriger rapidement ce probleme. En attendant evitez Webmail users d'avoir le clic trop rapide !
C'est le fonctionnement par defaut de php. Pourquoi cela a été désactivé, c'est a analyser, mais je vois bien une variable de configuration dans IMP a ce sujet.
Il me semble avoir lu dans un précédent journal que Free avait désactivé l'usage des cookies pour les ID de session car cela faisait trop de boulot à la hotline...
intéressant, mais certains sites utilisent le referer pour différentes raisons louables. Souvent cela peut-etre utilisé a des fin de securité, mais c'est une mauvaise idée etant donné que les requetes HTTP peuvent etre forgées.
Parfois c'est aussi utilisé dans un contexte plus technique de developpement Web. Si le clic provient de mon site, alors je fais ci ou cela en tenant compte d'un certain contexte. S'il n'y a pas de referer ou si le referer est externe, je peux effacer les variables de session (si elle existent).
donc ce workaround n'est pas la panacée, a moins de pouvoir dire que le referer n'est pas transmis dans certaines conditions.
Excuse moi, j'ai seulement webatou pour accéder au nntp depuis mon boulot. Mais as-tu eu une réponse d'un corp de Free à ton message ? Qu'ont-ils dit ? Ont ils une quelconque raison pour ne pas corriger ce problème ?
Je ne sais pas pour toi, mais pour moi, ça en dit long sur leur conscience professionelle...
Justifier de laisser une telle faille de sécu par une excuse aussi bidon que "trop de plaintes à la hotline", ca me parait surprenant.
# Webmail ou session php??
Posté par fat_cartman . Évalué à 1.
j'ai lu le descriptif de votre requete, et la chose qui me vient à l'esprit est : C'est pas la faute du webmail!
Il me semble que le "bug" vienne du fait que l'identifiant de session php soit passé dans la barre d'adresse, et que le fait de récupérer ce lien (adresse + php sessid) permette de retrouver les préférences (et l'identité) du propriétaire de la session.
La solution est peut etre de fermer sa session en sortant du webmail??
A suivre...
[^] # Re: Webmail ou session php??
Posté par lezardbreton . Évalué à 2.
cf : http://linuxfr.org/~Flyounet/12540.html(...)
C'est au webmail de ne pas transmettre adresse + php sessid dans l'adresse. La configuration sur le navigateur ne permet pas de changer ce paramètre à ma connaissance. On avait évoqué l'authentification forcée par cookie qui me semble être la seule solution.
[^] # Re: Webmail ou session php??
Posté par fat_cartman . Évalué à 1.
Cependant, il est vrai que le webmail doit assurer la sécurité des données, c'est pourquoi il devrait y avoir dans ce cas un gestion des sessions associées aux IPs correspondantes.
Ca reduirait le risque pour les personnes "externes".
[^] # Re: Webmail ou session php??
Posté par Babelouest (site web personnel) . Évalué à 3.
Et si on avait une autre solution ?
Je pense tout haut là:
IMP transforme les trucs qui ressemblent à des liens http en liens http cliquables (en rajoutant <a href=...).
A l'heure actuelle, le lien en question est la copie exacte du lien du mail, si on a un mail comme ca:
Enlarge your penis
Clic on the link below to have an enormous dick !
http ://www.linuxfr.org/
IMP le passe dans sa moulinette et donne ca:
Enlarge your penis
Clic on the link below to have an enormous dick !
<a href="http ://www.linuxfr.org/">http ://www.linuxfr.org/</a>
Et en l'occurence, le referer est la page du mail en cours avec l'id de session et le probleme de sécurité qui nous intérresse.
Et si au lieu du lien brut de décoffrage, on avait plutot:
<a href="http ://webmail.free.fr/redirect.php?url=http ://www.linuxfr.org/">http ://www.linuxfr.org/</a>
Ce qui fait que quand on clique sur le lien, on passe d'abord par la page redirect.php qui n'a pas l'id de session dans les paramètres et qui redirige vers l'url passé en paramètre. Ce qui fait que le referer passé à linuxfr.org sera http://webmail.free.fr/redirect.php?url=http://www.linuxfr.org/(...) et fini les soucis...
Qu'est-ce que vous en dites ?
[^] # Re: Webmail ou session php??
Posté par Marc Quinton . Évalué à 1.
[^] # Re: Webmail ou session php??
Posté par Babelouest (site web personnel) . Évalué à 1.
ce système est deja en place sur l'IMP que j'utilise (3.2.4)
les liens passent par la page
horde/imp/util/go.php?url=http: //prout....
[^] # Re: Webmail ou session php??
Posté par Marc Quinton . Évalué à 1.
D'autre part j'ai vu qu'il y avait sur le site de IMP des messages de mise en garde sur les vulnérabilités des anciennes versions, je suppose que le FAI en question a fait son travail. Si ce n'est pas le cas, qu'il le fasse ou qu'il demande du renfort aupres des personnes (ou groupes) compétents.
LA solution et la seule est de ne plus gerer les sessions (php, Horde ou IMP) via les URL mais par de vrais cookies. C'est le fonctionnement par defaut de php. Pourquoi cela a été désactivé, c'est a analyser, mais je vois bien une variable de configuration dans IMP a ce sujet.
La gestion des sessions via URL n'est pas spécialement vulnérable sauf s'il y a un site dynamique avec des pages et des liens externes. Dans ce cas, le referer est transmis avec la requete HTTP. Il ne reste plus qu'aux visiteurs malicieux a mettre le code qui va bien pour profiter de cette petite vulnérabilité.
C'est généralement un lien externe ou une simple image pointant vers un script php. C'est le fameux vol de session, si je ne me trompe pas.
Je pense que cette analyse est suffisante pour que Free.fr soit en mesure de corriger rapidement ce probleme. En attendant evitez Webmail users d'avoir le clic trop rapide !
[^] # Re: Webmail ou session php??
Posté par fat_cartman . Évalué à 1.
Je crois en effet que c'est la seule solution qui fonctionnera à long terme. :-))
[^] # Re: Webmail ou session php??
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 1.
Il me semble avoir lu dans un précédent journal que Free avait désactivé l'usage des cookies pour les ID de session car cela faisait trop de boulot à la hotline...
D'ailleurs, je viens de retrouver les explications: http://linuxfr.org/~Flyounet/12540.html(...) et http://blog.flyounet.net/2004/05/09/BG5dR-Insecurite-Du-Webmail-Imp(...)
th
# Workaround
Posté par philz . Évalué à 2.
Aller sur "about:config"
Chercher "referer"
Mettre 0 au paramètre "network.http.sendRefererHeader"
[^] # Re: Workaround
Posté par Marc Quinton . Évalué à 1.
Parfois c'est aussi utilisé dans un contexte plus technique de developpement Web. Si le clic provient de mon site, alors je fais ci ou cela en tenant compte d'un certain contexte. S'il n'y a pas de referer ou si le referer est externe, je peux effacer les variables de session (si elle existent).
donc ce workaround n'est pas la panacée, a moins de pouvoir dire que le referer n'est pas transmis dans certaines conditions.
# Pas de réponse ?
Posté par lezardbreton . Évalué à 2.
[^] # Re: Pas de réponse ?
Posté par Marc Quinton . Évalué à 1.
[^] # Re: Pas de réponse ?
Posté par lezardbreton . Évalué à 2.
Justifier de laisser une telle faille de sécu par une excuse aussi bidon que "trop de plaintes à la hotline", ca me parait surprenant.
[^] # Re: Pas de réponse ?
Posté par Marc Quinton . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.