Discussion :

[psychoBob]

Bonjour,

Pour en finir avec les histoires d'IP et de md5() dans les sessions pour empecher leurs vols par des hackers, je pose cette simple question :
Quel est votre numéro de carte bleu ?

Ouh là, non...
Disons plutot :
Pour un site non marchand avec forum, sans donnée confidentielles qui circulent, est-il utile de se blinder contre le vol de session, par exemple en vérifiant les IP ?
Est-ce un type de piratage facile et fréquent ?
Admettons que le pirate sniffe la session, il récupère l'id du membre ?
Que peux-t'il en faire ? Le fumer ?

[Jukien]

Salut,

Le principal problème des sessions est lorsque l'identifiant est transmis via l'url. En effet, en voulant donner l'adresse l'adresse d'une page à un ami, une personne peut en même temps lui donner cet identifiant, sans le vouloir, si elle ne fait pas attention. De même, j'avais été confronté à un cas similaire sur un jeu en ligne : chaque alliance disposait d'un espace personnel, dans lequel elle pouvait insérer des liens hypertextes vers des forums externes au jeu. Sur les-dits forums, des petits malins récupéraient le référer, ce qui leur permettaient de se connecter sous le compte de leur victime.


En revanche, lorsque cet identifiant est transmis par cookie, le vol de session est beaucoup plus compliqué, et peut donc être considéré comme très peu probable sur un site ordinaire.

[psychoBob]

Bon tu es le deuxième à me parler de ce problème, ça doit donc être assez fréquent.
Mais je ne vois pas trop comment ça peut se passer :
Le gars est identifié, il fait un copier coller du lien dans la barre d'adresse et l'envoie dans l'email. Je ne vois pas comment les variables de sessions peuvent être envoyées aussi, puisqu'elles sont masquées dans l'url.

Cela étant dit, mis à part ce problème et sachant que mes variables de sessions sont dans l'url, est-il très important de se prémunir contre le vol de sessions ?

[HuZimA]

Salut

que dire...

le criptage MD5 et je pense un minimum, certaine personne utilise les même mot de passe partout on il vont...

Pour ce qui est du vole de session sur ton site, si il sagit d'un forum ou de quoi que ce soit ou le client peut mettre quelque chose, ce qu'il faut savoir c'est qu'un voleur peut s'amuser a porter prejudice a quelqu'un envers une autre personne en insultant, rependant des rumeur et autre sous une fausse identité, sinon rien de bien mechant, mais parfois c'est deja pas mal

bye

[psychoBob]

D'accord, mais en pratique, ça arrive souvent ?

[Gwipi]

D'accord, mais en pratique, ça arrive souvent ?

A mon avis ça dépend du thème du site déjà.
Ensuite en pratique, moi j'ai jamais eu de problème.
J'ai mis en place un système de véri par IP et USER AGENT + suivi en cas de "intrusion" et du coup je me suis retrouvé avec plein de membre qui ne pouvait plus accéder au site. Donc j'ai arrété cette vérification.

[psychoBob]

J'ai mis en place un système de véri par IP et USER AGENT + suivi en cas de "intrusion" et du coup je me suis retrouvé avec plein de membre qui ne pouvait plus accéder au site. Donc j'ai arrété cette vérification.

Ah et bien justement, je viens de mettre en place un système de vérif par IP et je craignais que cela pose problème, par exemple pour les gens qui ont aol, ou des proxys faisant de sorte que les IP changent durant la connexion.

Et toi tu dis que tu as eu des problèmes à cause de cela... Quand tu dis "plein de membres" c'est 1% ou 20 % ? C'est quoi une vérif par USER AGENT ?

Pour mon site c'est juste un forum, avec prochainement des pages perso.

[nicolas.bui]

ben c comme le tracking IP sauf que l'User Agent tu track le navigateur utilisé.

par exemple l'user Rocco () se connecte sur ton site marchant avec FireFox 1.5 avec l'IP 210.15.50.10.

Bien son user agent contiendrais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8) Gecko/20051111 Firefox/1.5

Plus d'exemple ici : http://fr.wikipedia.org/wiki/User-Agent

Cela peut constituer une deuxieme protection en effet a condition que le voleur n'utilise pas le meme navigateur.

[psychoBob]

ça pose manifestement bcp de problèmes.

(merci pour le lien)

[if_zen]

Moi ce que je comprends pas, c'est qu'en php je gere tres bien mes sessions, et elles ne sont pas pour autant transmises dans l'url... Je dois avoir un cookie phpsessid qui doit trainer quelque part, peut-etre, mais je vois pas comment on peut se le faire voler...
Enfin bref, je me contente de <? session_start(); ?>
puis de quelques <? $_SESSION['id']='...'; ?>
Enfin, je vois pas ou est le problème en fait, tout est géré de façon invisible

[Kioob]

Je ne vois pas comment les variables de sessions peuvent être envoyées aussi, puisqu'elles sont masquées dans l'url.

aïe... Petit rappel : le navigateur à chaque page ré-envoye l'identifiant de session qu'on lui a fourni (que ce soit par URL, par cookie ou par formulaire). Avec cet identifiant, PHP retrouve un fichier sur le serveur qui lui contient toutes les variables de session.

Donc :
- les variables de sessions sont stockées sur le serveur, et uniquement sur le serveur... après tout, ça sert à ça
- l'identifiant de session suffit à se procurer la session, rien d'autre. A partir du moment où cet identifiant est volé, le "pirate" est associé à la même session.

En tous cas, que ce soit l'IP ou le User_Agent ou tout autre information HTTP, ce n'est pas fiable. Tu auras toujours de vrais visiteurs qui passent par un proxy ou routeur, et pour qui ce genre d'infos peut régulièrement changer.


D'après moi il n'y a que quelques méthodes vraiment efficaces :
- SSL : pas de miracle... le SSL n'a pas été inventé pour faire joli...
- vérifier la durée de session. En effet PHP ne la vérifie pas, et le fichier de session n'est pas forcément effacé après les fameuses 24 minutes... du coup un pirate peut avoir quelques heures pour intervenir... C'est donc tout con, mais intégrer cette petite vérification dans le script PHP limite considérablement la durée du risque.
- changement régulier de l'ID de session : si l'ID de session change à chaque page, le temps qu'un pirate tente de s'en emparer il sera sûrement trop tard : la session correspondante aura été détruite. (attention toutefois, avec PHP 4 la fonction session_regenerate_id() conserver l'ancienne session... aucun intérêt, mais c'est comme ça)



PS : tout ça a déjà longuement été débatu : http://www.developpez.net/forums/showthread.php?t=12254

[Kioob]

Enfin, je vois pas ou est le problème en fait, tout est géré de façon invisible

Oui PHP se charge de tout. Sauf de la sécurité...

C'est lui qui envoit le cookie de session à chaque fois que tu appels session_start(). Et lorsque le "trans_sid" est activé, tant que PHP ne reçoit pas de cookie de session (ce qui est forcément le cas de le première page), PHP ira jusqu'à modifier le code HTML généré pour modifier les liens et formulaires...
Si l'internaute désactive les cookies, il y a donc un "gros" risque concernant la sécurité.

[psychoBob]

ok,

Petit rappel : le navigateur à chaque page ré-envoye l'identifiant de session qu'on lui a fourni (que ce soit par URL, par cookie ou par formulaire). Avec cet identifiant, PHP retrouve un fichier sur le serveur qui lui contient toutes les variables de session.

Ne me dit pas que l'id de session est transmis par un simple copier coller d'une url dans laquelle il est masqué. Donc comment peut refiler par inattention sont id de session à quelqu'un ?

En tous cas, que ce soit l'IP ou le User_Agent ou tout autre information HTTP, ce n'est pas fiable. Tu auras toujours de vrais visiteurs qui passent par un proxy ou routeur, et pour qui ce genre d'infos peut régulièrement changer.

Oui, je viens d'enlever ce système.

D'après moi il n'y a que quelques méthodes vraiment efficaces :
- SSL : pas de miracle... le SSL n'a pas été inventé pour faire joli...
- vérifier la durée de session. En effet PHP ne la vérifie pas, et le fichier de session n'est pas forcément effacé après les fameuses 24 minutes... du coup un pirate peut avoir quelques heures pour intervenir... C'est donc tout con, mais intégrer cette petite vérification dans le script PHP limite considérablement la durée du risque.
- changement régulier de l'ID de session : si l'ID de session change à chaque page, le temps qu'un pirate tente de s'en emparer il sera sûrement trop tard : la session correspondante aura été détruite. (attention toutefois, avec PHP 4 la fonction session_regenerate_id() conserver l'ancienne session... aucun intérêt, mais c'est comme ça)

- Je n'ai encore jamais vu un forum fonctionnant sous ssl, même si s'est évidemment le mieux.
- Vérifier la durée de session : effectué (temps maxi fixé à 30 mn, est-ce trop ?)
- Changement régulier de l'ID de session : peut être intéressant, mais je ne sait pas comment faire. Quand le gars s'identifie, je crée une variable de session contenant son ID et bien sur il y a session_start() en haut de chaque page. Mais comment au juste régénérer l'id...

PS : tout ça a déjà longuement été débatu : http://www.developpez.net/forums/showthread.php?t=12254

Oui j'ai lu le thread, même plusieurs fois (merci pour le lien tout de même). Mais on a toujours besoin d'explications particulières pour son propre problème.

[if_zen]

ah tiens... J'avais jamais fait attention à ça... J'irai me renseigner sur google pour + d'info ça m'intrigue Merci

[Kioob]

Ne me dit pas que l'id de session est transmis par un simple copier coller d'une url dans laquelle il est masqué. Donc comment peut refiler par inattention sont id de session à quelqu'un ?

Bah justement avec le "trans_sid" l'ID de session est clairement visiblement dans l'URL. D'où un plus grand risque.
Sinon de manière générale, cet ID de session est transféré en clair sur le réseau... et peut donc _théoriquement_ être volé.

Typiquement en entreprise un collègue peut facilement le faire, si le réseau utilise des HUB et non des switch (déjà vu, chez France Telecom entre autre). Chez certains hebergeurs, un autre client peut sûrement en faire autant.

- Je n'ai encore jamais vu un forum fonctionnant sous ssl, même si s'est évidemment le mieux.

Forcément Après il faut évaluer le niveau de sécurité voulu par rapport au risque encouru...

- Vérifier la durée de session : effectué (temps maxi fixé à 30 mn, est-ce trop ?)

Tout dépend du site... pour un forum, il peut y avoir beaucoup de texte à lire, et dans ce cas 30 minutes n'est pas éxagéré non.

- Changement régulier de l'ID de session : peut être intéressant, mais je ne sait pas comment faire. Quand le gars s'identifie, je crée une variable de session contenant son ID et bien sur il y a session_start() en haut de chaque page. Mais comment au juste régénérer l'id...

http://at.php.net/manual/fr/function...enerate-id.php

Mais comme l'indique la DOC, le paramêtre "delete_old_session" n'a été ajouté que dans PHP 5.1.0... du coup il faut supprimer manuellement l'ancien fichier de session.

[psychoBob]

Je me permet de préciser que j'ai ouvert un post ici, au sujet d'un problème avec session_regenerate_id(). Si quelqu'un a l'amabilité d'y jeter un oeil...
Vu que ça me semble être une solution convenable pour cette histoire de vol de session et compte tenu de l'enjeu (un simple forum avec pages persos).