LA GESTION DES SESSIONS

Dans cette rubrique, nous étudierons un des sujets présentés dans le guide OWASP (The Open Web Application Security Project). L'OWASP est un guide qui présente les points majeurs à respecter afin de renforcer la sécurité des applications.

Nous avons choisi de vous présenter la première partie du chapitre relatif à la gestion des sessions. Les applications web dynamiques doivent utiliser un mécanisme afin de gérer au mieux les sessions des utilisateurs connectés. Une mauvaise implémentation de ce point peut avoir des conséquences importantes et augmenter les risques de piratage. Cet article abordera les points essentiels et un aperçu des règles et des meilleures pratiques afin d'assurer la sécurité des sessions.

La sécurité des sessions

Objectifs

La sécurité d'un site web repose sur de nombreux points. La gestion des session et, notamment, la solidité et la confidentialité de ces dernières sont les principaux enjeux qui permettent de définir le niveau de sécurité de l'application. Il est donc impératif que les développeurs prennent conscience de la nécessité d'assurer un contrôle permanent de l'authentification et d'assurer la robustesse de l'application face aux rejeux de paquets, aux requêtes forgées et aux insertions illicites dans les communications (man-in-the-middle).

La gestion des sessions

Contrairement aux programmes traditionnels qui stockent naturellement les données locales en mémoire allouées par le système d'exploitation sous la forme des variables dans la mémoire pile, les applications web sont basées sur un mode de fonctionnement différent. Le serveur renvoie simplement une page déterminée en fonction de la requête du client.Afin d'assurer l'étanchéité des utilisateurs et garder l'état du client connecté, les serveurs Web utilisent de plus en plus les plates-formes de développement comme J2EE ou ASP.NET,. Ces framework implémentent des mécanismes de maintient de session qui permettent de maintenir chaque utilisateur dans une session bien définie.

Une information cryptographique aléatoire et unique, partagée entre le client et le serveur (dans un cookie ou directement dans l'url), est fournie par le client dans chacune de ses requêtes. L'application web peut ainsi simuler un mode de fonctionnement basé sur des états. La capacité de maintient des utilisateurs au sein de sessions uniques et étanches est l'un des enjeux critiques pour la sécurité d'une application web. Il est important de savoir que certains langages comme Perl CGI sont dépourvus d'un tel mécanisme. Le développeur doit alors construire son propre mécanisme de conservation des sessions ce qui est coûteux et dangereux. Les plates-formes de développement telles que J2EE, PHP, ASP et ASP.NET gèrent les problématiques "bas niveaux" de la conservation de session.

Elles apportent, en parallèle, des possibilités de contrôle plus fin de la programmation plutôt que pour les configurations. (Ex: ASP.NET implémente la variable cachée "view state". Cette dernière est résistante face aux manipulations (parameters tampering). Elle est aussi présente sous la forme d'un champ caché dans chaque page web).

La génération permissive des sessions

Beaucoup de plates-formes de développement (ou "framework") génèrent automatique une nouvelle session si la requête cliente n'en possède pas. Ce comportement est appelé "génération permissive de session". Couplé avec des attaques de type phishing et un mauvais contrôle des autorisations, il est possible de réaliser des attaques dévastatrices. La création de sessions doit donc être strictement contrôlée. Il est important de s'assurer que cette session n'est pas déjà utilisée, qu'elle est bien dans l'état “déconnecté” et qu'aucun rôle ne lui est assigné par défaut. Ainsi un contrôle de validité de la session et de l'authentification doit être effectué avant tout affichage de contenu.

L'exposition des variables de session

Certaines plates-formes utilisent un répertoire partagé du serveur Web pour stocker les données de session. En particulier, PHP qui stocke par défaut ces données dans "/tmp" ou dans "C:\windows\temp" sur les systèmes Windows. Ces répertoires n'assurent pas la protection des données de session et peuvent conduire à la compromission de l'application si le serveur Web héberge plusieurs utilisateurs ou bien s'il est compromis.

Lorsque les sessions sont stockées sur le disque ou dans une base, il est important de savoir qui a accès à ses données. De plus, le serveur d'application doit être configuré de manière à ce que l'on utilise un répertoire par application. Si ça n'est pas envisageable, un chiffrement des données de session est impératif.

Les algorithmes de génération de session

Tout système de session robuste doit être pourvu d'un générateur de session efficace. Si le gestionnaire de session délivre des jetons prédictibles, un attaquant n'a même pas besoin de voler les variables de session d'un utilisateur – il suffit simplement qu'il teste plusieurs numéros de session pour voler aisément la session d'un utilisateur. Il est important que les jetons de session (ou "session-ID") soient uniques pour chaque utilisateur, non prédictibles et résistants au "reverse engineering". Il est vivement conseillé d'utiliser des générateurs connus comme Yarrow ou EGADS[1].

La durée de vie et la fin des sessions

L'@ des sessions

Les jetons de session qui n'expirent jamais laissent aux pirates une période de temps infinis pour deviner une session valide ou pour réaliser une attaque "brute-force". Par exemple, l'option "Remember Me" que l'on trouve sur beaucoup de sites de commerce en ligne. Si le cookie ou le jeton de session d'un utilisateur est volé, un attaquant peut alors utiliser ce jeton statique pour voler le compte de l'utilisateur lésé. Le problème est particulièrement critique dans un contexte publique où les stations clientes sont partagées (cybercafés, écoles, ndlr). Par ailleurs, les jetons de session peuvent être potentiellement enregistrés (loggés) et mis en cache dans les proxies : si un attaquant prend le contrôle du proxy, toutes les sessions non expirées peuvent être volées par l'attaquant. Les meilleures pratiques recommandent une utilisation de session (time out) de 5 minutes pour les applications à risque et de 20 minutes maximum pour les applications non critiques.

Le renouvellement des jetons de session

Afin de réduire le risque de vol de session ou d'attaque par brute-force, le serveur web peut, de manière continue et transparente, expirer et régénérer les jetons de session. Ce comportement réduit la fenêtre d'attaque pour les tentatives devols de session ou d'attaques par brute-force.

Les renouvellements des jetons de session doivent être effectués

• Avant toute transaction critique.
• Après un nombre déterminé de requêtes.
• Après une période de temps définie (par exemple 20 minutes).

Détection et prévention des attaques sur les jetons de session

La plupart des sites web possèdent des protections contre la tentative d'un grand nombre de mots de passe ( par exemple, le site peut temporairement bloquer un compte ou bloquer l'IP de l'attaquant ). Cependant, un attaquant peut, très souvent, tenter un très grand nombre de jetons de session avec une URL ou un cookie forgé sans que le site ne s'en aperçoive. La plupart des systèmes de détection d'intrusion (IDS) ne protègent pas contre ce type d'attaque; les tests d'intrusion ne portent généralement pas suffisamment d'égards à ce type de vulnérabilité, notamment pour les sites de commerce en ligne.

Différentes méthodes sont choisies. Certains ralentissent fortement ou bannissent carrément l'adresse IP de l'attaquant. Ce comportement peut engendrer des dommages collatéraux dans le cas où les fournisseurs d'accès Internet utilisent des caches transparents pour accélérer leurs services. (Pour cela, préférez toujours le contrôle de l'entête http proxy_via). D'autres préfèrent bloquer le compte si celui ci est défini. Enfin, un système de détection d'anomalie ou l'utilisation de module spécialisé comme "mod_dosevasive" et "mod_security" pour les serveurs Apache peuvent s'avérer utiles.

La fermeture de session

Avec la popularité croissante des cyber-cafés et autres lieux de partage de connexion Internet, les jetons de session font face à un nouveau risque. En effet, un navigateur Internet ne détruit les cookies de session que lorsque le navigateur est complètement fermé. Dans la plupart des cas, les navigateurs restent constamment ouverts même après le départ de l'utilisateur. La session de l'utilisation (côté client) doit être effacée et les cookies de session (coté serveur) écrasés dès que le client se déconnecte de l'application.    Les Meilleures Pratiques La meilleure pratique ne consiste pas à réinventer la roue mais plutôt d'utiliser un système de gestion de session robuste et standard. La plupart des environnements de développement web contiennent une API de gestion de session correcte. Cependant, les anciennes versions contenaient des vulnérabilités. C'est pourquoi il est fortement recommandé de toujours utiliser la version la plus récente de la technologie choisie (car plus performante) et de veiller aux publications de correctifs. Une recherche sur les moteurs de recherche ainsi que sur le site de l'éditeur vous permettra de définir la version la plus récente de votre plate-forme de développement

Plusieurs précautions à prendre:

• Stocker les mots de passe et les profils dans le serveur et ne jamais transiter par le navigateur client.
• Faire transiter les paramètres de navigation via l'url si ceux ci sont correctement validés et contrôlés par le serveur.
• Stocker les paramètres de présentation (comme le thème ou la langue) dans un cookie.
• Faire résider du coté serveur et ne jamais transiter dans les formulaires les données secrètes. Les données des formulaires ne doivent pas contenir d'informations secrètes et cachées. Les champs cachés doivent être utilisés pour conserver des numéros de séquence et pour prévenir des attaques par brute-force (champs conservant le nombre d'essai).

Dans le cas des formulaires à plusieurs pages, les données peuvent transiter par le côté client dans les cas suivants:

• Lorsqu'un contrôle d'intégrité est strictement effectué.
• Lorsque les données sont contrôlées et validées après chaque page ou bien lors de la dernière soumission.
• Les données secrètes (comme les mots de passe ou les droits de l'utilisateur) ne doivent jamais être modifiables par le client (aussi bien en mode GET qu'en mode POST). Ces données doivent être conservées via un numéro de session.

Les sessions sont le point d'entrée d'attaques en tout genre que nous vous présentons dans un article du mois de Décembre.

Bibliographie

[1]
Yarrow : http://www.schneier.com/yarrow.html
EGADS : http://www.securesw.com/egads/