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
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
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.
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.
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.
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.
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.
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.
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 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 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
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
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
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
Le 16/01/2012 20:04, Jean Francois Ortolo a écrit :
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
Le 16/01/2012 20:04, Jean Francois Ortolo a écrit :
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
Le 16/01/2012 20:04, Jean Francois Ortolo a écrit :
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
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.
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.
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.