Est-il possible de simuler une variable de session ?

[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

[BertrandB]

Post by 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

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/138670/how-unique-is-the-php-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.

[Jean Francois Ortolo]

Post by BertrandB
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
http://stackoverflow.com/questions/138670/how-unique-is-the-php-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

[Jean Francois Ortolo]

Post by BertrandB
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
http://stackoverflow.com/questions/138670/how-unique-is-the-php-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.

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

[Jean Francois Ortolo]

Post by Jean Francois 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
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

[Jean Francois Ortolo]

Bonjour Monsieur

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

[Jean Francois Ortolo]

Rebonjour Monsieur

Je corrige une petite erreur, un lapsus, c'est une parenthèse oubliée
dans l'instruction de sha1()

Bien amicalement.

Jean François Ortolo

Post by Jean Francois Ortolo
Bonjour Monsieur
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.
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

[Jean Francois Ortolo]

Post by Jean Francois Ortolo
Bonjour Monsieur
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;
?>
------------------------------------------------
Bien amicalement.
Jean François Ortolo

Rebonsoir Monsieur

Après test sur mon serveur Apache 2 sur mon ordinateur ( Fedora 15 64
bits ), ce script semble bien modifier l'identificateur de session, et
garde la seule variable de session correctement.

C'est vrai que cette variable de session, ne peut avoir que 1 ou 0
comme valeur, mais il semblerait que ce script conserve les variables de
session.

Merci de me donner votre impression, par rapport à ce script.

Je cherchais quant à moi, à trouver un moyen de changer
l'identificateur de session, de manière strictement aléatoire et complexe.

Je ne savais pas comment affecter à cet identificateur de session,
une valeur manuelle calculée.

Ce script a l'air de résoudre le problème.

Bien amicalement.

Jean François Ortolo

[Jean Francois Ortolo]

Rebonsoir Monsieur

J'ai encore une question :

Les modification systématiques de l'identificateur de session ( une
modification par page chargée ), ne servent qu'à rendre impossible le
fait de connaître la valeur d'un identificateur de session.

Mais... Internet Explorer ( certaines versions je crois ), ont une
faille qui permet de consulter à distance, les cookies d'un utilisateur,
mettons connecté au site que je cherche à sécuriser.

Imaginons... Un programme "dormant", guettant un certain nombre
d'adresses ip correspondant à des visiteurs connus du hacker comme
visiteurs payants de ce site, et utilisant ces versions d'Internet Explorer.

Voilà le topo :

- Un de ces visiteurs se connecte, puis reste sur une page, mettons,
plus de quelques secondes.

- Le programme repère ce visiteur, et lit le cookie de session dans
le navigateur du visiteur payant.

- Ensuite, automatiquement, le programme génère le même cookie dans
un fichier type Netscape, puis charge ( pas trop rapidement pour que les
modifications de l'identificateur de session aient lieu lors de la
navigation du programme ), des pages protégées du site...

En effet, le visiteur n'a pas encore changé de page, donc son
identificateur de session est identique et valide...

Conséquence, l'identificateur de session a changé, le vrai visiteur
n'est plus connecté. Et le hacker a bien accès au contenu protégé, et
continue allégrement à y accéder.

Face à celà, une seule et unique solution : C'est de mettre dans
une variable de session, l'adresse ip des visiteurs, et de ne changer
l'identificateur de session, que quand l'adresse ip remote est la même,
que celle enregistrée dans la variable de session.

Dans ce cas, la visite du programme, s'arrêtera, quand le vrai
visiteur, aura changé de page.

On peut aussi, coupler celà, avec un mode d'authentification, prenant
en compte, l'adresse ip et le mot de passe crypté du visiteur.

Celà fera, que le programme, n'ayant pas la même adresse ip que le
vrai visiteur ( on suppose que c'est trop difficile de spoofer très
rapidement dans ces conditions une adresse ip mise à jour récemment ),
ne sera pas authentifié, et donc n'aura pas accès au contenu protégé.

Ne pensez-vous pas, que ce scénario est possible ?

Dans cette éventualité, j'ai intérêt, à modifier le code de ce script
init_session.php ?

Merci beaucoup de votre réponse.

Bien amicalement.

Jean François Ortolo

[Tonton Th]

Post by Jean Francois Ortolo
Face à celà, une seule et unique solution : C'est de mettre dans
une variable de session, l'adresse ip des visiteurs, et de ne changer
l'identificateur de session, que quand l'adresse ip remote est la même,
que celle enregistrée dans la variable de session.

Et ça ne marchera pas si le visiteur est derrière un
proxy à multiples sorties...

[Jean Francois Ortolo]

Post by Tonton Th

Post by Jean Francois Ortolo
Face à celà, une seule et unique solution : C'est de mettre dans
une variable de session, l'adresse ip des visiteurs, et de ne changer
l'identificateur de session, que quand l'adresse ip remote est la même,
que celle enregistrée dans la variable de session.

Et ça ne marchera pas si le visiteur est derrière un
proxy à multiples sorties...

Bonjour Monsieur

Quand même, le site à protéger est un site de pronostics sur les
courses de chevaux, dont les pronostics sont payants.

On suppose, que les visiteurs de ce site, ne sont pas cloîtrés dans
une entreprise, derrière un proxy ?...

Il me faut bien supposer, que l'adresse ip remote, est fixe, sinon je
ne peux absolument pas sécuriser ce site.

Il me semble, que même lors d'une connexion à un FAI par modem
téléphonique, en crosude conexion l'adresse ip cliente ( remote ) ne
change pas.

Comme FAI changeant l'adresse ip en cours de connexion, je ne vois
guère qu'AOL...

Quant aux Intranets d'entreprises, les Travailleurs, ne sont pas
censé visiter le site, à leurs heures de travail ?

Merci beaucoup de votre réponse.

Bien amicalement.

Jean François Ortolo

[Tonton Th]

Post by Jean Francois Ortolo
Comme FAI changeant l'adresse ip en cours de connexion, je ne vois
guère qu'AOL...

Et les accès par téléphonie mobile ?

[Jean Francois Ortolo]

Post by Tonton Th

Post by Jean Francois Ortolo
Comme FAI changeant l'adresse ip en cours de connexion, je ne vois
guère qu'AOL...

Et les accès par téléphonie mobile ?

Bonjour Monsieur

Je n'ai pas d'idée par rapport aux téléphones mobiles.

Je croyais, que quand un téléphone mobile était connecté sur un site
web, son adresse ip ne changeait pas.

Sinon, je ne vois pas comment il serait possible aux systèmes (
réellement ) sécurisés de paiement, de fonctionner, à moins
effectivement d'utiliser la fameuse fonction qui affecte les différentes
fonctions gérant les sessions ( me souviens plus du nom de cette fonction ).

A ce moment-là, les fonctions gérant les sessions, seraient des
fonctions utilisateurs, et non plus des fonctions gérées par le système,
donc avec force utilisation de mémorisation dans des tables MySQL...

Merci beaucoup, de bien vouloir me dire, si un téléphone portable en
connexion internet avec un site web, va se mettre impromptu à changer
son adresse ip cliente, alors que le visiteur continue à visiter le site
?...

Bien amicalement.

Jean François Ortolo

[Jean Francois Ortolo]

Post by Tonton Th

Post by Jean Francois Ortolo
Comme FAI changeant l'adresse ip en cours de connexion, je ne vois
guère qu'AOL...

Et les accès par téléphonie mobile ?

Bonsoir Monsieur

J'ai mis en place ce soir, ce procédé de sécurisation, sur mon site
partenaire www.lescourses.com

J'ai accès, aux indications de l'intermédiaire de paiement de son
Directeur ( Allopass ).

Je verrai d'ici quelques jours, si la rentabilité a augmenté
brusquement depuis ce soir.

Je n'ai pas mis tout le procédé de sécurisation que j'envisageais (
une variable de session certifiant l'authentification, dépendant de
l'adresse ip cliente, et du mot de passe crypté du visiteur, avec
mémorisation de la connexion dans une table MySQL ), mais la
sécurisation par modification systématique de le valeur de
l'identificateur de session à chaque chargements de pages, devrait déjà
décourager pas mail de hackers...

Bien amicalement.

Jean François Ortolo

[Jean Francois Ortolo]

Rebonsoir Monsieur

Voici mon code modifié :

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();
if(!isset($_SESSION['REMOTE_ADDR']))
$_SESSION['REMOTE_ADDR'] = $_SERVER['REMOTE_ADDR'];

if($_SESSION['REMOTE_ADDR'] == $_SERVER['REMOTE_ADDR'])
{
$old_session = $_SESSION;
session_write_close();

mt_srand(make_seed());

session_id(sha1(mt_rand()));
session_start();

$_SESSION = $old_session;
}
?>
------------------------------------------------


Merci beaucoup de votre avis à propos de ce script.

Est-ce que celà vous semble suffisamment sécurisé ?

Bien amicalement.

Jean François Ortolo