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]

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]

Le 15/01/2012 10:08, BertrandB a écrit :
>
> 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.

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.

[Jean Francois Ortolo]

Le 15/01/2012 10:08, BertrandB a écrit :
>

> 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.

[Jean Francois 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.

[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. ;)

[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

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()));

[Jean Francois 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
>>
>>
>

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.

[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.

[Tonton Th]

On 01/16/2012 10:35 PM, Jean Francois Ortolo wrote:
> 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...

--

Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/

[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é ?

[Jean Francois Ortolo]

Le 16/01/2012 22:55, Tonton Th a écrit :
> On 01/16/2012 10:35 PM, Jean Francois Ortolo wrote:
>> 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 ?

[Tonton Th]

On 01/16/2012 11:02 PM, Jean Francois Ortolo wrote:

> 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]

Le 18/01/2012 12:07, Tonton Th a écrit :
> On 01/16/2012 11:02 PM, Jean Francois Ortolo wrote:
>
>> 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
?...

[Jean Francois Ortolo]

Le 18/01/2012 12:07, Tonton Th a écrit :

> On 01/16/2012 11:02 PM, Jean Francois Ortolo wrote:
>
>> 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...