[PHP] Modifier la session d'un autre utilisateur [Résolu]

Bonjour.

J'ai un système d'identification basé sur les sessions et j'aimerai m'assurer à chaque fois que l'utilisateur charge une page que cet utilisateur existe toujours ( que l'admin n'a pas supprimé ou bloqué son compte ) et qu'il a bien les permissions nécessaires pour lire la page à laquelle il tente d'accéder.
Or je me dis que lancer une requête SQL à chaque page juste pour vérifier ça ça fait un peu lourd donc je me dis que si je pouvais modifier la session d'un utilisateur quand l'admin lui enlève des droits ce serait moins lourd.
Ma question est donc : y a-t-il un moyen de modifier une autre session que celle qui est en cours ?

Merci d'avance.
Modifié par Changaco (15 Jul 2008 - 11:02)

koala64 a écrit :
Salut,

mmh... Tu ne te sers pas de session_regenerate_id() ?
Pourtant, c'est pas mal pour éviter les attaques par fixation de session.

Salut

Je ne cherche pas à contrer une attaque. Ici il s'agit de s'assurer que l'admin n'a ni supprimé le compte, ni retiré des droits à l'utilisateur.

koala64 a écrit :
Mieux vaudrait agir directement sur l'utilisateur plutôt que sur l'id de sa session.

Je ne cherche pas à modifier l'id de session je cherche à modifier les variables de session et à défaut de pouvoir le faire supprimer la session est une bonne option.

koala64 a écrit :
Cela dit, tout cela va t'amener à faire quelque chose de plus lourd que la simple requête que tu cherches à éviter.

Ce sera plus lourd en terme de lignes de code mais en terme de rapidité 1 requête par page en moins c'est pas négligeable ...

Ce que j'ai déjà fait c'est créer de manière dynamique un fichier php par user avec un nom de fichier qui contient l'id du user. Quand l'admin change les droits du user, son fichier est modifié.
Tu n'as plus alors qu'a faire un include du fichier de ton user actif dans ton code PHP pour vérifier ses droits.

Je comprends bien le souhait mais chercher à supprimer une session via l'identifiant, c'est exposer l'application à ces attaques vu qu'on ne peut plus se servir de session_regenerate_id().

C'est quand même plus dommageable que de supprimer une requête pour laquelle mySQL est prévue et gère cela sans sourciller.

... sans compter que je suppose que l'admin' ne se contente pas de supprimer une session, faute de quoi, il suffit de se déconnecter et de se reconnecter pour contourner la suppression des droits.

Enfin bon, ce n'est qu'un avis mais quelque soit la solution adoptée, mieux vaudrait mettre les données de l'utilisateur (plus difficilement falsifiables) en session et se référer à elles plutôt qu'à l'identifiant de session.
Modifié par koala64 (14 Jul 2008 - 11:46)

koala64 a écrit :
Je comprends bien le souhait mais chercher à supprimer une session via l'identifiant, c'est exposer l'application à ces attaques vu qu'on ne peut plus se servir de session_regenerate_id().

C'est quand même plus dommageable que de supprimer une requête pour laquelle mySQL est prévue et gère cela sans sourciller.

... sans compter que je suppose que l'admin' ne se contente pas de supprimer une session, faute de quoi, il suffit de se déconnecter et de se reconnecter pour contourner la suppression des droits.

Enfin bon, ce n'est qu'un avis mais quelque soit la solution adoptée, mieux vaudrait mettre les données de l'utilisateur en session et se référer à elles plutôt qu'à l'identifiant de session.

Si je supprime le fichier de session l'utilisateur est simplement déconnecté on est d'accord ?
Donc le système va voir qu'il n'est pas connecté et va l'envoyer sur la page de login.
L'utilisateur se connecte et ses nouveaux droits sont mis dans la session.
Si ses nouveaux droits ne lui permettent plus d'accéder à la partie du site en question alors on le redirige vers la partie publique ...

Lorsque tu mets :

unlink(session_save_path().'/sess_'.$id_de_la_session_a_detruire);

Ça suppose que tu connaisses l'identifiant et donc qu'il ne change pas (d'où les problèmes de sécurité)... ou alors qu'à chaque fois que tu régénères l'identifiant, si ça vient à être mis en place, que tu enregistres ce dernier en bdd à chaque changement de page des utilisateurs (= requête supplémentaire ce qui équivaut à revenir au point de départ).
Modifié par koala64 (14 Jul 2008 - 12:06)

koala64 a écrit :
Lorsque tu mets :

unlink(session_save_path().'/sess_'.$id_de_la_session_a_detruire);

Ça suppose que tu connaisses l'identifiant et donc qu'il ne change pas (d'où les problèmes de sécurité)... ou alors qu'à chaque fois que tu régénères l'identifiant, si ça vient à être mis en place, que tu enregistres ce dernier en bdd à chaque changement de page des utilisateurs (= requête supplémentaire ce qui équivaut à revenir au point de départ).

Maintenant je vois ce que tu veux dire. C'est vrai que c'est un problème. Je vais méditer tout ça en mangeant et je reviens poster ...

Il n'est pas nécessaire de connaître l'id de session mais plutôt de savoir si l'utilisateur est connecté ou pas. Dès lors que tu enregistres cet état lors de l'authentification de l'utilisateur, rien ne t'empêche, par recoupement, d'agir sur n'importe quelle donnée utilisateur (nom, email, ip, navigateur utilisé, etc...).

Quant à la fonction session_regenerate_id(), elle permet de changer l'identifiant de session tout en conservant les données de session. Perso, vu sa facilité de mise en place et les avantages qu'elle procure, c'est une fonction dont je ne me passe guère dans un système nécessitant l'identification de l'utilisateur.

koala64 a écrit :
Il n'est pas nécessaire de connaître l'id de session mais plutôt de savoir si l'utilisateur est connecté ou pas. Dès lors que tu enregistres cet état lors de l'authentification de l'utilisateur, rien ne t'empêche, par recoupement, d'agir sur n'importe quelle donnée utilisateur (nom, email, ip, navigateur utilisé, etc...).

Excuse moi je me suis mal exprimé : il est nécessaire de connaître l'id d'une session pour pouvoir la détruire ( sauf pour la session en cours bien sûr ).
Donc si je trouvais un moyen de modifier les données d'une session autre que celle en cours à partir du pseudo de l'utilisateur je n'aurai pas besoin de constamment savoir quel id de session correspond à quel utilisateur donc je pourrai utiliser "session_regenerate_id()" à chaque page si ça me chante.
Le seul problème c'est que cela ne m'a pas l'air possible sauf à changer une de ces deux valeurs de php.ini : "session.save_handler" ou "session.serialize_handler".
La question est donc : y a-t-il un autre moyen pour accéder aux données d'une session autre que celle en cours sans connaître son id ?

koala64 a écrit :
Quant à la fonction session_regenerate_id(), elle permet de changer l'identifiant de session tout en conservant les données de session. Perso, vu sa facilité de mise en place et les avantages qu'elle procure, c'est une fonction dont je ne me passe guère dans un système nécessitant l'identification de l'utilisateur.

Oui je sais bien à quoi elle sert mais ma question était de savoir s'il n'y avait pas d'inconvénients à l'utiliser à chaque page. Visiblement tu penses que non mais peut-être que d'autres personnes ont une autre opinion et c'est cela que j'aimerai savoir.

koala64 a écrit :
En fait, je dirais que si le seul but est d'économiser une requête en tentant d'accéder à une session autre que la tienne (le but des sessions étant justement de ne pas rendre les données utilisateurs accessibles), c'est infaisable sans nuire à l'application. (Je peux me tromper mais là, je ne vois vraiment pas comment faire )

Le but des sessions c'est de conserver des données utilisateur d'une page à une autre sans faire appel à la BDD et ce de façon plutôt sécurisée. À partir de là permettre à un script PHP de modifier les données d'un autre utilisateur que soi-même je ne vois pas en quoi cela va contre l'objectif initial puisque ce n'est pas l'utilisateur lui-même qui change les données mais bien un script PHP.
Ceci n'est pas possible de base et utiliser "session_set_save_handler()" me paraît un peu lourd juste pour ça.

koala64 a écrit :
En somme, si ça ne tenait qu'à moi, je conserverais le système de départ avec la requête au chargement de la page et je ne me compliquerais pas plus la vie.

Si je ne trouve pas de solution c'est bien ce que je vais finir par faire mais je trouve ça dommage.
Modifié par Changaco (14 Jul 2008 - 17:12)

J'ai essayé de regarder "session_set_save_handler()" mais je ne peux pas faire ce que je veux avec. En fait il faudrait remplacer la valeur de "session.serialize_handler" par "wddx" mais ce n'est pas quelque chose de disponible de base dans PHP donc c'est mauvais pour la portabilité du système.

Je vais donc réfléchir à une autre architecture pour mon système ...
Modifié par Changaco (14 Jul 2008 - 17:21)

Bon en fait j'étais parti du principe que les fichiers de session n'étaient pas des fichiers texte mais en fait ils le sont c'était juste mon éditeur de texte qui voulait pas le lire. Le problème est donc résolu car si je stocke le pseudo de l'utilisateur dans sa session il me suffit de parcourir les fichiers de session pour trouver celui que je veux modifier.

Sujet résolu.