[Cookies] C'est quoi un vol de session ? [Résolu]

[psychoBob]

Bonjour,

Je me prend la tête a essayer de réaliser un système de session et il s'avère que tout ce que je fais à ce sujet est bidon pour une raison qui m'apparait subitement éblouissante : Je ne sais pas ce qu'est un vol de session.


Alors s'il vous plait, comment fait le hacker et surtout qu'est ce qu'il peut faire ?
Est-il obligé de commettre son forfait pendant que le membre est connecté, ou son vol peut encore lui profiter ensuite ?

Bref qu'est ce que vous pouvez me dire en gros, en détail et en approfondi sur ce sujet, s'il vous plait ?

[Swoög]

Pour conserver une session d'une page à l'autre, il faut transmettre le numéro de session (SID)

si un pirate arrive à récupérer le session_id, il peut prendre possession de la session, c'est à dire qu'il peut faire croire au serveur que c'est lui qui est le propriétaire de la session, de ce fait, le serveur réagira comme si c'était le client légitime qui se connectait au site.

[psychoBob]

Bon ça j'avais compris, merci Swoög.

Maintenant le numéro de session ne sert à rien en soit, si ce n'est qu'il permet de s'accaparer les variables qui circulent dans la session correspondant à cet id, c'est ça ?

J'ai bon sur ça déjà ?

Si oui, une fois le membre déconnecté, le pirate n'a plus rien sous la dent, si ce n'est les éventuelles variables qu'il a récolté (mot de passe si on est c.., pseudo, ou identifiant etc...) , c'est ça ?

[Eusebius]

Envoyé par psychoBob

mot de passe si on est c...

Bah, s'il est capable de sniffer un id de session, il peut aussi bien sniffer directement le login et le mot de passe (en cas de connexion non chiffrée).

Tu peux rajouter des éléments dans la session qui permetterons de vérifier si l'utilisateur utilisant celle-ci est bien la bonne personne.
du genre tu enregistre l'adresse Ip et la version du navigateur du visiteur, et tu fait une fonction qui permet de tester si l'ip du visiteur et la version de son navigateur est egale aux données enregistrer dans la session, si non, dans ce cas c'est pas l'utilisateur attendu.

[psychoBob]

Envoyé par Eusebius

Bah, s'il est capable de sniffer un id de session, il peut aussi bien sniffer directement le login et le mot de passe (en cas de connexion non chiffrée).

Ah voilà qui s'approche d'une de mes interrogation:

Contrairement à une session qui perdure dans le temps, la transmission du login et du pass se fait une seule fois et très vite. Donc comment fais le pirate, il guète ? Il aspire tout ce qui transite sur le site indistinctement ? Ou il cible un membre, ou une connexion précise ? Il sniffe quoi d'ailleur ? Ce qui circule entre le site et un pc ? Donc il récupère les informations d'une session que pour un membre c'est ça ?

[psychoBob]

Envoyé par Fabouney

Tu peux rajouter des éléments dans la session qui permetterons de vérifier si l'utilisateur utilisant celle-ci est bien la bonne personne.
du genre tu enregistre l'adresse Ip et la version du navigateur du visiteur, et tu fait une fonction qui permet de tester si l'ip du visiteur et la version de son navigateur est egale aux données enregistrer dans la session, si non, dans ce cas c'est pas l'utilisateur attendu.

Oui mais ça j'ai ouvert des posts sur le sujet et la plupart on dit que c'était bidon, car vu que les IP change pour beaucoup de monde en cours de connexion (utilisateurs d'aol, proxy etc...) et vu que les informations du navigateurs ne sont pas fiables pour je ne sais plus quelle raison et bien en bout de course c'est hyper contraignant et ça gène tellement d'utilisateurque ça devient nul.

De toute façon c'est pas un post sur comment se protéger du vol de session, j'ai résolu le problème : c'est HTTPS le reste c'est du flan.
Mais je veux quand même comprendre en détail, si possible, ce qu'est un vol de session.

[Kioob]

Dans le cas d'un sniffer chez un hébergeur par exemple, le pirate "pourrait" voir tout le trafic arrivant sur la machine. Dans ce cas des outils particuliers permettent d'isoler les flux HTTP, puis de filtrer sur ce qui nous interesse ici, c'est à dire un couple login/pass envoyé une seule fois en POST, ou bien un identifiant de session en cookie. Mais selon le contexte, rien ne dit qu'il aura accès longtemps au trafic circulant.


Et comme tu le faisais remarqué plus haut, un login / pass ne va théoriquement circuler qu'une seule fois. Et est donc plus difficile à chopper.

Par contre l'ID de session va circuler à chaque hit HTTP sur le site (donc y compris pour les images, la CSS, les scripts JS, etc). Il est généalement valable "au moins" 24 minutes, et sa suppression étant alléatoire, ça peut même durer bien plus longtemps : même après le "départ" de l'internaute s'il n'y a pas (ou s'il ne l'utilise pas) pas de fonction "se déconnecter" qui détruirait la session. Et si le visiteur reste 2 heure à consulter le site, cela laisse un large créneau au pirate.
Le pire c'est que ceci est proportionnel à la durée de validité de la session : dans le cadre d'une "application intranet" il n'est pas rare de voir des sessions de 2 heures par exemple (pas forcément justifié d'ailleurs).


D'où l'intérêt d'un mécanisme pour se protéger de ça : essayer de limiter la durée de validité d'un même ID de session. Ainsi si on vérifie via PHP la durée de la session, on s'assure que cela ne s'éternisera pas au delà du temps souhaité (les fameuses 24 minutes de départ).
De plus, si à chaque nouvelle page, on change l'ID de session (ou un équivalent), le délai de validité de cet identifiant peut être réduit à quelques minutes, voir quelques secondes : cela améliore les choses, mais ne résoud pas non plus le problème. Il y aura toujours un petit créneau pendant lequel le vol sera possible.


Reste le risque dans le cas où l'internaute part sans détruire la session : celle ci est donc valide durant 24 minutes par exemple. Mais l'avantage c'est que l'ID de session n'apparait plus dans le trafic. Donc à moins d'avoir choppé le bon paquet au bon moment, le risque n'est pas énorme.


Bien sûr tout ceci est valable dans le cas d'un identifiant de session en cookie. S'il est dans l'URL, c'est bien pire, car on va aussi le retrouver dans le REFERER de tous les liens externes...

Bah c'est tout simple, à partir du moment ou des informations sont véhiculées sur le reseaux, du genre une session id qui dialogue entre serveur et client, est passible d'être intercepté par un individu, en effet le SSL est une solutions à beaucoup de problèmes de ce genre lol.

[Kioob]

Note : j'ai oublié de parler des "conséquences"

Donc, comme dit plus haut, la _seule_ conséquence, c'est que pour le site le pirate est le propriétaire de la session. Donc s'il s'agissait de l'administrateur du site, le pirate a donc accès aux mêmes fonctions que l'administrateur. Mais évidement il n'a absolument pas la possibilité de lire ce que contient la session : le mot de passe pourrait y être stocké que ça ne changerait rien pour lui (1).

Un bon moyen de se prémunir des "gros" risques, c'est de redemander le mot de passe pour les actions "graves" (genre suppression du compte d'un client par exemple ).


(1) : s'il ne faut pas mettre de mot de passe dans la session, c'est plutot pour éviter que si quelqu'un (un autre client de l'hébergeur par exemple) a un accès en lecture au fichier, ce serait domage qu'il puisse en tirer quoi que ce soit.

[psychoBob]

Top réponse, merci Kioob (oui oui les autres aussi ).

Perso j'ai placé un temps d'inactivité maximum de 15 minutes, au bout de ce délais, l'id de session est régénérée dans la base dès que le membre essaie de se reconnecter.
Je vais voir pour changer l'id de session à chaque page, c'est bien aussi (j'ai bazardé mon autre système avec deux id c'était bidon).

Bien sûr tout ceci est valable dans le cas d'un identifiant de session en cookie. S'il est dans l'URL, c'est bien pire, car on va aussi le retrouver dans le REFERER de tous les liens externes...

- C'est quoi déjà la fonction pour obliger les sessions à être stockées dans les cookies ? Parce qu'en plus ça m'éviterait d'avoir des id de session qui apparaissent puis disparraissent, je n'ai pas encore résolu le problème (je suis sur 10 trucs à la fois).

- une autre question aussi : php peut il générer deux id de session similaires existant en même temps ? Parce que je génère des md5() mais s'ils sont pareil (je sais c'est quasi impossible) entre deux membres, bonjour les dégats. Donc mieux vaut peut être prendre l'id de session pour l'envoyer dans la base en remplacement de l'id du membre, plutot qu'un md5().
Ce qui ne sert strictement à rien au demeurant quand j'y pense, puisque si le pirate choppe la session, il choppe le pseudo et comme celui ci est toujours le même, ça fait le même office qu'un numéro d'id pour une requête sql avec clause where.

[psychoBob]

Donc, comme dit plus haut, la _seule_ conséquence, c'est que pour le site le pirate est le propriétaire de la session.

Mais jusqu'à quand alors ? Uniquement tant que le membre est connecté ?

Mais évidement il n'a absolument pas la possibilité de lire ce que contient la session : le mot de passe pourrait y être stocké que ça ne changerait rien pour lui (1).

Ah bon c'est nouveau ça, j'ai vraiment pigé que dalle alors.

Un bon moyen de se prémunir des "gros" risques, c'est de redemander le mot de passe pour les actions "graves" (genre suppression du compte d'un client par exemple ).

Oui j'y avais pensé c'est bien ça. Mais si le pirate à chopé la session une fois, qu'est ce qui l'empêche d'être aux aguets pour recapter le mot de passe ?

[Kerod]

Ta première question je suis sur que c'est bon lol :
Ca dure le temps de vie de la session...donc même si le proprio est déconnecté le pirate peut toujours l'être car il possède l'id de session. Alors les autres c'est vrai ce que je dis (lol on sait jamais)

La deuxième là j'en suis pas sur :
Pour récupérer les infos (vu qu'elles sont stockés serveur ) il faudrait qu'il connaissent le nom des variables...donc s'il les connait pas comment il fait ?? . Sauf si la session est contenu dans une table comme les forums phpbb...

la troisième question : eh oui c'est un risque et c'est pour ca que l'on demande souvent de changer les pass et etc...

[Kioob]

Envoyé par psychoBob

Top réponse, merci Kioob (oui oui les autres aussi ).

De rien Ce qui serait bien c'est de faire une compilation de tout ce qui a été dit dans tes divers sujets, histoire de ne pas avoir à tout répéter la prochaine fois.

Perso j'ai placé un temps d'inactivité maximum de 15 minutes, au bout de ce délais, l'id de session est régénérée dans la base dès que le membre essaie de se reconnecter.

mm, j'ai peur de ne pas comprendre ce que tu veux dire là. Sur mes sites, quand le temps d'inactivité dépasse le délai voulu, je détruis la session, et en recrée une autre "vierge" si besoin.

Je vais voir pour changer l'id de session à chaque page, c'est bien aussi (j'ai bazardé mon autre système avec deux id c'était bidon).

bah comme on en a déjà longuement discuté, le session_regenerate_id() est difficilement exploitable avant PHP 5.1...

- C'est quoi déjà la fonction pour obliger les sessions à être stockées dans les cookies ? Parce qu'en plus ça m'éviterait d'avoir des id de session qui apparaissent puis disparraissent, je n'ai pas encore résolu le problème (je suis sur 10 trucs à la fois).

Il s'agit de paramêtres de PHP : session_use_cookies et session_use_only_cookies. Par contre dans ce cas tes "membres" devront obligatoirement accepter les cookies.

- une autre question aussi : php peut il générer deux id de session similaires existant en même temps ? Parce que je génère des md5() mais s'ils sont pareil (je sais c'est quasi impossible) entre deux membres, bonjour les dégats. Donc mieux vaut peut être prendre l'id de session pour l'envoyer dans la base en remplacement de l'id du membre, plutot qu'un md5().

C'est tellement peu probable que ça ne vaut pas la peine que tu t'en préoccupes à mon avis.

Sache également que certains navigateurs (IE...) bloquent les cookies trop longs, ou plutot "le total des cookies du site", donc dépasser les quelques 32 caractères du MD5 pourrait devenir génant.

Ce qui ne sert strictement à rien au demeurant quand j'y pense, puisque si le pirate choppe la session, il choppe le pseudo et comme celui ci est toujours le même, ça fait le même office qu'un numéro d'id pour une requête sql avec clause where.

Oui, comme je te l'ai déjà dit (oui oui ), une des seules contraintes de l'identifiant de session est qu'il ne doit pas être prédictible. Donc s'il est fixe pour un utilisateur, ça ne sert à rien.

Envoyé par psychoBob

Mais jusqu'à quand alors ? Uniquement tant que le membre est connecté ?

Jusqu'à ce que la session soit détruite.

Généralement elle n'est détruite que dans ces 2 cas là :
- si un script fait un session_destroy(). Le soucis : bah ce n'est pas automatique...
- si le "garbage collector" de PHP se déclenche et que le fichier de session a plus de 24 minutes (ce temps est configurable, dans le php.ini). Le hic : il se déclenche de manière tout à fait alléatoire.

=> elle peut donc être valable très très longtemps.

J'ajoute au passage 2 autres cas "plus ou moins fréquents" :
- dans le cas où les sessions sont stockés via le moteur de session d'eaccelerator, un reload ou restart d'Apache purge toutes les sessions
- sous Debian un cron est lancé régulièrement pour effacer les fichiers de session "trop vieux" (bon en pratique le dossier de session étant différent pour chaque virtual host, le script ne marche pas)

Ah bon c'est nouveau ça, j'ai vraiment pigé que dalle alors.

bah essaye par toi même : à moins que ton script fasse un "print_r( $_SESSION )", il n'y a aucun moyen pour le propriétaire d'une session (même légitime hein) d'en voir le contenu. Le but des sessions c'est justement ça à la base : cela permet une conservation des données de page en page de manière "sécurisé" (bien plus que les cookies en tous cas).

Oui j'y avais pensé c'est bien ça. Mais si le pirate à chopé la session une fois, qu'est ce qui l'empêche d'être aux aguets pour recapter le mot de passe ?

Comme déjà dit :
*) de part le fait que le login et le mot de passe ne circulent qu'une seule fois, les chopper "au bon moment" est quand même plus difficile que de chopper un cookie qui circule à _chaque_ hit HTTP. Oui oui j'insiste : sur une page qui contient une cinquantaine de "fichiers externes" (favicon, images, css, js, flash, etc), le cookie sera envoyé cinquante fois... et idem à la page suivante.

*) rien ne dit que le pirate a un accès en continue au trafic du site. Parce que si c'est vraiment le cas, il n'y a que le SSL qui pourra te protéger.
Histoire d'en remettre une couche : les identifications HTTP (ce qu'utilisent les fichiers .htaccess par exemple), bah c'est comme les cookies, ça circule à chaque hit HTTP... sauf que contrairement à un ID de session, là c'est un couple login+password qui circule en clair sans arrêt
Et beaucoup de personnes utilisent ça... alors que c'est certainement la moins fiable des méthodes...

[psychoBob]

De rien Ce qui serait bien c'est de faire une compilation de tout ce qui a été dit dans tes divers sujets, histoire de ne pas avoir à tout répéter la prochaine fois.

C'est à dire qu'à chaque fois c'est répété dans un contexte imperceptiblement différent pour le lecteur non motivé autant que moi par mes posts, cette différence imperceptible symbolisant l'évolution progressive de ma compréhension du sujet au fil des questions.

Perso j'ai placé un temps d'inactivité maximum de 15 minutes, au bout de ce délais, l'id de session est régénérée dans la base dès que le membre essaie de se reconnecter.

mm, j'ai peur de ne pas comprendre ce que tu veux dire là. Sur mes sites, quand le temps d'inactivité dépasse le délai voulu, je détruis la session, et en recrée une autre "vierge" si besoin.

En fait si le gars reste plus de 20 minutes (j'ai mis 20 maintenant) sans activité et qu'il change de page ou réactualise, il est déconnecté. En même temps le script qui déconnecte change le numéro de connexion dans la base, car à l'identification je génère un numéro de connexion qui est updaté à chaque nouvelle page.

bah comme on en a déjà longuement discuté, le session_regenerate_id() est difficilement exploitable avant PHP 5.1..

Non comme j'ai dit juste avant je n'utilise pas cette méthode. Quand le gars s'identifie je lui attribue un md5() que j'envoie dans la base et que je passe en session. A chaque page j'update ce md5() dans la base et dans la session pour qu'il reste le même dans les deux cas. Pour les formulaires de forum, je vais chercher dans les informations qui correspond au membre dans le md5() dans le champ numero_Connexion correspond à celui en session.
D'ailleur au moment où j'écris ça je me demande si ça sert à quelque chose puis que si le pirate chope la session, il va updater le champs numero_Connexion et le membre ne pourra plus poster mais le pirate si. J'ai raison ? Auxquel cas je suis bon pour reprendre mon ancien système : si les deux numéros ne correspondent pas, je déconnecte et j'utpdate le numéro dans la table pour que celui du pirate ne corresponde plus à son tour.
Si ça ne marche toujours pas comme ça je me casse, je passe en SSL.

Il s'agit de paramêtres de PHP : session_use_cookies et session_use_only_cookies. Par contre dans ce cas tes "membres" devront obligatoirement accepter les cookies.

Bon bah j'indiquerai un message.

[Kioob]

Non comme j'ai dit juste avant je n'utilise pas cette méthode. Quand le gars s'identifie je lui attribue un md5() que j'envoie dans la base et que je passe en session. A chaque page j'update ce md5() dans la base et dans la session pour qu'il reste le même dans les deux cas. Pour les formulaires de forum, je vais chercher dans les informations qui correspond au membre dans le md5() dans le champ numero_Connexion correspond à celui en session.
D'ailleur au moment où j'écris ça je me demande si ça sert à quelque chose puis que si le pirate chope la session, il va updater le champs numero_Connexion et le membre ne pourra plus poster mais le pirate si. J'ai raison ? Auxquel cas je suis bon pour reprendre mon ancien système : si les deux numéros ne correspondent pas, je déconnecte et j'utpdate le numéro dans la table pour que celui du pirate ne corresponde plus à son tour.

Bon... je vais prendre un exemple :
- l'internaute A arrive sur ton site, il obtient la session 9.
- l'internaute A s'identifie, ton script le note en session. Dans la session 9, il est donc indiqué "login = dupont".
- l'internaute B arrive sur ton site, et pour une raison inconnue il fourni l'ID de la session "9".

A partir de là, pour PHP, que ce soit l'internaute A ou l'internaute B, le résultat est le même : il s'agit de la session 9, et donc de l'utilisateur "dupont". Tu peux donc faire tous les croisements que tu veux entre cette session et la base de données que ça ne changera rien : chaque modification faite dans la base de données ou dans la session profite simultanément aux deux internautes.

Ce n'est pas le lien entre la session et la base de données qui est piraté, mais le lien entre l'internaute et la session.
C'est pour cela qu'on essaye de coupler l'ID de session avec une autre info provenant de l'internaute (IP, version de navigateur, autre cookie, etc).

Pour ma part j'ai opté pour une solution par cookie, qui me semble fiable :
http://www.developpez.net/forums/sho...8&postcount=34

[Eusebius]

Envoyé par psychoBob

(j'ai bazardé mon autre système avec deux id c'était bidon).

Tout arrive

[psychoBob]

Tu peux donc faire tous les croisements que tu veux entre cette session et la base de données que ça ne changera rien : chaque modification faite dans la base de données ou dans la session profite simultanément aux deux internautes.

Ce n'est pas le lien entre la session et la base de données qui est piraté, mais le lien entre l'internaute et la session.
C'est pour cela qu'on essaye de coupler l'ID de session avec une autre info provenant de l'internaute (IP, version de navigateur, autre cookie, etc).

Voilà j'y vois plus clair et justement je me disais que je ne faisais pas la différence entre l'id de session et la variable attribuée au membre en guise d'identifiant à la place de son id, qui me semble donc à peu près complètement inutile.
Une astuce serait de régénérer non pas l'id attribué au membre durant la session, mais donc bien l'id de session lui même.
Mais je n'ai pas accès à session_regenerate_id.
Est-il possible d'attribuer un numéro de session soit même et de la changer à chaque page, en modifiant celui créé par md5().
Par exemple une conn.... du genre :

Code :

1
2
3
 
session_start()
session_id=md5(time);

Pour ma part j'ai opté pour une solution par cookie, qui me semble fiable :
http://www.developpez.net/forums/sho...8&postcount=34

J'ai zyeuté, c'est pas facile à piger pour pas qui utilise pas les fonctions, faudra que je m'y mette un jour quand même. Je voudrais bien savoir si ma question juste avant peut trouver une réponse positive.

[wamania]

Une astuce serait de régénérer non pas l'id attribué au membre durant la session, mais donc bien l'id de session lui même.
Mais je n'ai pas accès à session_regenerate_id.
Est-il possible d'attribuer un numéro de session soit même et de la changer à chaque page, en modifiant celui créé par md5().

En créant un deuxiéme id de session ( le système bidon des 2 id de session )
Le but est de vraiment le créer soit meme, mais dans les memes conditions que id_session de PHP et de considérer le couple.
Cet id ressemble à celui de PHP:
1 enregistré coté serveur (PHP écrit le sien dans un fichier, mais tu peux laisser le tien en session) et 1 en cookie (ou par url si cookie refusé).
Puis tu fais une fonction regenerate_id pour ton id_session maison
La session sera valide si le couple d'id est valide.

[Kioob]

wamania : c'est exactement ce que j'ai fait dans le bout de code cité ci dessus, avec toutefois la gestion des accès concurrents.