Discussion :

[ixabro]

Bonjour,

je suis sûr qu'on vous a déja posé ce genre de questions, mais je tente toujours, biensur j'ai lu le FAQ avant posté sur ce forum. Mais celui ci n'a pas répondu à mes questions. Je me tourne alors vers vous developpiens.

Alors voilà, quand on créait une variable session : $_SESSION[X] = x, une id session est générée et disposée dans un cookie (à ce que j'ai cru comprendre).
Nous avons aussi à notre disposition la fonction session_generate_id() pour re-générer une nouvelle id de session. Cette fonction serait à placer après le session_start() de chaque page.

Je me pose le problème suivant :
Admetons qu'un attaquant A se soit approprié le cookie de la victime B. Si l'id de session ne change pas, A dispose des droits de B. Mais si l'id session change à chaque page alors A ne les possède plus. Justement là je ne sais vraiment si ça se passe ainsi.

Sinon j'aimerai comprendre ceci : ademettons, nous créons la variable session : $_SESSION[A] = a en $_SESSION[B] = a | notre id de session changerait ? Quel serait l'interet de changer le nom de session cela serait il être interessant pour la sécurité?

Ces notions de sécurité sessions sont un peu flou pour moi, veuillez m'en excuser.

Merci de lire mon post, en attentes de vos réponses.

[alain31tl]

Slt
Aucun intérêt de changer l'id de session, tout du moins dans ce cas de figure.
Soit tu utilises les cookies, soit les sessions php.

Dans le dernier cas, les variables de sessions sont enregistrées sur le serveur distant (domaine), et accessibles et/ou disponibles seulement depuis le navigateur de l'utilisateur , et ce, tant que ce dernier n'est pas fermé.
Par conséquent, je ne vois pas où est le probléme, ou les risques ?

C'est fait pour ça les sessions.

Note que j'ai mis en gras "seulement".

[sabotage]

seulement depuis le navigateur de l'utilisateur , et ce, tant que ce dernier n'est pas fermé.

Non : le lien entre l'utilisateur et la session est réalisée par l'id de session.
Plusieurs ordinateurs différents peuvent accéder à la même session en même temps tant qu'ils indiquent au serveur le meme id de session.
D'ou la possibilité de "vol de session" dont parle ixabro.

En fait il n'est pas nécessaire de changer l'id tout le temps mais seulement quand l'utilisateur change de droits.
Si notre pirate arrivait a deviner l'id courant d'un utilisateur, c'est le premier des deux qui interrogerait une page qui deviendrait le seul propriétaire de la session.

[alain31tl]

Plusieurs ordinateurs différents peuvent accéder à la même session en même temps tant qu'ils indiquent au serveur le meme id de session.
D'ou la possibilité de "vol de session" dont parle ixabro.

Slt
Je crée une session, elle est identifiée par un id de session.
Le serveur renvoie ces variables sur mon navigateur, sur mon pc.

Comment un autre utilisateur depuis un autre pc et un autre navigateur peut-il utiliser le même id. (?)

Si c'est possible, j'abandonne illico les sessions php.

[grunk]

Comment un autre utilisateur depuis un autre pc et un autre navigateur peut-il utiliser le même id. (?)

Avec une faille Xss par exemple. Un petit bout de js et op je reçoit l'identifiant de session stocké dans le cookie du mec qui aura cliqué sur la page infectée.

Encore plus simple , les serveur ou le SID est visible dans l'url. C'est très fréquent de voir des gens qui poste un lien avec à la fin PHPSESSID=azertyuiop.

[ixabro]

En effet mais là n'est pas la question. Justement la vérification constante des formulaires et autres se charge de veuiller à ce qu'aucun caractère spécial soit utilisé etc...
Sinon c'est l'arrivée en masse des failles XSS, CSS etc...
Je ne parlais pas vraiment de cela ...

Je voulais juste savoir si il y avait une stratégie pour éviter le vol session ou une manoeuvre d'un visiteur/utilisateur malvaillant qui pourrait être un problème à l'égard des autres membres du site.

En effet l'id de session d'un utilisateur B peut être volé à son inssue par un attaquant A.
Voilà où est mon problème, c'est extrèmement dérangant de savoir que A peut se connecter en tant que B et modifier des paramètres du profils etc... mot de passe aie ...
Peu importe les permissions comme me l'a fait remarqué Sabotage, si un utilisateur se retrouve sans possibilité de rentrer sur son compte... ça fait mal.

D'ailleurs je me demande comment il peut se connecter au site avec une id de session et un login... il ne faut pas aussi le mot de passe ? L'id permetterait d'outre passer cette attente ?

Sinon j'aimerai être sur de ceci :

$_SESSION['A'] et $_SESSION['B], ces deux sessions ont des id différentes sachant que chacune d'elle n'est pas lancée en même temps.

C'est à dire : connection 1 : -> $_SESSION[A] = ....
conncetion 2 : -> $_SESSION[B] = ....

Pour ces deux connections l'id session sera différente ou non ?

----------------

Sinon j'aimerai savoir si avec la fonction session_regenerate_id() on peut se tirer de quelques problèmes ? Cela sert il vraiment ou cette fonction ne désavantage pas les attaquant ?

Si j'en crois la fonction php, comment peut on voler l'id si elle change ... tout ceci est un peu flou.

[sabotage]

$_SESSION['A'] et $_SESSION['B] sont deux entrées dans la meme session.

comment il peut se connecter au site avec une id de session et un login... il ne faut pas aussi le mot de passe ? L'id permetterait d'outre passer cette attente ?

Dans le cas de fixation de session c'est l'utilisateur qui aura saisie son mot de passe, le pirate utilise la session parallelement à l'utilisateur une fois que celui-ci est connecté.
session_regenerate_id() permet d'eviter cette "fixation de session".
On peut egalement controler que l'ip ou même le navigateur de l'utilisateur ne changent pas en cours de route.

[alain31tl]

Encore plus simple , les serveur ou le SID est visible dans l'url. C'est très fréquent de voir des gens qui poste un lien avec à la fin PHPSESSID=azertyuiop.

Slt
Ouais bon, jamais j'aurais l'idée de faire passer un id en get ou post quand j'utilise les sessions.
Dans ce cas, on ne parle plus de session., mais de passage de variables dans l'url.
Faut pas tout mélanger non plus.

et puis:

Avec une faille Xss par exemple. Un petit bout de js et op je reçoit l'identifiant de session stocké dans le cookie du mec qui aura cliqué sur la page infectée.

Là aussi, soit on raisonne cookie, soit sessions, ce qui n'est pas la même chose.
cookie : sauvegardé sur le pc de l'utilisateur, ok.
Ce qui n'est pas le cas pour une session php dure.

C'est quand même simple à comprendre et de bien distinguer les cookies des sessions.
Un session se lance depuis un pc/navigateur, et elle demeurera sur ce pc/navigateur tant qu'il restera connecté.
Je défie quiconque de venir récupérer mes variables de session depuis un autre poste pc/navigateur.
C'est enfantin pourtant.

Pour ixabro, l'id de session n'a vraiment que peu d'intérêt.
Sauf pour une sauvegarde sur une base données dans le cadre d'une utilisation multi-utilisateurs ou collaborative.
En fait, cet id de session n'est qu'un "réréfencant" de variables mises en mémoire....éphéméres puisque détruites lors d'une deconnection.
Celà dépend donc du cas de figure de l'application, mais il ne faut pas se focaliser sur cet id de sessions.
Honnêtement, j'utilise les sessions sur la plupart de mes applicatifs, et je me moque de savoir ou de connaitre son identifiant (id) puisque c'est lui qui me renvoie les variables utiles.
Puis de toute façon, je coupe mon navigateur, et tout est détruit.

[RunCodePhp]

Salut

$_SESSION['A'] et $_SESSION['B] sont deux entrées dans la meme session.

+1
Le tableau $_SESSION est le contenu de la session, d'une seule et unique session, c'est valable pour chaque session.
Donc $_SESSION['A'] et $_SESSION['B'] appartiennent à la même session. Ce n'est pas ceci qui distingue 2 session, 2 utilisateurs.
Son identifiant (de $_SESSION) c'est : session_id(), et son nom : session_name(). Fait un echo sur ces 2 fonction te permettra de le vérifier.


Pour augmenter un peu plus la sécurité des sessions, la 1ère très simple à faire c'est de donner un autre nom aux sessions, car comme on l'a dit plus haut, par défaut c'est PHPSESSID.
Pour cela, il faut le faire avant le session_start() :

Code :

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

1
2
3
 
session_name('SESS_IXABRO');
session_start();

Le deuxième, là ça dépend totalement type d'hébergement, ça pourra ou non ce faire. Mais vu les très nombreux type d'hégement, il sera impossible d'y faire le tour de la question.
Juste dire que pour un hébergement mutualisé, en règle général les fichiers des sessions sont par défaut déposés dans un répertoire communs à tous les sites Web du serveur (répertoire : blablabla/.../tmp).
Du coup, tous les propriétaires des sites Web ont potentiellement accès à toutes les sessions, et pas seulement les siens.
Pour éviter quelques désagrément, il peut être envisagé de créer son propre répertoire, dans son espace d'hébergement (protégé par un .htaccess), mais cependant prendre la précaution de ne pas le placer dans le virtualhost (le www en général), ce qui diminuerait fortement la sécurité.
Cette dernière n'est toujours réalisable, faut voir.

Une autre solution (c'est celle que j'utilise) consiste à non pas gérer les session comme cela est prévu par défaut, c'est à dire dans des fichiers, mais les gérer dans une Bdd.
C'est plus compliqué à mettre en place cependant.

Je défie quiconque de venir récupérer mes variables de session depuis un autre poste pc/navigateur.
C'est enfantin pourtant.

Le problème n'est pas là.
Que toi, en tant que développeur, que tu prenne toutes les précautions pour que les données de tes utilisateurs et de ton site soient bien sécurisés, c'est une chose, mais quand est il lorsque c'est toi qui navigue sur d'autres sites ?
Admettons que tu fasse un achat sur un site par exemple.
Est tu certain que tes données personnelles soient bien sécurisées ?
Tu n'en sais strictement rien, et ton PC aura beau être le plus sécurisé au monde, rien ne te dis que la planète entière connaisse ton login/pas du site précédent, de toutes tes infos, et même pourquoi pas ton N° de carte bleue


Pour info, il est écrit ceci dans la Doc Php :

Utiliser les sessions ne signifie pas que les données de session ne pourront être vues que par un seul utilisateur. Il est important de garder cela en tête lorsque vous stockez et affichez des données importantes. Lorsque vous stockez des données dans une session, il faut se demander quels seront les problèmes posés si quelqu'un d'autre accède à cette information, ou comment votre application est affectée si la session est en fait celle d'un autre.

On peu difficilement être plus clair.
Les session sont loin d'être un mécanisme fiable.
Et la règle N°1, c'est de ne pas stocker n'importe quoi dans les sessions.
Y mettre par exemple le login et mot de passe dans les session lors d'une identification c'est une pure bêtise par exemple ... pourtant on le voit, même sur ce forum (et les autres aussi)
Idem, on y mets pas les infos de connexion de sa Bdd, etc ...


Dernier point.
Si on crée un site dont les informations qui y circulent sont hautement confidentielles, alors le SSL (httpS) est une solution qui pourrait s'imposer (être rajouté).

[grunk]

Là aussi, soit on raisonne cookie, soit sessions, ce qui n'est pas la même chose.
cookie : sauvegardé sur le pc de l'utilisateur, ok.
Ce qui n'est pas le cas pour une session php dure.

C'est quand même simple à comprendre et de bien distinguer les cookies des sessions

Y me semble quand même que lorsque tu fais un session_start par défaut un cookie temporaire est crée et contient l'id de session (appellé bbsessionhash ici). Sinon comment ton navigateur irait t'il récupérer tes infos dans le fichiers de session sans référence à celui ci ?
C'est ce cookie qu'un hacker viendra lire.
Si ce cookie n'est oas créer le SID est passé en url (voir POST).

Comme dis par RunCodePhp la seule solution qui permettent un niveau de sécurité élevé pour les session est d'utiliser une table spécifique en bdd et non pas le système de php. Souvent on utilisera une table de type memory puisque les données ne sont pas critique mais nécessite des temps d'accès rapide.

[sabotage]

Puis de toute façon, je coupe mon navigateur, et tout est détruit.

Non, la session survit à la fermeture du navigateur.
C'est le cookie de session qui est concerné par la fermeture du navigateur.

Si tu refais un appel au serveur en spécifiant l'id de session, la session reprendra avec toutes ses données.

La suppression effective des sessions mortes est réalisée "regulierement" par le serveur.

[RunCodePhp]

Puis de toute façon, je coupe mon navigateur, et tout est détruit.

Non, la session survit à la fermeture du navigateur.
C'est le cookie de session qui est concerné par la fermeture du navigateur.

Les 2 cas sont possibles, mais impossible aussi. Vous n'avez donc ni tord, ni raisons sur ce point.

En faite, ça dépend des navigateurs, des options qu'ils offrent, et donc du choix qu'auront fait chaque utilisateur.

Pour FireFox par exemple (et une installe par défaut), 3 choix sont offerts :
- Leur expiration
- La fermeture de FireFox (à ne pas confondre avec la fermeture de l'onglet)
- Me demander à chaque fois.

Mais c'est pas tout.
Php permet de redéfinir la date du cookie de session, et ça, comme on veut.

Donc même si coté client le réglage est "La fermeture de FireFox" et que le cookie soit présent, donc navigateur pas encore fermé, si une requête HTTP est lancée vers le serveur, et que la date d'expiration est périmée (bien que le fichier soit existant), cette session ne sera pas reconduite.
Une nouvelle session (nouvel ID) sera fournie. Les infos de l'ancienne sessions seront perdue.

Autre scénario.
Si le choix coté navigateur c'est "leur expiration" et que coté serveur la date d'expiration est valable 1 mois (par exemple), et bien on peu très bien récupérer la même session pendant tout cette période d'1 mois, peu importe que le navigateur soit fermé ou pas.


Les sessions sont donc à la fois souples, mais restrictifs en même temps.
Ca dépend pour beaucoup du coté client malgré tout, on est pas "maitre" dans cette affaire.

[ixabro]

Pour répondre à RunCodePhp, je me suis en effet mise à la place de l'attaquant et j'essaye continuellement de prévoir si par exemple la session d'un membre devait se retrouver entre de mauvaises mains.
Il faut donc si on a anticipé, mettre en place un système de contrôle divers par le biais de botPHP ou autres...

Exemple :

Si l'utilisateur se connecte. Ajout de sa présence sur le compte (sous forme de marque) , dans la base de données ... de là on peut coder pour faire en sorte qu'il n'y ait pas deux personnes sur le même compte.

Si l'utilisateur s'inscrit. Ajout de l'ip, de l'host et du navigateur de celui-ci.
Connection du membre...
Si decconnection du membre et reconnection d'une autre personne possèdant une ip différente, un navigateur et un host différent dans les 0 à 10min qui viennent... refuser la connection.

[ETC ...] et bien d'autres systemes de gestion et de controle.


Mais ce qui m'interesse fortement c'est ce dont à parler RunCodePhp sur la mise en mémoire des sessions via bdd.

[RunCodePhp]

Si l'utilisateur s'inscrit. Ajout de l'ip, de l'host et du navigateur de celui-ci.
Connection du membre...
Si decconnection du membre et reconnection d'une autre personne possèdant une ip différente, un navigateur et un host différent dans les 0 à 10min qui viennent... refuser la connection.

Une adresse IP n'est absolument pas une données fiable. J'ai même tendance à dire que c'est la pire.
J'entends par là, pour un site qui accepterait des utilisateurs inconnus (forums, blog, etc ...).
C'est prendre le risque de refuser une personne tout se qui de plus honnête (parce qu'il utilisera un outil qui le rendra louche).
Ou alors, et surtout, accepter un pirate (averti) qui lui aura pris toute les précautions pour se faire passer pour quelqu'un d'honnête.
Ce qui serait un comble pour un dispositif de sécurité.

Le gros problème dans cette affaire, c'est que les codeurs/développeurs que nous sommes, on est pas des pirates, on connait très mal les techniques qu'utilisent les pirates, voir pas du tout.
Difficile du coup de savoir comment contrer ces pirates.

De plus, rien ne dit qu'en souhaitant fermer une porte à droite, on ne serait pas en train d'ouvrir une autre porte à gauche (qu'un pirate saura s'engouffrer).
Donc becarefull

Pour ma part, et pour les sessions, la règle d'or est d'éviter de stocker des données trop confidentielles dans les sessions.
Si piraterie il devait avoir, et bien le pirate n'aura pas grand chose à se mettre sous la dent.

Si les données sont très confidentielles -> SSL

Le reste, c'est des sur-couches de codes qui à mon sens ne résout pas grands choses de plus.

Mais ce qui m'interesse fortement c'est ce dont à parler RunCodePhp sur la mise en mémoire des sessions via bdd.

C'est une méthode que j'ai adoptée, qui à l'origine vient d'un Soft Open Source : OsCommerce.
(Mais très fortement modifié, plus grand chose à voir avec le code original).
Tu peux t'en inspirer.
Mais d'autres Soft l'ont surement adopté.
En tout cas, j'estime que c'est une solution très confortable.

[sabotage]

Il y a une démonstration ici :
http://a-pellegrini.developpez.com/t...hp/session-db/

[alain31tl]

Bsr

Sur ce sujet, j'avais créé mes propres sources en associant sessions + sauvegarde sur database pour un cabinet député maire.

Et c'est relativement simple à mettre en place, en préférant enregistrer les variables utiles + id de référence, juste aprés la création de la session.

Mais nullement et jamais, mes pages de scripts web ne font référence à des variables sensibles ( id de session, login, pasword etc...).
En fait, c'est simplement une tournure d'esprit quand on comprend bien le système de gestion des sessions.

Et puis, les cookies, ce n'est pas ma tasse de thé, et si du piratge devait avoir lieu, c'est de ce côté que se tourneraient les protagonistes, c'est plus qu'évident.
Je me répête, c'est pour cette raison que je me suis fait insistant (sans trop déranger, j'espére ) qu'il est plus judicieux de n'utiliser que des sessions php... et rien que celà.

[sabotage]

Et puis, les cookies, ce n'est pas ma tasse de thé, et si du piratge devait avoir lieu, c'est de ce côté que se tourneraient les protagonistes, c'est plus qu'évident.

Les id de sessions sont transmis soit par cookie soit par URL.
Comme tu dis ne vouloir ni l'un ni l'autre ... il y a un problème.

[alain31tl]

Les id de sessions sont transmis soit par cookie soit par URL.
Comme tu dis ne vouloir ni l'un ni l'autre ... il y a un problème.

Oui, il est courant de pouvoir se reconnecter sur un site, aprés l'avoir quitté et fermé le navigateur...et s'y reconnecter sans être contraint de se réidentifier.
Et effectivement, on retrouve nos variables comme auparavant, sites commerciaux généralement qui conserve un panier de commande...par exemple.
Simplement parce que les variables pour ce premier cas sont enregistrées sur le pc de l'utilisateur (cookies).

C'est simple, il suffit de supprimer les fichiers temporaires du dd pour se rendre compte de cette pertinence et que ce n'est plus possible aprés coup, aprés avoir vidé son fichier temporaire.
Tu me confirmeras ou non l'état de fait ?

Mais ce n'est pas spécifique.
Il est d'autre cas où celà est impossible et par voie de conséquence, être obligé de se réidentifier.
Tu me confirmeras ou non l'état de fait ?

Donc,on est bien en présence de 2 possibilités de gérer les sessions.
1- Session client/serveur + cookie pc utilisateur
2 - Sessions client/serveur sans cookie pc utilisateur.
Et dans ce dernier cas, aucune trace sur ton pc, sauf éventuellement le lien qui a été consulté, et rien d'autre.

[sabotage]

Tu dis la meme chose que moi : les sessions fonctionnent soit avec en stockant l'id dans un cookie soit en passant l'id par l'url.
Il y a forcemment un échange de l'id entre le client et le serveur à chaque fois ... et le serveur ne vérifie d'aucune manière la légitimé de l'utilisateur qui lui fourni l'id.

[RunCodePhp]

Et puis, les cookies, ce n'est pas ma tasse de thé, et si du piratge devait avoir lieu, c'est de ce côté que se tourneraient les protagonistes, c'est plus qu'évident.

C'est étonnant, car je ne suis pas du tout de cette avis.
Ce serait plutôt coté serveur que les pirates (à mon sens toujours) recherchent les failles, pas coté client.
Enfin, dans notre domaine j'entends, c'est à dire un pirate à la recherche d'un ID de session dans le but de l'usurper.

Pirater un poste client (donc un PC avant tout, avant d'ttendre le navigateur) est à mon sens compliqué.
De plus, et quand bien même il arriverait à lire les cookies, il y a de forte chance que leur date soient périmée, donc inexploitable.


Par contre, pirater un serveur, comme par exemple celui d'un hébergeur, un mutualisé par exemple, cible privilégié car on sait que les sessions sont bien souvent déposés dans un même répertoires communs (tmp), et bien là, s'il parvient, c'est un peu le jackpot : des milliers de fichiers sessions (peut être plus même), et parmi ceux là, des sessions pas encore périmée, donc exploitables, et la cerise sur le gâteau, tout le contenu qui va avec.


Des sites amateurs, que dis je, des sites professionnels même ne sont pas si sécurisés que ça, suffit de sillonner le Net (les forums entre autre) pour s'en rendre compte.
Les pirates eux savent comment les chercher, c'est leur truc.
Même chose pour les hébergeurs, il y en a qui sont plus ou moins sécurisés, en tout cas les pirates eux le savent, se passent le mot.

Les id de sessions sont transmis soit par cookie soit par URL.

Exacte.
Il faut que le serveur envoie au moins 1 fois le cookie (le couple nom-valeur au même titre que tout paramètres et ça dans l'URL, donc visible) vers le poste client pour que justement ce dernier crée le cookie.
Ca ne peut être autrement.
L'identification repose à 100% entre le cookie du poste client et la session coté serveur.
Donc tu exploite les cookies.
Ceci dit, je comprends ce que tu veux dire, c'est à dire que tu t'arrête à créer qu'1 seule cookie, et que celui ci contient juste un ID, celui de la session.
De mon coté c'est pareil, soit dit en passant.

Mais c'est pas pour ça qu'il faut être parano.

Prenons un site dont j'ai exploité il y a peu, un site qui développe et vend des photos sur papier à partir des images qu'on envoie. (site très connu).
Et bien ils exploitent à fond la caisse les cookies, mais alors, à fond.
Ceci, dans un seul but de permettre des faire toutes les manips sur nos photos sans avoir à aucun moment fourni une seule information personnelles (ni adresse e-mail, mot de passe, etc ... rien).
Et bien grâce aux cookies, on peu reprendre les manips plusieurs jours après.
Bref ... leur truc est vachement bien goupillé.
Coté sécurité ? 0 risques, aucun. Normal, ce n'est que des infos relatives aux photos, aucune données personnelles, rien, nada ...

Conclusion : Il n'y a pas de restriction à se faire d'un coté comme de l'autre (cookie ou session), il n'y a pas moins ou plus de sécurité, tout est une question de bon sens, et tout repose sur la confidentialité des donnée.

@alain31tl
Tu peux exploiter les cookies, faut juste se restreindre à ne pas stocker n'importe quoi, c'est tout