• # Webmail ou session php??

    Posté par . Évalué à 1.

    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...
    • [^] # Re: Webmail ou session php??

      Posté par . Évalué à 2.

      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.
      • [^] # Re: Webmail ou session php??

        Posté par . Évalué à 1.

        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".
      • [^] # Re: Webmail ou session php??

        Posté par (page perso) . Évalué à 3.

        Et si...
        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 . Évalué à 1.

      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 !
  • # Workaround

    Posté par . Évalué à 2.

    Dans Firefox (Mozilla aussi sans doute) :

    Aller sur "about:config"
    Chercher "referer"
    Mettre 0 au paramètre "network.http.sendRefererHeader"
    • [^] # Re: Workaround

      Posté par . Évalué à 1.

      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.
  • # Pas de réponse ?

    Posté par . Évalué à 2.

    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 ?
    • [^] # Re: Pas de réponse ?

      Posté par . Évalué à 1.

      je suis un peu comme toi, interface Webatou. Cependant c'est le silence radio complet.
      • [^] # Re: Pas de réponse ?

        Posté par . Évalué à 2.

        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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.