Forum d'entraide PHPFrance

Bonjour à tous et à toutes,

J'ai une question assez simple, en revanche la réponse va moins l'être :
Soit deux membres A et B avec deux sessions différentes, non commune et distincte. Puis-je étant le membre A accéder à la session du membre B en lecture et/ou en écriture si je possède la chaine d'identification du membre B ? Si oui, comment ?

Par avance merci

Salut ,

Oui , via l'url par exemple ... ( je n'irais pas plus loin sur la méthode trés connue )

Mais je pense que beaucoup d'hébergeur interdisent la définition de session via l'url ( ce qui me parait normal )

Et/ou un plugin apache comme mod_security va directement bloquer la requête

Et au niveau du développement , un filtre sur les données entrantes doit être mis en place ... , et ou regénération de session constamment , ce qui limite les vols ...

il y a bien d'autres façon de sécuriser les scripts ...

Soit deux membres A et B avec deux sessions différentes, non commune et distincte. Puis-je étant le membre A accéder à la session du membre B en lecture et/ou en écriture si je possède la chaine d'identification du membre B ? Si oui, comment ?

Oui. Si tu connais le contenu du cookie de session du client A, il suffit de construire un cookie sur B ayant le même contenu. C'est tout. Ça s'appelle un vol de session. Mais pour cela il faut un accès physique à la machine du client A, lui demander d'aller faire un tour à la cafet' et de faire une copie du cookie ou du fichier qui les contient.

Sans accès physique, je ne vois que le vol de session par "cross site scripting" ou encore de snifer les paquets du réseau de A. Bref, pas à la portée de n'importe qui.

Tu poses la question pour t'en protéger ou pour attaquer?

Ah, je me suis mal expliquer

En gros, je suis sur un système de messagerie privée et, plutôt que de vérifier toutes les X secondes via une requête à la base de données qui sera certainement surchargée, j'aimerais savoir si je ne peut pas directement changer le nombre de message total et non-lu du destinataire exemple :

==========
Client | Session
------------------
...A....|....Sa....
...B....|....Sb....

==========
Contenu des sessions :
Variables :
Session|mp_non_lu|mp_total
---------------------------------
...Sa....|......25.......|...256..
...Sb....|......33.......|...128..

==========
A envoi un message à B


==========
Nouveau contenu des sessions :
Variables :
Session|mp_non_lu|mp_total
---------------------------------
...Sa....|......25.......|...256..
...Sb....|......34.......|...129..

Voilà, j'espère m'être mieux exprimé

Par avance merci de votre aide

Moi pour me prévenir de ceci, je me fais un regenerate_id() à chaque page

Moi pour me prévenir de ceci, je me fais un regenerate_id() à chaque page

Mauvaise idée, sur le livre de G. Ponçon et J. Pauli traitant de Zend Framework catégorie Cahiers du Programmeur, il est écrit qu'il faudrait prendre en compte les risque de collisions... En revanche, la régénération au moment de la connexion est souhaitable, ce que j'applique, mais le sujet n'est pas là ^^

Par avance merci de votre aide

Ah, c'est du côté serveur que ça se passe. Dans ce cas, oui j'imagine qu'il est possible d'accéder à un fichier de session en connaissant son id. De le unserialize(), modifier la donnée et ensuite le serialize(). Mais attention, je pense que PHP utilise un serialize() interne pour les sessions. Tu devras un peu jouer sur les perg_split() pour séparer chaque variable de session pour arriver à tes fins. A essayer.

Ou alors de jouer avec les session_id(). Du genre

// depuis une session de A:

// stockage de l'ID de session de A
$IDdeA = session_id();

// bascule sur la session de B
session_id($IDdeB);

      // modification de la variable de B et mise en session

// retour sur la session de A
session_id($IDdeA);

Merci beaucoup, mais, comment savoir si la session existe encore ?

Par avance merci de votre aide

Il faut deux conditions pour qu'une session existe: un cookie sur le client (contenant l'id de la session) et un fichier de session sur le serveur. Pour détruire une session il faut détruire le fichier de session côté serveur avec un session_destroy() ensuite forcer une suppression du cookie client avec setcookie() avec un cookie vide. Si tu ne supprimes pas les deux elle persistera. Je le sens pas trop ton truc avec les sessions.

Pourquoi ne gères-tu pas tout ça dans une table. Si ton serveur MySQL est lent, utilise sqlite qui est très véloce pour ce genre de choses. Aussi rapide que d'ouvrir un fichier de session.

Oui et non, oui, j'ai pensé à SQLite, mais il aura trop de charge, j'utilise PostGreSQL et, bien que je fasse très bien les choses, je pourrait arrivé très vite à pas loin de 2.000 requêtes native par secondes pour 400 membres, donc, le but est de l'alléger...
J'ai pensé à faire une requête toutes les X secondes, X étant déterminé en fonction de la charge du serveur, mais ça reviendrait à faire attendre les membres et surchargé PostGreSQL qui n'a pas besoin de ça...
Nous avons installé les sessions dans la RAM, via memcache, je doute donc de la plus grande rapidité de SQLite...
J'aimerais savoir si j'appelai une session (par session_id()) inexistante, que ce passerait-il ?

Par avance merci de votre aide

J'aimerais savoir si j'appelai une session (par session_id()) inexistante, que ce passerait-il ?

Je ne suis pas trop sûr que la manipulation de sessions qu j'ai proposée plus haut fonctionnera. Je suis même certain du contraire après avoir lu ceci:

Note: Lorsque vous utilisez les sessions avec les cookies, le fait de spécifier un id pour session_id() fera qu'un nouveau cookie sera toujours envoyé lors de l'appel à session_start(), sans ce soucier si l'identifiant de session courant est identique à celui qui vient d'être défini.

Il te reste à manipuler les fichiers de session.

Oui et non, oui, j'ai pensé à SQLite, mais il aura trop de charge, j'utilise PostGreSQL et, bien que je fasse très bien les choses, je pourrait arrivé très vite à pas loin de 2.000 requêtes native par secondes pour 400 membres, donc, le but est de l'alléger...

Le dernier benchmark effectué je crois par Naholyr et posté sur PHPfrance faisait apparaitre des performances très en retrait pour PostrGre par rapport à SQLite, donc peut être devrais-tu essayé tout de même pour en être sûr.

bien que je fasse très bien les choses

Prétentieux va!!!

Le dernier benchmark effectué je crois par Naholyr et posté sur PHPfrance faisait apparaitre des performances très en retrait pour PostrGre par rapport à SQLite, donc peut être devrais-tu essayé tout de même pour en être sûr

Ne s'agirait-il pas de celui-ci?
http://www.phpfrance.com/forums/viewtopic.php?t=245780

Le dernier benchmark effectué je crois par Naholyr et posté sur PHPfrance faisait apparaitre des performances très en retrait pour PostrGre par rapport à SQLite, donc peut être devrais-tu essayé tout de même pour en être sûr.

Mmmh, je vais continuer de creuser du côté des session, mais, vu que je suis avec PostGreSQL depuis le début de mon projet et qu'il commence à dater, 9 mois, je ne pense que je vais lâcher PostGreSQL de si tôt, deplus, j'ai déjà plus de 40 fonctions en PL/pgsql, ce qui me permet d'économiser la communication entre PostGreSQL et PHP, ce qui est le plus couteux, et c'est ce en quoi PostGreSQL est plus rapide...

bien que je fasse très bien les choses

Prétentieux va!!!

Un peu, mais au vu de mon travail...
Bref, vous verrez dans quelques mois

Il faut deux conditions pour qu'une session existe: un cookie sur le client (contenant l'id de la session) et un fichier de session sur le serveur. Pour détruire une session il faut détruire le fichier de session côté serveur avec un session_destroy() ensuite forcer une suppression du cookie client avec setcookie() avec un cookie vide. Si tu ne supprimes pas les deux elle persistera. Je le sens pas trop ton truc avec les sessions.

Pourquoi ne gères-tu pas tout ça dans une table. Si ton serveur MySQL est lent, utilise sqlite qui est très véloce pour ce genre de choses. Aussi rapide que d'ouvrir un fichier de session.

C'est ce que j'ai utiliser pour un extranet en fait je gère les sessions aussi sur la base de donnée histoire d'avoir une visibilité supplémentaire.

A l'ouverture de session tu stock des informations en base et tu met à jour selon ce que tu as besoin et le rang utilisateur, plutôt que de rentrer dans des manipulation au niveau des cookie qui semblent fastidieuses et peu fiables.