Est-il possible de simuler une variable de session ?
Le
Jean Francois Ortolo
Bonjour
Question pour le php
Je me suis laissé dire, sur le forum du site www.webrankinfo.com ,
qu'une variable de session était obligatoirement côté serveur , et qu'il
était impossible d'en créer ( ou d'en modifier ) une par le client ( que
ce soit un programme php ou un navigateur ).
Or, Monsieur John Gallet, en son temps, avait expliqué qu'il y avait
des failles de sécurité à utiliser des variables de session de contenu
fixe ( ou non codé ), ou en tout cas, dont le contenu était en relation
directe avec ce que l'on voulait cacher.
Pour l'instant, j'ai simplement besoin de savoir, si c'est possible
de créer une variable de session, avec un programme php client (par
exemple avec des fonction curl_*() ), qui "aspire" un site distant.
Dans un deuxième temps, j'aurai également besoin d'avoir la réponse à
cette même question, mais à partir d'un navigateur client ( au lieu d'un
programme php ).
Merci beaucoup au modérateur, de ne pas filtrer mon message, pour son
côté relatif au php. ;)
Bien amicalement.
Jean François Ortolo
Question pour le php
Je me suis laissé dire, sur le forum du site www.webrankinfo.com ,
qu'une variable de session était obligatoirement côté serveur , et qu'il
était impossible d'en créer ( ou d'en modifier ) une par le client ( que
ce soit un programme php ou un navigateur ).
Or, Monsieur John Gallet, en son temps, avait expliqué qu'il y avait
des failles de sécurité à utiliser des variables de session de contenu
fixe ( ou non codé ), ou en tout cas, dont le contenu était en relation
directe avec ce que l'on voulait cacher.
Pour l'instant, j'ai simplement besoin de savoir, si c'est possible
de créer une variable de session, avec un programme php client (par
exemple avec des fonction curl_*() ), qui "aspire" un site distant.
Dans un deuxième temps, j'aurai également besoin d'avoir la réponse à
cette même question, mais à partir d'un navigateur client ( au lieu d'un
programme php ).
Merci beaucoup au modérateur, de ne pas filtrer mon message, pour son
côté relatif au php. ;)
Bien amicalement.
Jean François Ortolo
Poser une question
la variable de session est transmise par un cookie ou en paramètre
d'appel. Sur le serveur elle corspond à un fichier dans un réeprtoire
commun contenant le contenu sérialisé de la variable globale $_SESSION.
Donc il est théoriquement faisable d'arriver sur la session de quelqu'un
d'autre en jouant sur le cookie
une excelente discussion sur le sujet :
http://stackoverflow.com/questions/...session-id
il y est proposé une méthode de protection mais on peut en imaginer d'autres
comme multiplié les faux cookie de session
changer le sessid à chaque requête
coupler le cookie de sesion avec un cookie contenant une clé stokée dans
la varianble de session ... cette clé changeant souvent.
Bonjour Monsieur
Changer le cookie de session à chaque requête, serait dans son
concept, l'équivalent d'une chaîne aléatoire de type rand(), modifiée
pour générer des chaînes de caractères...
Celà ne risquerait-il pas, de surcharger le serveur ?
Ou bien, l'autre solution, une clé changeant à chaque requête dans un
cookie, associé à un cookie de session, çà me plairait bien...
Mais, comment savoir lors de la requêtes suivante, la valeur correcte
de la clé ?
Je ne vois pas très bien comment implémenter un processus de
mémorisation, que d'autres visiteurs ne pourraient pas parasiter ?
Et... Si je mettais dans un cookie de nom fixe, le hash md5() de la
concaténation de l'adresse ip ( moins le dernier numéro et le dernier
point, pour tenir compte des adresses ip changeantes d'aol ), de
l'user-agent du navigateur, et du mot de passe fourni crypté avec
crypt() en DES avec une "salt" de deux lettres aléatoires ?
Je mettrais également, le même mot de passe crypté, dans un cookie.
Mot de passe donc théoriquement indéchiffrable avec un dictionnaire de
mots de passe, puisque le mot de passe serait au départ fourni par
l'intermédiaire de paiement, donc composé de lettres et chiffres aléatoires.
J'insérerais dans une table MySQL au moment de la certification de
l'authentification, le timestamp de time(), le mot de passe crypté, et
la valeur du premier cookie.
Pour vérifier que le visiteur est authentifié, je disposerais donc de
son mot de passe crypté, je ferais une recherche par timestamp
croissant, des enregistrements dont le champ du mot de passe crypté, est
égal au cookie de ce mot de passe crypté.
Avant celà, j'effacerais tous les enregistrements de cette table
MySQL, dont le timestamp serait inférieur à time() - ( 24 * 60 * 60 ),
pour ne retenir que les sessions datant de moins de 24 heures.
Si je trouve un enregistrement lors de ma première requête, le
visiteur serait authentifié, sinon non.
Compte tenu du fait, que pour simuler une authentification,il
faudrait à la fois, avoir une adresse ip identique, et un cookie de
session identique, ce procédé d'identification, pourrait-il être
considéré comme suffisamment "secure" ?
Merci beaucoup de votre réponse.
Bien amicalement.
Jean François Ortolo
Rebonjour Monsieur
J'ai regardé sur le PHP Manual, la fonction session_regenerate_id($param)
Quand $param vaut true, l'ancienne session est censée être détruite,
mais les données de session sont conservées quand même.
J'ai noté dans les nombreux commentaires, que quand une page protégée
avec cette fonction, est rechargée rapidement, et que le mode de
transmission des sessions est par cookies ( ce que je souhaite ), alors
le navigateur client peut souvent, ne pas updater ses cookies lors de
chaque chargement de page, et ainsi on obtiendrait des résulats
imprévisibles, le plus souvent le visiteur serait déconnecté faussement.
Celà semble m'indiquer, que le seul moyen de sécuriser correctement
une connexion, serait d'associer à un id de session ( sous forme de
cookie ), un autre cookie qui soit une clé aléatoire, mise à jour à
chaque chargement de page. Soit votre troisième recommandation.
Mais, pour implémenter celà, comment, lors d'un chargement d'une
page, savoir, en lisant la valeur de ce cookie, que la valeur est
correcte ? Il faudrait pour celà, avoir la valeur de la clé précédente.
Celà ne nécessiterait-il pas, d'enregistrer à chaque chargement de
page, la valeur de la clé, dans une table MySQL, dont la valeur serait
lue, passée à la moulinette de la fonction pseudo-aléatoire de mise à
jour, le résultat comparé avec le cookie-clé, et succès si les deux
matchent ? Dans ce cas, mise à jour de la nouvelle clé à la place de
l'ancienne clé dans la table MySQL ?
De toute manière, pour qu'il y ait validation de l'authentification à
chaque chargement de page, il faut bien que le navigateur et le serveur,
échangent au moins deux cookies : L'un en lecture vers le serveur, et
l'autre en écriture vers le navigateur ?
A charge pour le navigateur client, de ne pas charger ses pages trop
rapidement, sinon il sera déconnecté ?
Comme je ne sais pas la rapidité complète de la fonction
session_regenerate_id($param), ne pensez-vous pas, que cette deuxième
solution du cookie-clé, est préférable à cette fonction de changement
d'id de session ?
D'autre part, je porte à votre connaissance, le fait qu'il semble
qu'il soit possible de complexifier facilement les valeurs possibles des
identificateurs de session, en mettant les deux instructions suivantes,
en début des scripts php du site, avant les instructions relatives au
sessions :
ini_set("session.entropy_file", "/dev/urandom");
ini_set("session.entropy_length", "512");
Celà aurait pour effet, de supprimer toute possibilité, que deux
identificateurs de session soient identiques, pour deux navigateurs
différents, au même moment.
Merci beaucoup de votre réponse.
Bien amicalement.
Jean François Ortolo
Rebonjour Monsieur
J'ai fait une erreur.
Effectivement, votre troisième solution, en fait, associait un id de
session, avec une clé contenue à la fois, dans un cookie et dans une
variable de session.
Je pense, que pour réduire le temps nécessaire a à la transmission
des informations entre le navigateur et le serveur ( un cookie en
lecture, et un cookie en écriture ), je m'en tiendrai, à la solution que
j'ai indiquée, faisant appel à une table MySQL mémorisant la clé, plutôt
qu'à une variable de session.
Comme la clé serait censée changer tout le temps, il ne serait pas
nécessaire de la crypter, par rapport au contenu de la table MySQL.
Bien amicalement.
Jean François Ortolo
J'ai vu le code suivant pour régénérer l'id de session, sans toucher
aux variables de session ( adapté par mes soins, pour initialiser la
fonction mt_rand() )
On appelle ce script init_session.php ,
il sera inclus au début de tous les scripts php
où interviennent des sessions.
---------------------------------------------------------
<?php
function make_seed()
{
list($usec, $sec) = explode(' ', microtime());
return( (float)$sec + ((float)$usec * 100000);
}
session_start();
$old_session = $_SESSION;
session_write_close();
mt_srand(make_seed());
session_id(sha1(mt_rand());
session_start();
$_SESSION = $old_session;
?>
------------------------------------------------
Le but, comme vous voyez, est de régénérer un id de session
strictement et entièrement aléatoire ( produit par la fonction sha1() ),
ne pouvant pas être dupliqué entre les différentes sessions (
nombreuses... ) du serveur.
Ma question est :
Pensez-vous, que ce script, fera effectivement ce qu'a dit le
commentaire mentionnant ce code sur le PHP Manual, c'est-à-dire garder
les variables de session, tout en régénérant l'identificateur de session ?
Le problème, est que je ne sais pas si les variables incluses dans la
globale $_SESSION , sont effacées par l'instruction
session_write_close() après l'affectation de $old_session
Donc, il se pourrait, qu'effectivement la réaffectation de $_SESSION
par $old_session à la fin, puisse restaurer les variables de session.
C'est ce qu'a l'air de supposer l'auteur de ce commentaire dans le
PHP Manual.
Evidemment, l'identificateur de session est censé être dans un
cookie, mais ce n'est pas important, vu qu'il est régénéré à chaque
appel de script, et totalement imprévisible.
Merci beaucoup, si vous pouviez valider, ou invalider, ce code, qu'il
me suffirait de mettre dans un script, que je pourrais inclure au début
de chaque scripts du site que je dois sécuriser. ;)
Bien amicalement.
Jean François Ortolo