Est-il possible de simuler une variable de session ?

WRInaute accro
Bonjour

Ma question peut paraîttre triviale :

Est-il possible, dans un navigateur, de simuler une variable de session ?

Les identificateurs de sessions ( PHPSESSID ou autre nom si spécifié ), ne sont valables que tant que le site a été visité une fois au moins, depuis l'allumage du navigateur.

Mais... Une fois une page du site visitée, est-il possible de faire en sorte, dans un navigateur courant ( Firefox, Chrome, ou même IE ), d'alimenter une variable de session, qui se comporte vis-à-vis du navigateur, et du site, de la même manière que si cette variable de session, avait été alimentée par le site ?

Merci beaucoup pour votre réponse.

Jean François Ortolo


PS Je sais bien, que de toute façon, en programmant en php, on peut facilement faire celà avec les fonctions curl_*().

Ma question ne porte que sur les navigateurs.
 
WRInaute accro
e-kiwi a dit:
Bonjour,

une variable session est une variable serveur. aucun lien avec un navigateur


Bonjour e-kiwi ;)

Celà signifie-t-il, qu'il est rigoureusement impossible, même dans un script php avec des fonction curl_*(), de simuler ( = de créer ou modifier ) une variable de session d'un site "aspiré" avec ces fonctions dans le script ?

Merci beaucoup de ta réponse.

Bien amicalement.

Jean François Ortolo
 
WRInaute accro
forty a dit:
rien n’empêche de créer un cookie de pseudo-session ainsi qu'une table de variable+valeur


Bonjour forty ;)

De quelle manière, avec des fonctions de type curl_*() , créer une variable var de pseudo-session de valeur : $value , de telle manière que quand sur le serveur, on teste la valeur de la variable : if($_SESSION['var'] == $value) , ce test rende true ?

Eventuellement, la même question avec un navigateur. Probablement pas possible ?

Merci beaucoup de ta réponse. ;)

Bien amicalement.

Jean François Ortolo
 
WRInaute accro
e-kiwi a dit:
explique nous ce que tu veux faire précisément , et on te dira la meilleure façon de faire :)


Bonjour e-kiwi

Sachant qu'un site ( dont je tairai le nom ), utilise comme interrupteur indiquant l'authentification d'un visiteur, une seule variable de session avec une valeur fixe quel que soit le visiteur, et que ce site déclenche avec l'instruction classique en début de ses scripts php, une session de cette manière : session_start(); ( sans spécifier d'autre identificateur de session autre que celui par défaut PHPSESSID ), j'aimerai ssavoir, s'il est possible, après avoir aspiré une page de ce site ( pour positionner le PHPSESSID identificateur de session reçu comme cookie obligatoirement ), d'écrire cette variable de session avec cette valeur et un nom supposés connus ( $value et var ), de manière à ce que le site cible, en faisant le test if($_SESSION['var'] == $value) , constate que le test rend true ( avec var et $value supposés être les nom et valeur de cette variable de session certifiant l'authentification du visiteur ).

L'authentification du visiteur, n'est pas destiné à l'identifier, mais à lui permettre l'accès à des endroits privés du site.

J'ajoute, que j'ai besoin d'avoir cette information, non pas pour hacker ce site, mais au contraire pour le sécuriser, car je pense qu'il n'est pas suffisament sécurisé actuellement, compte tenu du fait que la variable de session certifiant l'authentification du visiteur, a un nom et une valeur fixes.

L'ensemble de la manip ( première aspiration du site pour obtenir le PHPSESSID, puis affectation de la variable de session ), devant être fait, soit par un navigateur, ou bien par un script php client, contenant des instructions php avec des instructions de type curl_*() , ou bien éventuellement, de type socket ( fsocketopen() , etc... )

Ceci, compte tenu du fait, que ce site, crée effectivement cette variable de session, quand le visiteur est bien authentifiié, par l'instruction : $_SESSION['var'] = $value; ( nom et valeur adaptés et onnus ).

Je le sais, car j'ai participé à la programmation de ces éléments de certification d'authentification de ce site, et je suis tenu, de fournir au Monsieur qui me l'a demandé, un procédé d'authentification fiable, résistant aux hacks.

D'autre part, j'ai mis au point sur le papier, un excellent procédé d'authentification fiable utilisant aussi une table MySQL en plus d'une variable de session,mais pour convaincre ce Monsieur de me laisser modifier cette procédure d'authentification, je suis obligé de lui montrer que l'ancienne méthode n'est pas fiable... ;(

Mais... Si l'ancienne version est fiable quand même, pas la peine de changer ? ;)

Merci beaucoup à vous de vos réponses.

Bien amicalement.

Jean François Ortolo
 
WRInaute accro
il me semble qu'il n'y a que curl qui le permette, pas socket
déjà, comment est transféré le sid ? par cookie ou par url ? en général le timeout du sid est de 30', ne permettant plus de se connecter au delà.
Comment l'internaute obtient son accès restreint ? juste en récupérant son sid ou par rapport à une inscription dans une bdd ?
pour moi, la meilleure protection d'un accès restreint reste le couple ltaccess/htpasswd
 
WRInaute accro
Leonick a dit:
il me semble qu'il n'y a que curl qui le permette, pas socket
pas sur qu'en mode "SOCK_RAW" tu ne puisse pas "simuler" ce que tu veux (ce qui ne change rien au problème de base).
 
WRInaute accro
ortolojf a dit:
Sachant qu'un site, utilise une seule variable de session avec une valeur fixe quel que soit le visiteur pour l'authentification.
J'aimerai savoir, s'il est possible, après avoir aspiré une page de ce site, d'écrire cette variable de session avec cette valeur et un nom supposés connus, de manière à ce que le site cible, pense que l'utilisateur est authentifié.

J'ai reformulé ta question avec ce que je pense avoir compris de la question. ^^^

Les variables de sessions sont "écrites" par le serveur et tes scripts qui tournent dessus. Donc on ne peut pas "forcer" une variable de session à prendre une valeur (via un navigateur dans des conditions normales) sans passer par un de tes scripts prévu pour y écrire (genre page login par exemple). C'est donc la sécurité du script qui conditionne la sécurité de la variable de session.

Pour augmenter la sécurité tu peux ajouter un sel a la valeur contenu dans cette variable qui rend sa prédiction impossible, donc par voie de conséquence, l'usurpation d'un de tes scripts moins facile (cela implique donc de détourner un script pour imposer une écriture dans la dite variable et en plus de savoir quoi y écrire bref cour toujours).

Ensuite associer authentification et cookies est hasardeux car les cookies sont eux particulièrement exposés puisque côté client (voir pour mémoire la facilité d'usurper des droits admin avec les phpBB de vieille génération). Donc toute authentification ne dois pas se baser sur une valeur contenu dans un cookies. Passer un numéro de session (hash de 32 caractères le plus souvent) ne pose en revanche pas de souci car il n'est pas possible de prédire le numéro de session d'un utilisateur ayant les droits convoités (sauf a renifler mais c'est plu la même clientèle ;-) ou d'avoir un accès au serveur hébergeant mais là tu va pas te faire ch*er a bidouiller une variable tu y va directement).

Si actuellement tu divulgue le contenu de tes variables de session dans tes cookies (cas plu fréquent qu'on le croie) tu risque d'avoir des soucis surtout si tu prend la valeur du cookies pour argent content.

pour le sécuriser, car je pense qu'il n'est pas suffisamment sécurisé actuellement, compte tenu du fait que la variable de session certifiant l'authentification du visiteur, a un nom et une valeur fixe
C'est pas tant son nom que la valeur qui peu poser souci, mais comme exposé ci avant pose toi d'abord la question de comment y écrire et là tu devrais être rassuré si tu n'a pas codé le truc avec les pieds.

Pense aussi que si on met de côté tes scripts et leur sécurité intrinsèque, la valeur de ta variable de session est juste une suite de bits dans la MEV du serveur. Et que pour y accéder en écriture il y a juste un débordement qui pourrait le faire, mais sachant qu'il y a quasiment aucune chance d'altérer que cette variable et avec une valeur pas certaine du tout sans planter tout le thread dédié au traitement de la requête. Bref attaquer ta variable est beaucoup plus complexe que mettre tout le serveur sous contrôle, ce qui rend la manipe irréaliste.

Pour finir, il est parfois plus sécu d'avoir une simple écriture de ta variable comme ça :
$_SESSION['var'] = 'value';
Car si tu maitrise bien les conditions qui aboutissent a cette écriture, le contenu en lui même est "en dur", donc pas issue d'un sous ensemble logiciel pouvant être détourné (il n'y a a rien de pire que le fruit d'une requête complexe en base par exemple si des paramètres de cette requête dépendent d'un utilisateur)

Pour mon cas perso j'utilise depuis longtemps deux variables de sessions pour la sécurité de mes sites.

l'une s'appelle 'log' (utilisateur connecté ou pas) et l'autre s'appelle 'droit' et contient 6 ou 7 mots uniques définissant le type d'utilisateur (webmaster, visiteur, rédacteur en chef, modérateur, ...)
Ces deux variables si elle n'existent pas (!isset()) sont systématiquement initialisées au droits minimums non connecté dans le fichier de config (donc inclus partout) et ne peuvent être changées que par le formulaire de connexion qui lui est blindé. Il n'y a nul par ailleurs un accès en écriture sur ces variables, juste des lectures.
 
WRInaute accro
Bonsoir à tous, merci de vos réponses ;)

J'ai écrit à l'instant, deux scripts php avec deux fonctions ( une par script ), respectivement les fonctions make_authen($password) et verif_authen() , qui lisent et écrivent dans une table MySQL de la base de données.

Grâce à ces fonctions, la variable de session, pourrait contenir le mot de passe crypté avec la fonctionc crypt() en DES et un "salt" totalement aléatoire.

Le mode d'enregistrement et de vérification d'une authentification, se ferait à la fois par cette variable de session, et par la lecture de l'adresse ip remote, ainsi qu'un timestamp qui, au delà de 24 heures, efface le contenu de cette table MySQL à la prochaine connexion.

Je pense, que l'ensemble de ce procédé d'authentification, est fiable et sécurisé, car comme la variable de session n'est de toute façon pas lisible dans le navigateur ( même en regardant dans les menus de configuration ) ( et même si c'était possible, le mot de passe serait crypté avec un "salt" de deux lettres", donc indéchiffrable compte tenu du peu d'intérêt realtif que celà repréenterait, par rapprot aux efforts à faire ... ;) ), donc dans ces conditions, rien ne filtre au dehors, et il est également impossible, de remplir cette table MySQL avec des données permettant l'authentification, de l'extérieur, donc, l'authentification provoquée est impossible.

Je vais immédiatement, faire en sorte qu'il soit impossible de déclencher ces scripts de l'extérieur. ;)

Il me reste, à convaincre mon Directeur, que celà vaut la peine de modifier ( trsè facilement et rapidement ), les scripts actuels où sont programmés les authentifications, qui je crois, sont au nombre de deux.

Pourriez-vous m'apporter des arguments pour celà, que je puisse présenter à mon Directeur ? ;)

Merci beaucoup de vos réponses.

Bien amicalement.

Jean François Ortolo
 
Discussions similaires
Haut