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

[Anthor]

Et le cache Opcode multiplie par 30% minimum, le nombre de thread simultanés qu'apache peut supporter :love:

[Melimelo]

Une question au passage comme ca, il y a un interet a utiliser Memcache plustot que les tables Memory ?

Sinon, je trouve le systeme de flag pas mal pour la mise a jour des droits ou pour prevenir l'arriver de nouveau mp.

Mais keke a l'air assez retissant. Possibilite que vous postiez un resumer de votre conversation Mp ?

Cordialement Melimelo

[keke]

Coucou Melimelo ^^

Les discutions sont en cours. J'ai préféré finir par MP, car il est plus facile d'apporter des réponses sans avoir des remarques parasites liés au fonctionnement normal d'un forum. J'ai proposé une sorte de conclusion à la discussion, mais je préfère citer les mots de rygnes :

En conclusion, tu as raison. [note de kéké :le système par session est limité et n'est pas fiable à 100%]
C'est un système en chaussette (qui tient chaud l'hiver mais qu'on aimerait peut-être enlever l'été) qui peut vite partir en sucette...

Melimelo, note que je suis retissant à l'utilisation de variable de Session sauf dans les cas que j'ai mentionné. J'aime pas me citer, ça fait pompeux ... mais bon :

En mon sens, les variables de session ne sont pas des données fiables. Elles peuvent être utilisées que dans des cas précis :
- système de connexion
- formulaire en plusieurs pages (même si on peut les éviter)
- pour stocker des constantes propre au joueur. (le nom du joueur, le nom de sa ville principale, ...)
- pour stocker des id de tables qui sont pratiquement invariants durant la connexion de l'utilisateur. A utiliser dans l'idée d'optimiser ses requêtes.

La variable de Rygnes ne rentrait pas dans ces 4 cas ... Ce n'est pas une constantes, ni une variable de sessions, elle n'est pas lié à un formulaire et ne rejoins pas la notion d'identifiant.
Sa variable est une variable de type Flag, qui peut évoluer indépendamment de l'utilisateur... => Centraliser l'information par BDD uniquement même si ça consomme 1 pouillème de ressource en plus.

Dans le cas d'un flag sur la messagerie, la méthode employé par RoworII me parait efficace car le cas en est différent. Différent en 2 points :
- La donnée n'est pas sensible ... si le joueur ne voit pas qu'il a un nouveau message ... Y'a pas mort d'homme.
- La donnée est mise à jour par une action maitrisée. Il s'agit d'un autre joueur qui met à jour la variable de session. Correctement implémenté cette méthode peut-être fiabilisée ... mais il faut une bonne pratique des variables de session. Un pro peut se permettre ce genre d'action.

Pour ces 2 raisons (s'il en manque ma conclusion est opposée), le cas de RoworII me parait efficace.

J'ai peut-être fait avorté la discussion avec Holy car je n'étais pas très en phase avec lui. On campait sur nos positions respectives ... et finalement la discussion piétinait ... Plus de discussion constructive => arrêt de la discussion sinon on risque de se vexer pour rien.

Le résumé te plait-il ?

kéké

[Melimelo]

sympa et j'ai pour finir compris tout seul que le systeme etait caduque dans le cas du double navigateur car seulement une des deux sessions sera mis a jours.

Sinon je pense que je vais l'utiliser pour les messagerie.

Merci beaucoup en tout cas.


Cordialement Melimelo (toujours prive d'internet)

[Anthor]

IMPORTANT
Enfin un trucs concernant les sessions, il est primordial lors de l'appel à session_start d'utiliser session_regenerate_id afin d'eviter qu'un utilisateur ne se fasse imposer son numero de session.
Ce qui serait l'équivalent d'un vol de' session, et malheureusement beaucoup d'application sont vulnérable à cette faille!

Il ne faut surtout pas le faire après chaque session_start(), ce qui correspond à renvoyer un nouveau cookie à chaque requête http, pour renouveler l'identifiant, ce qui est très lourd.
Par contre il faut effectivement régénérer l'identifiant à chaque connexion d'un membre, pour déconnecter tout autre personne susceptible d'être connecté.

Pour simplement éviter une même session entre deux navigateurs différents, et donc un éventuel vol de session, il suffit simplement d'enregistrer le navigateur entre 2 requêtes :

Code PHP :

<?php 

session_start();

$clientHeaders = $_SERVER['HTTP_USER_AGENT'];

if( array_key_exists('HTTP_ACCEPT', $_SERVER) )

    $clientHeaders .= $_SERVER['HTTP_ACCEPT'];

$clientHeaders = md5($clientHeaders);



// Si utilisateur connecté

if( isConnect() && $_SESSION['clientBrowser'] != $clientHeaders )

{

    session_regenerate_id();

    session_destroy();

    header("HTTP/1.0 403 Forbidden" );

    exit();

}



$_SESSION['clientBrowser'] = $clientHeaders; 

[Holy]

IMPORTANT
Enfin un trucs concernant les sessions, il est primordial lors de l'appel à session_start d'utiliser session_regenerate_id afin d'eviter qu'un utilisateur ne se fasse imposer son numero de session.
Ce qui serait l'équivalent d'un vol de' session, et malheureusement beaucoup d'application sont vulnérable à cette faille!

Il ne faut surtout pas le faire après chaque session_start(), ce qui correspond à renvoyer un nouveau cookie à chaque requête http, pour renouveler l'identifiant, ce qui est très lourd.
Par contre il faut effectivement régénérer l'identifiant à chaque connexion d'un membre, pour déconnecter tout autre personne susceptible d'être connecté.

Pour simplement éviter une même session entre deux navigateurs différents, et donc un éventuel vol de session, il suffit simplement d'enregistrer le navigateur entre 2 requêtes :

Code PHP :

<?php 

session_start();

$clientHeaders = $_SERVER['HTTP_USER_AGENT'];

if( array_key_exists('HTTP_ACCEPT', $_SERVER) )

    $clientHeaders .= $_SERVER['HTTP_ACCEPT'];

$clientHeaders = md5($clientHeaders);



// Si utilisateur connecté

if( isConnect() && $_SESSION['clientBrowser'] != $clientHeaders )

{

    session_regenerate_id();

    session_destroy();

    header("HTTP/1.0 403 Forbidden" );

    exit();

}



$_SESSION['clientBrowser'] = $clientHeaders; 

[Anthor]

C'est pourtant une solution reconnu dans le monde du développement. Peut-être devrait-tu revoir le fonctionnement interne des sessions ?

Si tu change de navigateur, le premier est automatiquement déconnecté, grâce au changement d'id, puis du vidage, qui reconnecte une nouvelle session. L'ordre est important, car si tu vides en premier, l'identifiant reste le même.Le pirate ne peux plus réouvrir la session à moins de retrouver l'identifiant de session.

Enfin, tu devrais savoir que cela fait parti des préconisations de Zend en matière de sécurité. M'enfin je dit ça je dit rien... Continuez donc à vous réinventer la roue avec des script inutiles et coûteux en ressources ^^

[Melimelo]

ca c'est pour eviter une MEME session sur deux navigateur different.

Mais si on veut empecher un meme utilisateur d'avoir deux navigateur a la fois sur le site, c'est effectivement pas cette solution ^^

[Holy]

C'est pourtant une solution reconnu dans le monde du développement. Peut-être devrait-tu revoir le fonctionnement interne des sessions ?

Si tu change de navigateur, le premier est automatiquement déconnecté, grâce au changement d'id, puis du vidage, qui reconnecte une nouvelle session. L'ordre est important, car si tu vides en premier, l'identifiant reste le même.Le pirate ne peux plus réouvrir la session à moins de retrouver l'identifiant de session.

Enfin, tu devrais savoir que cela fait parti des préconisations de Zend en matière de sécurité. M'enfin je dit ça je dit rien... Continuez donc à vous réinventer la roue avec des script inutiles et coûteux en ressources ^^

Je dois pas avoir grand chose à ce que tu me dis je pense (ou alors on parle pas de la même chose) ^^'

Soyons précis, parce que c'est un peu brouillon.

Moi ce que je disais c'est:
Tu es connecté sous "pseudo A" sur Internet Explorer.
Tu décides de te connecter dans le même temps sur mozilla avec ce même compte.

Tu auras donc 2 sessions sur un seul et même compte.
Donc deux identifiants de session pour un seul utilisateur.

Si tu parles de la même situation, je ne comprends pas comment ton script pourrait fonctionner puisque dans tous les cas, $_SESSION est indépendant d'un navigateur à l'autre et donc même si tu définis les navigateurs, ceux-ci seront définis indépendamment l'un de l'autre.

Ah >_< je crois que je viens de piger, tu parles en cas de "vol" de sid ou autre faille qui permet de récupérer . Moi je parlais de manière plus générale. Cette technique serait un bon complément à mon obstruction de double connexion (qui elle est basée elle sur le fait qu'on se "log" deux fois, donc deux sessions sur un utilisateur, et non pas une session par l'utilisateur et le pirate).

Bête question mais les données renvoyées par HTTP_USER_AGENT et HTTP_ACCEPT ne peuvent-elles pas être complétées par d'autres données discriminantes de manière à améliorer le résultat ?

Et je trouve pas qu'on réinvente la roue, on cherche juste à sécuriser aux maximums les données de session, déjà rien qu'en terme de sécurité c'est un plus (dans l'absolu). Et si avec ça et un bon petit framework artisanal on arrive à limiter l'accès à la BDD, ça peut être efficace.

[Anthor]

Tu peux éventuellement rajouter l'IP dedans, et oui on parle bien de solution légère pour éviter le vol de SID