Les sessions
Ce tutoriel est composé des parties suivantes :
Toutefois, il existe de nombreux problèmes de sécurité liés à cette fonctionnalité… Je vais donc vous parler des différents problèmes occasionnés par les sessions, ainsi que des moyens d'éviter des attaques les utilisant.
Pour cela, il suffit pour un utilisateur mal intentionné de donner un lien vers un site en précisant un identifiant de session.
Par exemple : http://www.super-site.com/?PHPSESSID=123
Dès qu'un utilisateur cliquera sur ce lien et ira sur le site en question, son identifiant de session sera mis à "123", ainsi, si il se connecte sur ce site, le pirate n'aura qu'a changer son identifiant de session pour mettre le même que celui du lien qu'il a piégé, et il sera connecté sur le compte de la victime !
Si la victime en question est un administrateur, il peut y avoir beaucoup de dégâts...
De plus, si quelqu'un poste un lien vers un site vulnérable, et qu'il oublie d'enlever son ID de session dans le lien, tout visiteur cliquant sur le lien se verra attribuer la même session (et sera donc connecté sur le même compte...).
Il ne faut donc par oublier qu'un identifiant de session est avant tout secret.
Les dégâts peuvent là-aussi être très grave !
Sur un serveur web, les sessions sont stockées dans un répertoire commun à tous les sites hébergés, les sessions sont donc communes pour tous les sites web.
Ainsi, il est possible d'accéder aux sessions appartenant à un autre site hébergé sur le même serveur, ce qui peut aussi poser des problèmes de sécurité importants.
Tout d'abord, si vous êtes hébergé sur un serveur mutualisé, il existe un moyen simple qui va vous permettre de garder vos sessions secrètes. Pour cela, il suffit simplement d'utiliser la fonction session_set_save_handler(), qui permet d'appeler une fonction que vous avez faite, et qui se chargera d'enregistrer les sessions comme vous le souhaitez, au lieu de les sauvegarder dans le répertoire par défaut.
Le mieux est d'enregistrer les sessions dans une table de votre base de données, ainsi, vous n'aurez plus de problème de sécurité, puisque vous seul pouvez accéder à votre base de données.
Pour savoir comment utiliser cette fonction, vous avez un exemple sur la page de manuel, et dans les commentaires, quelqu'un donne un exemple de code pour utiliser une base de données.
Je vais également vous présenter trois moyens (pouvant êtres combinés), qui permettent d'éviter les attaques par fixation de session, et les vols de session en général, ou au moins de diminuer les risques.
La première méthode est très simple, mais n'en est pas moins efficace ! Elle consiste à rajouter ce code après session_start() :
Dans cet exemple, j'utilise l'IP du client et son user-agent, mais vous pouvez très bien utiliser seulement l'IP ou l'user-agent.
Un autre moyen, très simple, consiste à utiliser session_regenerate_id() pour régénérer l'identifiant de session de l'utilisateur, je vous recommande de régénérer l'ID de session à la connexion : Ça peut permettre d'éviter les attaques par fixation de session.
La dernière méthode consiste à changer la configuration de PHP afin d'améliorer la sécurité des sessions :
Dans le fichier php.ini, modifiez cette directive de configuration, pour lui mettre la valeur suivante :
Une seconde directive intéressante à modifier est la suivante :
Pour plus d'informations, je vous laisse avec le manuel PHP
Si vous êtes sur un serveur mutualisé et que vous ne pouvez pas modifier php.ini, il existe la fonction ini_set() qui permet de faire des modifications toute la durée du script.
Introduction
Aujourd'hui, de nombreux sites utilisent les sessions, c'est un moyen très pratique de conserver des informations sur un visiteur lorsqu'il se promène sur un site.Toutefois, il existe de nombreux problèmes de sécurité liés à cette fonctionnalité… Je vais donc vous parler des différents problèmes occasionnés par les sessions, ainsi que des moyens d'éviter des attaques les utilisant.
Fixation de sessions
Il existe une attaque, nommée la fixation de sessions, qui permet de récupérer la session d'un utilisateur :Pour cela, il suffit pour un utilisateur mal intentionné de donner un lien vers un site en précisant un identifiant de session.
Par exemple : http://www.super-site.com/?PHPSESSID=123
Dès qu'un utilisateur cliquera sur ce lien et ira sur le site en question, son identifiant de session sera mis à "123", ainsi, si il se connecte sur ce site, le pirate n'aura qu'a changer son identifiant de session pour mettre le même que celui du lien qu'il a piégé, et il sera connecté sur le compte de la victime !
Si la victime en question est un administrateur, il peut y avoir beaucoup de dégâts...
De plus, si quelqu'un poste un lien vers un site vulnérable, et qu'il oublie d'enlever son ID de session dans le lien, tout visiteur cliquant sur le lien se verra attribuer la même session (et sera donc connecté sur le même compte...).
Il ne faut donc par oublier qu'un identifiant de session est avant tout secret.
XSS
Un second risque lié a l'utilisation de sessions est la faille XSS : Si un pirate découvre une faille XSS, il n'a plus qu'a faire un code qui va envoyer l'ID de session a une page qu'il a créé, et il pourra récupérer plein de sessions, et prendre le contrôle de très nombreux comptes !Les dégâts peuvent là-aussi être très grave !
Serveur mutualisé
Si votre site est hébergé sur un serveur mutualisé, il existe aussi un risque assez important.Sur un serveur web, les sessions sont stockées dans un répertoire commun à tous les sites hébergés, les sessions sont donc communes pour tous les sites web.
Ainsi, il est possible d'accéder aux sessions appartenant à un autre site hébergé sur le même serveur, ce qui peut aussi poser des problèmes de sécurité importants.
Protection
Comme nous venons de le voir, les sessions posent donc de nombreux problèmes de sécurité.Tout d'abord, si vous êtes hébergé sur un serveur mutualisé, il existe un moyen simple qui va vous permettre de garder vos sessions secrètes. Pour cela, il suffit simplement d'utiliser la fonction session_set_save_handler(), qui permet d'appeler une fonction que vous avez faite, et qui se chargera d'enregistrer les sessions comme vous le souhaitez, au lieu de les sauvegarder dans le répertoire par défaut.
Le mieux est d'enregistrer les sessions dans une table de votre base de données, ainsi, vous n'aurez plus de problème de sécurité, puisque vous seul pouvez accéder à votre base de données.
Pour savoir comment utiliser cette fonction, vous avez un exemple sur la page de manuel, et dans les commentaires, quelqu'un donne un exemple de code pour utiliser une base de données.
Je vais également vous présenter trois moyens (pouvant êtres combinés), qui permettent d'éviter les attaques par fixation de session, et les vols de session en général, ou au moins de diminuer les risques.
La première méthode est très simple, mais n'en est pas moins efficace ! Elle consiste à rajouter ce code après session_start() :
Code : PHP
$identifiant = md5($_SERVER['REMOTE_ADDR'].$_SERVER['HTTP_USER_AGENT']);
if(! isset($_SESSION['identifiant']))
$_SESSION['identifiant'] = $identifiant;
elseif($_SESSION['identifiant'] != $identifiant)
{
// Rediriger vers une page qui va redemander le mot de passe à l'utilisateur, ou le déconnecter
die('IP ou User-agent modifié !');
}
Grâce à ce code, chaque session a un propriétaire unique, définit par son IP et son user-agent, ce qui rend impossible les attaquer par fixation de session, par faille XSS, ou tout autre vol de session. if(! isset($_SESSION['identifiant']))
$_SESSION['identifiant'] = $identifiant;
elseif($_SESSION['identifiant'] != $identifiant)
{
// Rediriger vers une page qui va redemander le mot de passe à l'utilisateur, ou le déconnecter
die('IP ou User-agent modifié !');
}
Dans cet exemple, j'utilise l'IP du client et son user-agent, mais vous pouvez très bien utiliser seulement l'IP ou l'user-agent.
Un autre moyen, très simple, consiste à utiliser session_regenerate_id() pour régénérer l'identifiant de session de l'utilisateur, je vous recommande de régénérer l'ID de session à la connexion : Ça peut permettre d'éviter les attaques par fixation de session.
La dernière méthode consiste à changer la configuration de PHP afin d'améliorer la sécurité des sessions :
Dans le fichier php.ini, modifiez cette directive de configuration, pour lui mettre la valeur suivante :
Code : php.ini
session.use_only_cookies = 1
Ainsi, les attaques par fixation deviendront impossible, puisque les sessions fonctionneront seulement avec les cookies.Une seconde directive intéressante à modifier est la suivante :
Code : php.ini
session.cookie_httponly = 1
Cette directive va indiquer au navigateur que les cookies doivent être seulement accessibles en HTTP, et ne doivent pas l'être avec Javascript, ainsi, en cas de faille XSS, les sessions seront protégées.Pour plus d'informations, je vous laisse avec le manuel PHP
Si vous êtes sur un serveur mutualisé et que vous ne pouvez pas modifier php.ini, il existe la fonction ini_set() qui permet de faire des modifications toute la durée du script.
