This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "4.7.6 Tester les fonctionnalités de déconnexion (OTG-SESS-006)"

From OWASP
Jump to: navigation, search
(No difference)

Revision as of 17:12, 26 November 2014

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

La fin d'une session est une partie importante du cycle de vie d'une session. Réduire au minimum la durée de vie des jetons de session réduit les chances de réussite d'une attaque de détournement de session. Cela peut être vu comme un contrôle visant à prévenir les attaques Cross Site Scripting et Cross Site Request Forgery. De telles attaques sont connues pour reposer sur l'existence d'une session authentifiée. Ne pas avoir de mécanisme de fin de session sécurisé ne fait qu'accroitre la surface d'attaque.


Une fin de session sécurisée nécessite au moins les composants suivants :

  • Dispobilité de contrôles dans l'interface utilisateur permettant de se déconnecter manuellement.
  • Fin de session automatique après un certain temps d'inactivité (session timeout).
  • Invalidation correcte de l'état de la session côté serveur.


De multiples problèmes peuvent empêcher la fin effective d'une session. Dans une applucation web idéalement sécurisée, un utilisateur devrait pouvoir terminer sa session à n'importe quel moment, via l'interface utilisateur. Chaque page devrait inclure un bouton de déconnexion, directement visible. Des fonctions de déconnexion ambigues ou manquant de clarté peuvent entraîner un manque de confiance chez l'utilisateur.


Une autre erreur commune dans les fins de session est de donner une nouvelle valeur au jeton de session alors que l'état côté serveur demeure actif et peut être réutilisé en redonnant son ancienne valeur au cookie de session. Parfois, seule un message de confirmation est montré à l'utilisateur sans autre action. Cela doit être évité.


Certains frameworks d'application web reposent seulement sur le cookie de session pour identifier un utilisateur connecté. L'identifiant d'utilisateur est inclu dans la valeur (chiffrée) du cookie. Le serveur d'application ne fait aucun suivi de la session côté serveur. Lors de la déconnexion, le cookie est supprimé du navigateur. Cependant, comme l'application ne fait aucun suivi, elle ne sait pas si la session est déconnectée ou pas. Ainsi, en réutilisant le cookie il est possible d'accéder à la session authentifiée. La fonctionnalité Forms Authentication (authentification par formulaire) d'ASP.NET en est un exemple bien connu.


Les utilisateur de navigateurs web ne se soucient souvent pas qu'une application soit encore ouverte et ferment simplement le navigateur ou un onglet. Une application web devrait prendre en compte ce comportement et terminer la session automatiquement côté serveur après un temps défini.


L'utilisation d'un système de single sign-on (SSO) au lieu d'un mécanisme spécifique d'authentification entraîne souvent l'existence de plusieurs sessions qui doivent être terminées séparément. Par exemple, la fin d'une session spécifique à l'application ne termine pas la session dans le système SSO. En naviguant à nouveau sur le portail SSO, l'utilisateur a la possibilité de se reconnecter sur l'application d'où il s'était déconnecté précédemment. D'autre part, la fonction de déconnexion du système SSO n'entraîne pas forcément la fin des sessions sur les applications connectées.


Comment tester

Tester l'interface utilisateur de déconnexion :
Vérifier l'apparence et la visibilité de la fonctionnalité de déconnexion dans l'interface utilisateur. Pour cela, il faut regarder chaque page avec le point de vue d'un utilisateur qui a l'intention de se déconnecter de l'application web.


Résultat attendu :
Une bonne interface de déconnexion a certaine propriétés :

  • Un bouton de déconnexion présent sur toutes les pages de l'application.
  • Le bouton de déconnexion doit être rapidement reconnaissable par l'utilisateur voulant se déconnecter de l'application web.
  • Après le chargement de la page, le bouton de déconnexion doit être visible sans avoir à faire défiler le contenu.
  • Idéalement, le bouton de déconnexion sera placé dans une zone fixe de la page, et ne sera pas affectée par le défilement du contenu.


Tester les fins de session côté serveur :
D'abord, stocker toutes les valeurs de cookies servant à identifier une session. Appeler la fonction de déconnexion et observer le comportement de l'application, plus précisémment ce qui concerne les cookies de session. Essayer de naviguer sur une page qui n'est visible qu'avec une session authentifiée, par exemple avec le bouton retour du navigateur.Si la page en cache est affichée, utiliser le bouton de rafraîchissement pour recharger la page depuis le serveur. Si la fonction de déconnexion change la valeur des cookies de session, restaurer les anciennes valeurs des cookies de session et recharger une page depuis la zone authentifiée de l'application. Si ces tests ne montrent pas de vulnérabilités sur une page particulière, il faut tester au moins quelques autres pages considérées comme critiques, pour assurer que la fin de la session est reconnue correctement dans ces parties de l'application.


Résultat attendu :
Aucune donnée limitée aux utilisateurs authentifiés ne devrait être visible sur les pages examinées pendant les tests. Idéalement, lorsque l'on accède à une partie authentifiée après la fin de la session, l'application doit rediriger vers une partie publique ou un formulaire de connexion. Cela ne devrait pas être nécessaire à la sécurisation de l'application, mais changer les valeurs des cookies de session après déconnexion est généralement considéré comme une bonne pratique.


Tester les expiration de session :
Essayer de déterminer la limite d'expiration d'une session en accèdant à la partie authentifiée de l'application web à des intervalles de temps croissants. Si le comportement de déconnexion apparaît, le délai utilisé correspond à peu près à la durée de vie de la session.


Résultat attendu:
Les mêmes résultats que pour la fin de session côté serveur, décrits plus haut, sont attendus après une déconnexion due à une inactivité.


La durée de vie correcte d'une session dépend de l'usage de l'application et doit être un compromis entre sécurité et facilité d'utilisation. Dans une application bancaire, cela n'a pas de sens de garder une session inactive plus de 15 minutes. Par contre, une durée trop courte sur un wiki ou un forum risque d'importuner les utilisateurs qui saisissent des articles longs avec des demandes de reconnexion inutiles. Dans ce cas, une durée de plus d'une heure peut être acceptable.


Tester les fins de session en environnement SSO (single sign-off) :
Il faut se déconnecter de l'application. Vérifier si le portail central ou l'annuaire d'application permet à l'utilisateur de se reconnecter à l'application sans authentification. Tester si l'application demande à l'utilisateur de s'authentifier si l'URL ou un point d'entrée de l'application est accédé. Une fois connecté de l'application, il faut se déconnecter du système SSO, puis essayer d'accéder à des parties authentifiées de l'application.


Résultat attendu :
Une déconnexion de l'application connectée à un système SSO ou une déconnexion du système SSO doit entraîner la fin de toutes les sessions. Une nouvelle authentification doit être demandée pour accéder à l'application après déconnexion du SSO et de l'application.


Outils

References

Whitepapers


Retrieved from "https://wiki.owasp.org/index.php?title=4.7.6_Tester_les_fonctionnalités_de_déconnexion_(OTG-SESS-006)&oldid=186086"