Les sessions (sécurité, utilité, optimisation)

[phenix]

Les sessions sont stockées sur le serveur et c'est le programme qui les enregistre. Ça ne vient donc pas de l'utilisateur et ne peut pas être manipulé par lui. C'est un endroit sûr (à ma connaissance).

Le seul risque (toujours à ma connaissance 2), c'est l'usurpation de session. L'identifiant de session d'un utilisateur est souvent stockée dans un Cookie intitulé PHPSESSID. Parfois il passe dans l'URL sous forme de variable GET, il porte là aussi le nom de PHPSESSID.

Si un joueur A obtient le PHPSESSID d'un joueur B, il peut se faire passer pour lui sur le site (vu que c'est la session du joueur A qui est utilisée). Cela fait partie des attaques par CSRF (ou XSRF).

Je suis heureux de l'apprendre, les sessions mon toujours fait peur a ce niveau.

Pour éviter ce type d'attaque il suffirais donc de comparer des IP...

[Zamentur]

C'est théoriquement possible mais pas très utile en fait...
Quoi que, je pense qu'il y aurait des problèmes avec les cookies.
De toute façon, ce n'est pas une bonne solution.
Ce n'est pas fait pour ça et certains outils dispo eux sont fait pour ça.

La solution proposé c'est dans le cas ou memcache n'est pas installé et qu'on a pas la main sur le serveur.

EDIT: Attention en se connectant à la session d'un autre joueur, on envoie au premier joueur l'identifiant de l'autre.
Ce qui peut entrainer un vol de session!

[Cartman34]

Merci phenix, tu répètes ce que je dis :p

Zamentur -> Tu peux toujours utiliser mysql mais il est vrai que le moteur MEMORY n'est pas toujours intégré je n'en sais trop rien en fait...)

[Holy]

Je me permets d'ajouter ma petite pierre à l'édifice.

Personnellement, dans tous mes jeux, j'empêche absolument une double connexion sur un même compte (petit script), et dans le même temps j'utilise avant tout les sessions dont je provoque l'actualisation lorsque les données de l'utilisateur sont mises à jour par quelqu'un d'autre que lui (admin, modo ou autre).

Ainsi si je bannis un joueur, je crée un fichier avec son id dans un dossier. En début de script chez le joueur, j'ai un petit bout de code qui vérifie l'existence du fichier en question. Si il existe, je mets ma session à jour ($_SESSION['ban'] passe à 1 par exemple), et je supprime ensuite le fichier.

En soi le système n'est pas lourd, puisqu'il s'agit d'une unique vérification de fichier.

[rygnes]

Le seul risque (toujours à ma connaissance ), c'est l'usurpation de session. L'identifiant de session d'un utilisateur est souvent stockée dans un Cookie intitulé PHPSESSID. Parfois il passe dans l'URL sous forme de variable GET, il porte là aussi le nom de PHPSESSID.

La solution n'est pas nouvelle et est utilisée par de grands jeux/sites...
Il faut vérifier que les IPs correspondent.

Ce n'est pas une bonne méthode.
D'une part parce que ceux qui utilisent volontairement des proxys ne pourraient pas accéder au jeu et d'autre part parce que les utilisateurs de type AOL ne pourront pas non plus y jouer.
Théoriquement, lorsqu'on développe une application, ce n'est pas dans l'optique de la sécuriser au point d'en empêcher l'accès.
Je serais curieux de savoir quels sites utilisent cette vieille méthode ?

Personnellement, dans tous mes jeux, j'empêche absolument une double connexion sur un même compte (petit script)

Une double connexion oui. Mais pas le vol de session.
Je ne comprends pas bien l'utilité de ce système, peux tu l'illustrer par un exemple pratique s'il te plaît ?

[Holy]

Personnellement, dans tous mes jeux, j'empêche absolument une double connexion sur un même compte (petit script)

Une double connexion oui. Mais pas le vol de session.
Je ne comprends pas bien l'utilité de ce système, peux tu l'illustrer par un exemple pratique s'il te plaît ?

Je ne voyais pas non plus l'utilité d'un tel système avant de découvrir que si je me connectais sous deux navigateurs sur le même compte, je créais deux sessions (ça peut sembler logique, mais ça ne m'avait jamais frappé). Or si je me base en partie sur les sessions, il est difficile de coordonner les actions des deux sessions.

Exemple: Un joueur se trouve sur une map, il a droit à X déplacements par jour. Le nombre de déplacements restant est stocké dans une variable de session. Je n'ai qu'à me déplacer d'abord avec firefox par exemple, épuisé les déplacements sur cette session. Et ensuite me déplacer avec IE. Etant donné que ce sont deux sessions distinctes pour le même compte, je multiplie mes capacités par deux (ou plus si on utilise encore d'autres browsers).

Ce système n'est valable uniquement que si le script se base sur les données de session. Si vous vérifiez régulièrement avec la base de données, forcément, ça ne servirait pas à grand chose.

J'utilise un fichier dans lequel j'ai un tableau avec les identifiants de session courants de tous les joueurs. Dés lors que quelqu'un se connecte sur le même compte, je crée un fichier temporaire ayant pour nom l'ancien identifiant de session (sid) courant.
A chaque début de page, je vérifie l'existence d'un fichier portant le nom du sid, si il existe, déconnexion forcée et suppression du fichier.
Le dossier contenant les fichiers provoquant la déconnexion est nettoyée régulièrement pour éviter qu'il y en aie 20 000 ^^

J'ai expliqué en gros le principe. Dans le détail, c'est plus propre que ça, puisque lorsqu'une personne se déconnecte de son plein gré, son "sid" est supprimé du tableau reprenant tous les sid courants, etc.

Edition: De fait, ça n'empêche pas le vol de session. A mon sens, le vol dépend plus du codeur que de l'utilisateur. En sécurisant bien les champs, c'est rare que ça arrive.

[rygnes]

Oh je vois...
Je n'utilise pas du tout les sessions pour cet usage (mes caches ne peuvent pas être utilisés à des fins de tricherie), c'est pour cela que je ne percevais pas l'intérêt.
Mais le système 'session+cache en session+contrôle', n'est-il pas plus alambiqué dans sa mise en oeuvre par rapport au système 'session+bdd' ?

Enfin c'est une question de goût. Je préfère user un peu plus de ressources et avoir moins de contrôles à programmer, trop de contrôles nuit au contrôle.

[Holy]

Oh je vois...
Je n'utilise pas du tout les sessions pour cet usage (mes caches ne peuvent pas être utilisés à des fins de tricherie), c'est pour cela que je ne percevais pas l'intérêt.
Mais le système 'session+cache en session+contrôle', n'est-il pas plus alambiqué dans sa mise en oeuvre par rapport au système 'session+bdd' ?

Enfin c'est une question de goût. Je préfère user un peu plus de ressources et avoir moins de contrôles à programmer, trop de contrôles nuit au contrôle.

C'est, à mon sens, l'un des grands problèmes de la documentation. J'ai pratiquement jamais trouvé d'articles sur ce genre de thématiques ^^

J'ai longtemps hésité, et aujourd'hui j'ai un squelette qui se base sur un cache de session assez complet. Je pourrais reconvertir mon système facilement vers une table sql. Faudrait que j'essaie de voir les performances

[Nambew]

Holy, c'est pour ça qu'il faut toujours faire une vérification dans la BD pour savoir si l'utilisateur peut effectuer ou non l'action. Bloquer un joueur parce qu'il ouvre plusieurs sessions est une mauvaise idée, quand je joue à un jeu web, je vais parfois ouvrir deux sessions, une avec le jeu et l'autre avec les messages.

[rygnes]

Tu peux partir du principe que les sessions sont moins fiables qu'une base de donnée.
Tout ce qui n'est pas en dur est par définition volatile, s'il y a plantage, tu perds bien plus de données.

Pour ta mise en oeuvre, tu peux faire deux classes distinctes et les faire fonctionner en parallèle.

Nambew, tu joues avec deux navigateurs différents sur le même jeu ?
Parce que si c'est le même navigateur, il s'agit de la même session.