Module Apache mod_session

Qu'est-ce qu'une session ?

Au coeur de l'interface de session se trouve une table de paires cl�/valeur qui sont accessibles d'une requ�te du navigateur � l'autre. Les valeurs de cl�s peuvent se voir affecter toute cha�ne de caract�res valide, en fonction des besoins de l'application qui fait usage de la session.

Une "session" est une cha�ne application/x-www-form-urlencoded qui contient la paire cl�/valeur d�finie par la sp�cification HTML.

Selon les souhaits de l'administrateur, la session peut �tre chiffr�e et cod�e en base64 avant d'�tre soumise au dispositif de stockage.

Qui peut utiliser une session ?

L'interface de session a �t� con�ue � l'origine pour �tre utilis�e par d'autres modules du serveur comme mod_auth_form ; les applications � base de programmes CGI peuvent cependant se voir accorder l'acc�s au contenu d'une session via la variable d'environnement HTTP_SESSION. Il est possible de modifier et/ou de mettre � jour une session en ins�rant un en-t�te de r�ponse HTTP contenant les nouveaux param�tres de session.

Stockage des sessions sur le serveur

Apache peut �tre configur� pour stocker les sessions utilisateurs sur un serveur particulier ou un groupe de serveurs. Cette fonctionnalit� est similaire aux sessions disponibles sur les serveurs d'applications courants.

Selon la configuration, les sessions sont suivies � partir d'un identifiant de session stock� dans un cookie, ou extraites de la cha�ne de param�tres de l'URL, comme dans les requ�tes GET courantes.

Comme le contenu de la session est stock� exclusivement sur le serveur, il est n�cessaire de pr�server la confidentialit� de ce contenu. Ceci a des implications en mati�re de performance et de consommation de ressources lorsqu'un grand nombre de sessions est stock�, ou lorsqu'un grand nombre de serveurs doivent se partager les sessions entre eux.

Le module mod_session_dbd permet de stocker les sessions utilisateurs dans une base de donn�es SQL via le module mod_dbd.

Stockage des sessions au niveau du navigateur

Dans les environnements � haut trafic o� le stockage d'une session sur un serveur consomme trop de ressources, il est possible de stocker le contenu de la session dans un cookie au niveau du navigateur client.

Ceci a pour avantage de ne n�cessiter qu'une quantit� minimale de ressources sur le serveur pour suivre les sessions, et �vite � plusieurs serveurs parmi une for�t de serveurs de devoir partager les informations de session.

Le contenu de la session est cependant pr�sent� au client, avec pour cons�quence un risque de perte de confidentialit�. Le module mod_session_crypto peut �tre configur� pour chiffrer le contenu de la session avant qu'elle soit stock�e au niveau du client.

Le module mod_session_cookie permet de stocker les sessions au niveau du navigateur dans un cookie HTTP.

Exemples simples

La cr�ation d'une session consiste simplement � ouvrir la session, et � d�cider de l'endroit o� elle doit �tre stock�e. Dans l'exemple suivant, la session sera stock�e au niveau du navigateur, dans un cookie nomm� session.

Session On
SessionCookieName session path=/

Une session est inutile s'il n'est pas possible d'y lire ou d'y �crire. L'exemple suivant montre comment des valeurs peuvent �tre inject�es dans une session � l'aide d'un en-t�te de r�ponse HTTP pr�d�termin� nomm� X-Replace-Session.

Session On
SessionCookieName session path=/
SessionHeader X-Replace-Session

L'en-t�te doit contenir des paires cl�/valeur sous le m�me format que celui de la cha�ne d'argument d'une URL, comme dans l'exemple suivant. Donner pour valeur � une cl� la cha�ne vide a pour effet de supprimer la cl� de la session.

#!/bin/bash
echo "Content-Type: text/plain"
echo "X-Replace-Session: key1=foo&key2=&key3=bar"
echo
env

Selon la configuration, les informations de la session peuvent �tre extraites de la variable d'environnement HTTP_SESSION. Par d�faut la session est priv�e, et cette fonctionnalit� doit donc �tre explicitement activ�e via la directive SessionEnv.

Session On
SessionEnv On
SessionCookieName session path=/
SessionHeader X-Replace-Session

Une fois la lecture effectu�e, la variable CGI HTTP_SESSION doit contenir la valeur cl�1=foo&cl�3=bar.

Confidentialit� des sessions

En utilisant la fonctionnalit� de votre navigateur "Afficher les cookies", vous pouvez voir une r�pr�sentation de la session sous forme de texte en clair. Ceci peut poser probl�me si le contenu de la session doit �tre dissimul� � l'utilisateur final, ou si un tiers acc�de sans autorisation aux informations de session.

� ce titre, le contenu de la session peut �tre chiffr� � l'aide du module mod_session_crypto avant d'�tre stock� au niveau du navigateur.

Session On
SessionCryptoPassphrase secret
SessionCookieName session path=/

La session sera automatiquement d�chiffr�e � la lecture, et rechiffr�e par Apache lors de la sauvegarde, si bien que l'application sous-jacente qui utilise la session n'a pas � se pr�occuper de savoir si un chiffrement a �t� mis en oeuvre ou non.

Les sessions stock�es sur le serveur plut�t qu'au niveau du navigateur peuvent aussi �tre chiffr�es, pr�servant par l�-m�me la confidentialit� lorsque des informations sensibles sont partag�es entre les serveurs web d'une for�t de serveurs � l'aide du module mod_session_dbd.

Confidentialit� du cookie

Le m�canisme de cookie HTTP offre aussi des fonctionnalit�s quant � la confidentialit�, comme la possibilit� de restreindre le transport du cookie aux pages prot�g�es par SSL seulement, ou l'interdiction pour les scripts java qui s'ex�cutent au niveau du navigateur d'obtenir l'acc�s au contenu du cookie.

Les param�tres standards du cookie peuvent �tre sp�cifi�s apr�s le nom du cookie comme dans l'exemple suivant :

Session On
SessionCryptoPassphrase secret
SessionCookieName session path=/private;domain=example.com;httponly;secure;

Dans les cas o� le serveur Apache sert de frontal pour des serveurs d'arri�re-plan, il est possible de supprimer les cookies de session des en-t�tes HTTP entrants � l'aide de la directive SessionCookieRemove. Ceci permet d'emp�cher les serveurs d'arri�re-plan d'acc�der au contenu des cookies de session.

Support des sessions pour l'authentification

Comme il est possible de le faire avec de nombreux serveurs d'applications, les modules d'authentification peuvent utiliser une session pour stocker le nom d'utilisateur et le mot de passe apr�s connexion. Le module mod_auth_form par exemple, sauvegarde les nom de connexion et mot de passe de l'utilisateur dans une session.

Session On
SessionCryptoPassphrase secret
SessionCookieName session path=/
AuthFormProvider file
AuthUserFile conf/passwd
AuthType form
AuthName realm
#...

Pour la documentation et des exemples complets, voir le module mod_auth_form.

Int�gration des sessions avec les applications externes

Pour que les sessions soient utiles, leur contenu doit �tre accessible aux applications externes, et ces derni�res doivent elles-m�mes �tre capables d'�crire une session.

L'exemple type est une application qui modifie le mot de passe d'un utilisateur d�fini par mod_auth_form. Cette application doit pouvoir extraire les nom d'utilisateur et mot de passe courants de la session, effectuer les modifications demand�es, puis �crire le nouveau mot de passe dans la session, afin que la transition vers le nouveau mot de passe soit transparente.

Un autre exemple met en jeu une application qui enregistre un nouvel utilisateur pour la premi�re fois. Une fois l'enregistrement termin�, le nom d'utilisateur et le mot de passe sont �crits dans la session, fournissant l� aussi une transition transparente.

Modules Apache

Selon les besoins, les modules du serveur peuvent utiliser l'API mod_session.h pour lire et �crire dans les sessions. Les modules tels que mod_auth_form utilisent ce m�canisme.

Programmes CGI et langages de script

Les applications qui s'ex�cutent au sein du serveur web peuvent �ventuellement extraire la valeur de la session de la variable d'environnement HTTP_SESSION. La session doit �tre cod�e sous la forme d'une cha�ne application/x-www-form-urlencoded selon les pr�conisations de la specification HTML. Cette variable d'environnement est d�finie via la directive SessionEnv. Un script peut �crire dans la session en renvoyant un en-t�te de r�ponse application/x-www-form-urlencoded dont le nom est d�fini via la directive SessionHeader. Dans les deux cas, tout chiffrement ou d�chiffrement, ainsi que la lecture ou l'�criture de ou vers la session � partir du m�canisme de stockage choisi sont g�r�s par le module mod_session et la configuration correspondante.

Applications situ�es derri�re mod_proxy

Si la directive SessionHeader est utilis�e pour d�finir un en-t�te de requ�te HTTP, la session cod�e sous la forme d'une cha�ne application/x-www-form-urlencoded sera accessible pour l'application. Si ce m�me en-t�te est fourni dans la r�ponse, sa valeur sera utilis�e pour remplacer la session. Comme pr�c�demment, tout chiffrement ou d�chiffrement, ainsi que la lecture ou l'�criture de ou vers la session � partir du m�canisme de stockage choisi sont g�r�s par le module mod_session et la configuration correspondante.

Applications ind�pendantes

Les applications peuvent choisir de manipuler la session en s'affranchissant du contr�le du serveur HTTP Apache. Dans ce cas, c'est l'application qui doit prendre en charge la lecture de la session depuis le m�canisme de stockage choisi, son d�chiffrement, sa mise � jour, son chiffrement et sa r��criture vers le m�canisme de stockage choisi de mani�re appropri�e.