4.7.7 Tester l'expiration de session (OTG-SESS-007)

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

Sommaire

Dans cette phase, les testeurs vont vérifier que l'application déconnecte automatiquement une utilisateur qui a été inactif depuis un certain temps, assurant ainsi qu'il n'est pas possible de "réutiliser" la même session, et qu'aucune donnée sensible de reste stockée dans le cache du navigateur.

Toutes les applications devraient implémenter une limite d'inactivité sur les sessions. Cette limite définit le temps qu'une session restera active alors qu'il n'y a pas d'activité de l'utilisateur, après ce temps d'inactivité (depuis la dernière requête HTTP de la session considérée), la session sera fermée et invalidée. La limite la plus appropriée doit être un compromis entre la sécurité (limite plus courte) et le confort d'utilisation (limite plus longue), et dépend fortement du niveau de sensibilité des données manipulées par l'application. Par exemple, une limite de 60 minute peut être acceptable pour un forum public, mais pas pour une application bancaire (dans ce cas, un maximum de 15 minutes est recommandé). Dans tous les cas, une application qui ne force pas de déconnexion en cas d'inactivité doit être considérée comme non sécurisée, sauf si un tel comportement est spécifiquement requis fonctionnellement.

L'expiration de session limite les chances qu'un attaquant puisse deviner et utiliser un identifiant de session appartenant à un autre utilisateur, et dans certaines circonstances, peut protéger les ordinateurs publics contre la réutilisation de session. Cependant, si l'attaquant peut détourner une session donnée, l'expiration ne pourra rien pour limiter ses actions, puisqu'il peut générer périodiquement de l'activité sur la session afin de la garder active plus longtemps.

Le management des expirations de sessions doit être fait côté serveur. si certaines données contrôlées par le client sont utilisées pour imposer l'expiration de session, par exemple les valeurs de cookie ou autre paramètres client pour mesurer des références temporelles (par exemple, le nombre de minutes depuis la connexion), un attaquant pourrait manipuler ces données pour étendre la durée d'une session. L'application doit donc suivre la durée d'inactivité côté serveur et, une fois la limite atteinte, invalider automatiquement la session courante de l'utilisateur puis supprimer toutes les données stockées côté client.

Ces deux actions doivent être implémentées avec précaution, afin de d'aviter d'introduire des faiblesses qui pourraient être exploitée par un attaquant pour obtenir un accès si l'utilisateur oublie de se déconnecter de l'application. Plus précisémment, comme pour la fonction de déconnexion, il est important d'assurer que tous les jetons de ssion (par exemple les cookies) sont correctement détruits ou rendus inutilisables, et que des contrôles corrects sont appliqués côté serveur pour empêcher la réutilisation de jetons de session. Si de telles actions ne sont pas appliquées correctement, un attaquant pourrait rejouer ces jetons de session afin de "ressuciter" la session d'un utilisateur légitime et usurper son identité (cette attaque est communément nommée 'cookie replay'). Le fait que l'attaquant ait besoin d'accéder à ces jetons de session (stockés sur le PC de la victime) est bien sûr un facteur limitant, mais dans certains cas, cela n'a rien de particulièrement difficile.

Le scénario le plus commun pour ce genre d'attaques met en jeu un ordinateur public utilisé pour accéder à des informations privées (par exemple : webmail, compte bancaire en ligne). Si l'utilisateur laisse l'ordinateur sans se déconnecter explicitement, et qu'aucune expiration de session n'est implémentée par l'application, alors un attaquant peut accéder au même compte en pressant simplement le bouton "retour" du navigateur.

Comment tester

Test en boite noire

La même approche que dans la section 4.7.6 Tester les fonctionnalités de déconnexion (OTG-SESS-006) peut être utilisée pour mesurer les déconnexions par expiration.

La méthodologie de test est très similaire. D'abord le tester doit vérifier qu'un expiration existe, par exemple en se connectant et en attendant que la déconnexion automatique soit déclenchée. Comme pour la fonction de déconnexion, après expiration, tous les jetons de session doivent être détruits ou inutilisables.

Ensuite, si l'expiration est configurée, le tester doit comprendre si elle est imposée par le client ou par le serveur (ou par les deux). Si le cookie de session est non-persistent (ou , plus généralement, le cookie de session ne contient pas de données temporelles), le tester peut considérer que l'expiration est imposée par le serveur. Si le cookie de session contient des données liées au temps (par exemple heure de connexion, date d'expiration d'un cookie persistant), alors il est possible que le client soit impliqué dans la gestion de l'expiration. Dans ce cas, le tester peut essayer de modifier le cookie (s'il n'est pas protégé cryptographiquement) et voir ce qui arrive à la session. Par exemple, le tester peut configurer une date d'expiration éloignée dans le futur et regarder si la session a pu être prolongée.

En règle générale, tout devrait être vérifié côté serveur, et il ne devrait pas être possible d'accéder de nouveau à l'application en restaurant les anciennes valeurs de cookies de session.

Test en boite grise

Le testeur doit vérifier que :

• LA fonction de déconnexion détruit tous les jetons de session, ou au moins les rend inutilisables.
• Le serveur vérifie correctement l'état des sessoins, empêchant un attaquant de rejouer des identifiants de sessions détruits.
• une expiration est imposée correctement par le serveur. Si le serveur utilise une limite d'expiration qui est lue depuis un jeton de session envoyé par le client (ce qui n'est pas conseillé), alors ce jeton doit être cryptographiquement protégé contre les manipulations.

A noter que le plus important pour l'application est d'invalider les session côté serveur. Généralement cela signifie que le code doit invoquer les méthodes appropriées, par exemple HttpSession.invalidate() en Java et Session.abandon() en .NET. Supprimer les cookies du navigateur est conseillé, mas pas stricement nécessaire; puisque si la session est connrectement invalidée sur la serveur, la possession des cookies n'aidera pas l'attaquant.

References

OWASP Resources

• Session Management Cheat Sheet