Identifiants de sessions : fonctionnement et stockage
5 réponses
Eric Demeester
Bonjour à tous,
Ca fait pas mal de temps que je programme sous divers langages (1983,
arg!), je me suis mis à PHP il y a une petite année. Pour l'instant ça
se passe plutôt bien, mais là je coince sur quelques concepts et malgré
la lecture des archives de ce groupe et de diverses FAQs, je coince un
peu, alors je me permets de faire appel à vos lumières, plus
particulièrement concernant le fonctionnemment des sessions :)
J'ai déjà développé plusieurs sites faisant appel aux sessions PHP, mais
en gros ça se résume à ça : l'utilisateur entre son identifiant et son
mot de passe. Si je le trouve dans ma base de données :
- j'enregistre ça dans $_SESSION :
$identifiant = $_SESSION['identifiant']
$Modepasse = $_SESSION['motdepasse']
puis je le redirige vers la page d'accueil de la partie du site
« protégée ».
Par ailleurs, lors de l'accès à une page protégée, je fais un
session_start(), je récupère $_SESSION['identifiant'],
$_SESSION['motdepasse'], je contrôle dans ma base, si c'est ok la page
s'affiche sinon retour à la page d'accueil avec un session_destroy().
Tout cela est probablement un peu lourd, mais bon ça fonctionne et à
l'usage (quelques milliers d'utilisateurs) ça semble fiable :)
Là, on me demande de développer (c'est à la mode) un site de vente en
ligne avec constitution d'un panier d'achat. A priori, côté base de
données et stockage des éléments sélectionnés par le visiteur dans
$_SESSION[] pour les promener d'une page à l'autre, j'ai compris comment
faire. Il me reste des interrogations sur les possibilités d'intégrer
des tableaux associatifs les uns dans les autres mais c'est un détail,
je testerai.
Par contre, il n'est pas question d'exiger du visiteur se prùenant sur
un site de vente en ligne qu'il s'identifie au préalable. Pour moi,
cette identification ne peut se faire qu'à la validation de la commande,
soit en lui demandant de rentrer ses coordonnées, soit en lui demandant
de s'identifier par identifiant/mot de passe pour préremplir ses
coordonnées s'il a déjà passé commande par le passé.
J'en viens à mes questions, n'ayant trouvé aucune réponse claire (ou
plutôt pléthore de réponses difficiles à comprendre pour moi) ici ni
lors de mes recherches sur le web :
1. J'ai cru comprendre que la fonction session_start() générait
automatiquement un identifiant de session. Déjà, est-ce exact ? Cet
identifiant est j'imagine lié à l'adresse IP de la machine du client,
sinon il y a risque de confusion ?
2. J'ai cru comprendre ensuite que cet identifiant de session
permettait, le temps du parcours du site par le visiteur, de
l'identifier et de stocker l'ensemble des informations contenues dans la
session dans un fichier côté serveur.
3. Si je me résume, untel (connu ou non) se connecte sur le site, se
voit attribuer automatiquement un identifiant de session dès lors que la
page (d'accueil ou une autre au hasard en fonction de ce qu'il aura mis
en bookmarks) débute par session_start(), permettant de tracer ce qu'il
fait. J'ai bon jusque là ?
4. Parlons maintenant de sécurité. D'après ce que j'ai lu, l'id de
session peut être soit transmis dans l'URL (dangereux), soit stocké dans
un cookie sur l'ordinateur de l'utilisateur (mais nombre d'utilisateurs,
pour de mauvaises raisons en gébéral, n'aiment pas les cookies et les
refusent).
D'après ce passionnant article :
http://www.ilovejackdaniels.com/php/better-sessions/
on doit pouvoir s'en sortir en stockant l'ID de session sur le serveur
sans la faire passer dans l'URL, en utilisant l'adresse IP de la machine
appelante. Ca me plait bien comme principe, et des explications ou
renvois à des textes de référence expliquant comment procéder me
seraient d'une grande aide.
Voila, désolé d'avoir été si long et par avance un grand merci pour vos
lumières.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Frederic Rouchouze
D'après ce passionnant article : http://www.ilovejackdaniels.com/php/better-sessions/ on doit pouvoir s'en sortir en stockant l'ID de session sur le serveur sans la faire passer dans l'URL, en utilisant l'adresse IP de la machine appelante. Ca me plait bien comme principe, et des explications ou renvois à des textes de référence expliquant comment procéder me seraient d'une grande aide.
Je pense que tu n'as pas tout saisi dans cet article. Il ne s'agit pas de ne plus faire transiter l'ID entre le client et le serveur (c'est le principe même des sessions) mais de rendre plus difficile le "vol" d'ID.
Quant à utiliser uniquement l'IP du client pour identifier l'utilisateur (au lieu d'utiliser un ID de session), ça ne me semble pas plus sûr. Le "spoofing" d'adresse IP existe au même titre que le "vol" d'ID de session. Les spécialistes de la sécurité pourront probablement nous en dire plus là-dessus (je n'y connais rien).
Dans tous les cas, si tu veux construire ton propre système de gestion de sessions, tu peux utiliser la fonction http://fr.php.net/manual/fr/function.session-set-save-handler.php -- Frédéric Rouchouze mailto:
D'après ce passionnant article :
http://www.ilovejackdaniels.com/php/better-sessions/
on doit pouvoir s'en sortir en stockant l'ID de session sur le serveur
sans la faire passer dans l'URL, en utilisant l'adresse IP de la machine
appelante. Ca me plait bien comme principe, et des explications ou
renvois à des textes de référence expliquant comment procéder me
seraient d'une grande aide.
Je pense que tu n'as pas tout saisi dans cet article. Il ne s'agit pas de ne
plus faire transiter l'ID entre le client et le serveur (c'est le principe
même des sessions) mais de rendre plus difficile le "vol" d'ID.
Quant à utiliser uniquement l'IP du client pour identifier l'utilisateur (au
lieu d'utiliser un ID de session), ça ne me semble pas plus sûr. Le
"spoofing" d'adresse IP existe au même titre que le "vol" d'ID de session.
Les spécialistes de la sécurité pourront probablement nous en dire plus
là-dessus (je n'y connais rien).
Dans tous les cas, si tu veux construire ton propre système de gestion de
sessions, tu peux utiliser la fonction
http://fr.php.net/manual/fr/function.session-set-save-handler.php
--
Frédéric Rouchouze
mailto:fredchou@nospam.free.fr
D'après ce passionnant article : http://www.ilovejackdaniels.com/php/better-sessions/ on doit pouvoir s'en sortir en stockant l'ID de session sur le serveur sans la faire passer dans l'URL, en utilisant l'adresse IP de la machine appelante. Ca me plait bien comme principe, et des explications ou renvois à des textes de référence expliquant comment procéder me seraient d'une grande aide.
Je pense que tu n'as pas tout saisi dans cet article. Il ne s'agit pas de ne plus faire transiter l'ID entre le client et le serveur (c'est le principe même des sessions) mais de rendre plus difficile le "vol" d'ID.
Quant à utiliser uniquement l'IP du client pour identifier l'utilisateur (au lieu d'utiliser un ID de session), ça ne me semble pas plus sûr. Le "spoofing" d'adresse IP existe au même titre que le "vol" d'ID de session. Les spécialistes de la sécurité pourront probablement nous en dire plus là-dessus (je n'y connais rien).
Dans tous les cas, si tu veux construire ton propre système de gestion de sessions, tu peux utiliser la fonction http://fr.php.net/manual/fr/function.session-set-save-handler.php -- Frédéric Rouchouze mailto:
Frederic Rouchouze
- j'enregistre ça dans $_SESSION : $identifiant = $_SESSION['identifiant'] $Modepasse = $_SESSION['motdepasse']
Moi je teste le mot de passe dans la base de données puis je mais juste 'identifiant' dans la session. Il ne me semble pas utile de re-tester le mot de passe... Qu'en pensez-vous ? -- Frédéric Rouchouze mailto:
- j'enregistre ça dans $_SESSION :
$identifiant = $_SESSION['identifiant']
$Modepasse = $_SESSION['motdepasse']
Moi je teste le mot de passe dans la base de données puis je mais juste
'identifiant' dans la session. Il ne me semble pas utile de re-tester le mot
de passe...
Qu'en pensez-vous ?
--
Frédéric Rouchouze
mailto:fredchou@nospam.free.fr
- j'enregistre ça dans $_SESSION : $identifiant = $_SESSION['identifiant'] $Modepasse = $_SESSION['motdepasse']
Moi je teste le mot de passe dans la base de données puis je mais juste 'identifiant' dans la session. Il ne me semble pas utile de re-tester le mot de passe... Qu'en pensez-vous ? -- Frédéric Rouchouze mailto:
Eric Demeester
dans (in) fr.comp.lang.php, Frederic Rouchouze ecrivait (wrote) :
Bonjour,
Dans tous les cas, si tu veux construire ton propre système de gestion de sessions, tu peux utiliser la fonction http://fr.php.net/manual/fr/function.session-set-save-handler.php
Disons que je tiens surtout à avoir une idée aussi précise que possible du fonctionnement des sessions avant de me lancer dans le développement d'un site « sensible » y faisant largement appel.
Merci pour ce lien précieux, je sens que son étude va occuper une partie de mon week-end :)
-- Eric
dans (in) fr.comp.lang.php, Frederic Rouchouze
<fredchou@nospam.free.fr.invalid> ecrivait (wrote) :
Bonjour,
Dans tous les cas, si tu veux construire ton propre système de gestion de
sessions, tu peux utiliser la fonction
http://fr.php.net/manual/fr/function.session-set-save-handler.php
Disons que je tiens surtout à avoir une idée aussi précise que possible
du fonctionnement des sessions avant de me lancer dans le développement
d'un site « sensible » y faisant largement appel.
Merci pour ce lien précieux, je sens que son étude va occuper une partie
de mon week-end :)
dans (in) fr.comp.lang.php, Frederic Rouchouze ecrivait (wrote) :
Bonjour,
Dans tous les cas, si tu veux construire ton propre système de gestion de sessions, tu peux utiliser la fonction http://fr.php.net/manual/fr/function.session-set-save-handler.php
Disons que je tiens surtout à avoir une idée aussi précise que possible du fonctionnement des sessions avant de me lancer dans le développement d'un site « sensible » y faisant largement appel.
Merci pour ce lien précieux, je sens que son étude va occuper une partie de mon week-end :)
-- Eric
Patrick Mevzek
- j'enregistre ça dans $_SESSION : $identifiant = $_SESSION['identifiant'] $Modepasse = $_SESSION['motdepasse']
Moi je teste le mot de passe dans la base de données puis je mais juste 'identifiant' dans la session. Il ne me semble pas utile de re-tester le mot de passe... Qu'en pensez-vous ?
Cela n'apporte rien et c'est dangereux. Mieux vaut éviter de le mettre.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
- j'enregistre ça dans $_SESSION :
$identifiant = $_SESSION['identifiant']
$Modepasse = $_SESSION['motdepasse']
Moi je teste le mot de passe dans la base de données puis je mais juste
'identifiant' dans la session. Il ne me semble pas utile de re-tester le mot
de passe...
Qu'en pensez-vous ?
Cela n'apporte rien et c'est dangereux. Mieux vaut éviter de le mettre.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
- j'enregistre ça dans $_SESSION : $identifiant = $_SESSION['identifiant'] $Modepasse = $_SESSION['motdepasse']
Moi je teste le mot de passe dans la base de données puis je mais juste 'identifiant' dans la session. Il ne me semble pas utile de re-tester le mot de passe... Qu'en pensez-vous ?
Cela n'apporte rien et c'est dangereux. Mieux vaut éviter de le mettre.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Calimero
Eric Demeester wrote:
Disons que je tiens surtout à avoir une idée aussi précise que possible du fonctionnement des sessions avant de me lancer dans le développement d'un site « sensible » y faisant largement appel.
Merci pour ce lien précieux, je sens que son étude va occuper une partie de mon week-end :)
PHP génère (ou tu peux générer toi même) un ID qui est envoyé à l'utilisateur. A chaque requête ultérieure, le client renvoie cet ID. A partir de cet ID, PHP peut rechercher les informations de sessions via un backend de stockage. Le backend par défaut est un backend disque. C'est à dire que les sessions sont sérialisées puis stockées sur le disque. Inversement, on lit du disque puis on unserialize.
1. Concernant la génération automatique de l'ID de session, le lier à une IP n'a pas forcément grand intérêt: si on a un client derrière un cluster de proxies, on se retrouve avec différentes IP. Avec un proxy on peut également avoir plusieurs sessions depuis une même IP. Il n'y a donc pas forcément de relation {1,1} entre IP et session.
2. Toute variable qui peut passer dans serialize()/unserialize() pourra être stockée en variable de session: chaines, tableaux et même certains objets/classes. Il y a deux système de sérialisation, de mémoire. D'autre part, on peut stocker les sessions ailleurs que sur disque. Il y a des handlers qui utilisent des bases de données ou des systèmes à la memcached pour par exemple partager les cookies entre différentes machines (par ex si on a un cluster avec load balancer ou si on veut faire du simple round robin...).
3. Ca dépend de ce qu'on appelle tracer ?
4. La correspondance IP == session me paraît douteuse. Concernant le rejet des cookies, il me semble que la majorité des navigateurs acceptent par défaut les cookies de session (ie des cookies non persistant). C'est quand on se lance dans des cookies persistants ou des cookies dans des frames sur plusieurs domaines, etc... que les choses se gâtent.
Concernant la sécurité des sessions, y a un papier d'une quinzaine de pages PDF linké depuis la manuel PHP des sessions. Assez intéressant.
-- @+ Calimero
Eric Demeester wrote:
Disons que je tiens surtout à avoir une idée aussi précise que possible
du fonctionnement des sessions avant de me lancer dans le développement
d'un site « sensible » y faisant largement appel.
Merci pour ce lien précieux, je sens que son étude va occuper une partie
de mon week-end :)
PHP génère (ou tu peux générer toi même) un ID qui est envoyé à
l'utilisateur. A chaque requête ultérieure, le client renvoie cet ID.
A partir de cet ID, PHP peut rechercher les informations de sessions
via un backend de stockage. Le backend par défaut est un backend
disque. C'est à dire que les sessions sont sérialisées puis stockées
sur le disque. Inversement, on lit du disque puis on unserialize.
1. Concernant la génération automatique de l'ID de session, le lier à
une IP n'a pas forcément grand intérêt: si on a un client derrière un
cluster de proxies, on se retrouve avec différentes IP. Avec un proxy
on peut également avoir plusieurs sessions depuis une même IP. Il n'y
a donc pas forcément de relation {1,1} entre IP et session.
2. Toute variable qui peut passer dans serialize()/unserialize()
pourra être stockée en variable de session: chaines, tableaux et même
certains objets/classes. Il y a deux système de sérialisation, de mémoire.
D'autre part, on peut stocker les sessions ailleurs que sur disque. Il
y a des handlers qui utilisent des bases de données ou des systèmes à
la memcached pour par exemple partager les cookies entre différentes
machines (par ex si on a un cluster avec load balancer ou si on veut
faire du simple round robin...).
3. Ca dépend de ce qu'on appelle tracer ?
4. La correspondance IP == session me paraît douteuse.
Concernant le rejet des cookies, il me semble que la majorité des
navigateurs acceptent par défaut les cookies de session (ie des
cookies non persistant). C'est quand on se lance dans des cookies
persistants ou des cookies dans des frames sur plusieurs domaines,
etc... que les choses se gâtent.
Concernant la sécurité des sessions, y a un papier d'une quinzaine de
pages PDF linké depuis la manuel PHP des sessions. Assez intéressant.
Disons que je tiens surtout à avoir une idée aussi précise que possible du fonctionnement des sessions avant de me lancer dans le développement d'un site « sensible » y faisant largement appel.
Merci pour ce lien précieux, je sens que son étude va occuper une partie de mon week-end :)
PHP génère (ou tu peux générer toi même) un ID qui est envoyé à l'utilisateur. A chaque requête ultérieure, le client renvoie cet ID. A partir de cet ID, PHP peut rechercher les informations de sessions via un backend de stockage. Le backend par défaut est un backend disque. C'est à dire que les sessions sont sérialisées puis stockées sur le disque. Inversement, on lit du disque puis on unserialize.
1. Concernant la génération automatique de l'ID de session, le lier à une IP n'a pas forcément grand intérêt: si on a un client derrière un cluster de proxies, on se retrouve avec différentes IP. Avec un proxy on peut également avoir plusieurs sessions depuis une même IP. Il n'y a donc pas forcément de relation {1,1} entre IP et session.
2. Toute variable qui peut passer dans serialize()/unserialize() pourra être stockée en variable de session: chaines, tableaux et même certains objets/classes. Il y a deux système de sérialisation, de mémoire. D'autre part, on peut stocker les sessions ailleurs que sur disque. Il y a des handlers qui utilisent des bases de données ou des systèmes à la memcached pour par exemple partager les cookies entre différentes machines (par ex si on a un cluster avec load balancer ou si on veut faire du simple round robin...).
3. Ca dépend de ce qu'on appelle tracer ?
4. La correspondance IP == session me paraît douteuse. Concernant le rejet des cookies, il me semble que la majorité des navigateurs acceptent par défaut les cookies de session (ie des cookies non persistant). C'est quand on se lance dans des cookies persistants ou des cookies dans des frames sur plusieurs domaines, etc... que les choses se gâtent.
Concernant la sécurité des sessions, y a un papier d'une quinzaine de pages PDF linké depuis la manuel PHP des sessions. Assez intéressant.
