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
(Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == Session termination is an important part of the session lifecycle. Reducing to a minimum the lifetime of the session token...")
 
 
(2 intermediate revisions by the same user not shown)
Line 3: Line 3:
  
 
== Sommaire ==
 
== Sommaire ==
−
Session termination is an important part of the session lifecycle. Reducing to a minimum the lifetime of the session tokens decreases the likelihood of a successful session hijacking attack. This can be seen as a control against preventing other attacks like Cross Site Scripting and Cross Site Request Forgery. Such attacks have been known to rely on a user having an authenticated session present. Not having a secure session termination only increases the attack surface for any of these attacks.  
+
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 en effet 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'accroître la surface d'attaque.
  
  
−
A secure session termination requires at least the following components:
+
Une fin de session sécurisée nécessite au moins les éléments suivants :
  
−
* Availability of user interface controls that allow the user to manually log out.
+
* Existence d'une interface utilisateur permettant explicitement de se déconnecter.
−
* Session termination after a given amount of time without activity (session timeout).
+
* Fin de session automatique après un certain temps d'inactivité (session timeout).
−
* Proper invalidation of server-side session state.
+
* Désactivation effective de la session côté serveur.
  
  
−
There are multiple issues which can prevent the effective termination of a session. For the ideal secure web application, a user should be able to terminate at any time through the user interface. Every page should contain a log out button on a place where it is directly visible. Unclear or ambiguous log out functions could cause the user not trusting such functionality.
+
De multiples problèmes peuvent empêcher une fin efficace d'une session. Dans une application 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 ambiguës ou manquant de clarté peuvent entraîner un manque de confiance de l'utilisateur dans leur efficacité.
  
  
−
Another common mistake in session termination is that the client-side session token is set to a new value while the server-side state remains active and can be reused by setting the session cookie back to the previous value. Sometimes only a confirmation message is shown to the user without performing any further action. This should be avoided.  
+
Une autre erreur commune dans les fins de session est renouveler jeton de session côté client alors que l'état côté serveur demeure actif et peut être réutilisé en redonnant son ancienne valeur au cookie de session. Parfois, aucune action n'est effectuée à part l'envoi d'un message de confirmation à l'utilisateur. Cela doit être évité.
  
  
−
Some web application frameworks rely solely on the session cookie to identify the logged-on user. The user's ID is embedded in the (encrypted) cookie value. The application server does not do any tracking on the server-side of the session. When logging out, the session cookie is removed from the browser. However, since the application does not do any tracking, it does not know whether a session is logged out or not. So by reusing a session cookie it is possible to gain access to the authenticated session. A well-known example of this is the Forms Authentication functionality in ASP.NET.
+
Certains environnements d'application web reposent seulement sur le cookie de session pour identifier un utilisateur connecté. L'identifiant d'utilisateur est inclus 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.
  
  
−
Users of web browsers often don't mind that an application is still open and just close the browser or a tab. A web application should be aware of this behavior and terminate the session automatically on the server-side after a defined amount of time.
+
Il arrive que les utilisateurs de navigateurs web ne se soucient pas qu'une application reste ouverte ou pas 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 délai déterminé.
  
  
−
The usage of a single sign-on (SSO) system instead of an application-specific authentication scheme often causes the coexistence of multiple sessions which have to be terminated separately. For instance, the termination of the application-specific session does not terminate the session in the SSO system. Navigating back to the SSO portal offers the user the possibility to log back in to the application where the log out was performed just before. On the other side a log out function in a SSO system does not necessarily cause session termination in connected applications.
+
L'utilisation d'un système d'authentification unique (single sign-on SSO) à la place d'une authentification par l'application entraîne souvent l'existence de plusieurs sessions qui doivent être terminées séparément. Par exemple, la fin d'une session applicative 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.
  
−
== How to Test ==
 
−
'''Testing for log out user interface:'''<br>
 
−
Verify the appearance and visibility of the log out functionality in the user interface. For this purpose, view each page from the perspective of a user who has the intention to log out from the web application.
 
  
 +
== Comment tester ==
 +
'''Tester l'interface utilisateur de déconnexion :'''<br>
 +
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.
  
−
'''Result Expected:'''<br>
 
−
There are some properties which indicate a good log out user interface:
 
−
* A log out button is present on all pages of the web application.
 
−
* The log out button should be identified quickly by a user who wants to log out from the web application.
 
−
* After loading a page the log out button should be visible without scrolling.
 
−
* Ideally the log out button is placed in an area of the page that is fixed in the view port of the browser and not affected by scrolling of the content.
 
  
 +
'''Résultat attendu :'''<br>
 +
Une bonne interface de déconnexion a certaines propriétés :
 +
* Un bouton de déconnexion doit être 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, qui ne doit pas être modifiée par le défilement du contenu.
  
−
'''Testing for server-side session termination:'''<br>
 
−
First, store the values of cookies that are used to identify a session. Invoke the log out function and observe the behavior of the application, especially regarding session cookies. Try to navigate to a page that is only visible in an authenticated session, e.g. by usage of the back button of the browser. If a cached version of the page is displayed, use the reload button to refresh the page from the server. If the log out function causes session cookies to be set to a new value, restore the old value of the session cookies and reload a page from the authenticated area of the application. If these test don't show any vulnerabilities on a particular page, try at least some further pages of the application that are considered as security-critical, to ensure that session termination is recognized properly by these areas of the application.
 
  
 +
'''Tester les fins de session côté serveur :'''<br>
 +
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, et, en particulier, 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 c'est la version en cache de la page qui est affichée, utiliser le bouton de rafraîchissement pour recharger la page depuis le serveur. Si la fonction de déconnexion renouvelle les cookies de session, restaurer les anciennes valeurs des cookies de session et recharger une page d'une 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 s'assurer que la fin de session s'effectue correctement dans ces parties de l'application.
  
−
'''Result Expected:'''<br>
 
−
No data that should be visible only by authenticated users should be visible on the examined pages while performing the tests. Ideally the application redirects to a public area or a log in form while accessing authenticated areas after termination of the session. It should be not necessary for the security of the application, but setting session cookies to new values after log out is generally considered as good practice.
 
  
 +
'''Résultat attendu :'''<br>
 +
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 une page 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.
  
−
'''Testing for session timeout:'''<br>
 
−
Try to determine a session timeout by performing requests to a page in the authenticated area of the web application with increasing delays. If the log out behavior appears, the used delay matches approximately the session timeout value.
 
  
 +
'''Tester les délais d'expiration de session :'''<br>
 +
Essayer de déterminer le délai d'expiration d'une session en accédant à la zone authentifiée de l'application web à des intervalles de temps croissants. La durée de vie de la session correspond approximativement au délai constaté au moment de la déconnexion.
  
−
'''Result Expected:'''<br>
 
−
The same results as for server-side session termination testing described before are excepted by a log out caused by an inactivity timeout.
 
  
 +
'''Résultat attendu:'''<br>
 +
Les mêmes résultats que pour les tests de fin de session côté serveur, décrits plus haut, sont attendus après une déconnexion due à une inactivité.
  
−
The proper value for the session timeout depends on the purpose of the application and should be a balance of security and usability. In a banking applications it makes no sense to keep an inactive session more than 15 minutes. On the other side a short timeout in a wiki or forum could annoy users which are typing lengthy articles with unnecessary log in requests. There timeouts of an hour and more can be acceptable.
 
  
 +
Le délai d'expiration 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 d'une heure ou plus peut être acceptable.
  
−
'''Testing for session termination in single sign-on environments (single sign-off):'''<br>
 
−
Perform a log out in the tested application. Verify if there is a central portal or application directory which allows the user to log back in to the application without authentication. Test if the application requests the user to authenticate, if the URL of an entry point to the application is requested. While logged in in the tested application, perform a log out in the SSO system. Then try to access an authenticated area of the tested application.
 
  
 +
'''Tester les fins de session en environnement d'authentification unique SSO (single sign-off) :'''<br>
 +
D'abord, se déconnecter de l'application. Vérifier ensuite 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 lorsqu'il accéde à une URL d'entrée de l'application. Une fois connecté à l'application, il faut se déconnecter du système SSO, puis essayer d'accéder à des parties authentifiées de l'application.
  
−
'''Result Expected:'''<br>
 
−
It is expected that the invocation of a log out function in a web application connected to a SSO system or in the SSO system itself causes global termination of all sessions. An authentication of the user should be required to gain access to the application after log out in the SSO system and connected application.
 
  
 +
'''Résultat attendu :'''<br>
 +
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.
  
−
==Tools==
+
 
 +
==Outils==
 
* "Burp Suite - Repeater" - http://portswigger.net/burp/repeater.html
 
* "Burp Suite - Repeater" - http://portswigger.net/burp/repeater.html
  
−
== References ==
+
== Références ==
 
'''Whitepapers'''
 
'''Whitepapers'''
−
* "The FormsAuthentication.SignOut method does not prevent cookie reply attacks in ASP.NET applications" - http://support.microsoft.com/default.aspx?scid=kb;en-us;900111
+
* "La méthode FormsAuthentication.SignOut ne protège pas des attaques par rejeu de cookies dans les applications ASP.NET" - http://support.microsoft.com/default.aspx?scid=kb;en-us;900111
−
* "Cookie replay attacks in ASP.NET when using forms authentication" - https://www.vanstechelman.eu/content/cookie-replay-attacks-in-aspnet-when-using-forms-authentication
+
* "Attaques par rejeu de cookies dans ASP.NET en utilisant les formulaires d'authentification" - https://www.vanstechelman.eu/content/cookie-replay-attacks-in-aspnet-when-using-forms-authentication
 
<br>
 
<br>

Latest revision as of 14:27, 13 January 2015

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 en effet 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'accroître la surface d'attaque.


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

  • Existence d'une interface utilisateur permettant explicitement de se déconnecter.
  • Fin de session automatique après un certain temps d'inactivité (session timeout).
  • Désactivation effective de la session côté serveur.


De multiples problèmes peuvent empêcher une fin efficace d'une session. Dans une application 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 ambiguës ou manquant de clarté peuvent entraîner un manque de confiance de l'utilisateur dans leur efficacité.


Une autre erreur commune dans les fins de session est renouveler jeton de session côté client alors que l'état côté serveur demeure actif et peut être réutilisé en redonnant son ancienne valeur au cookie de session. Parfois, aucune action n'est effectuée à part l'envoi d'un message de confirmation à l'utilisateur. Cela doit être évité.


Certains environnements d'application web reposent seulement sur le cookie de session pour identifier un utilisateur connecté. L'identifiant d'utilisateur est inclus 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.


Il arrive que les utilisateurs de navigateurs web ne se soucient pas qu'une application reste ouverte ou pas 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 délai déterminé.


L'utilisation d'un système d'authentification unique (single sign-on SSO) à la place d'une authentification par l'application entraîne souvent l'existence de plusieurs sessions qui doivent être terminées séparément. Par exemple, la fin d'une session applicative 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 certaines propriétés :

  • Un bouton de déconnexion doit être 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, qui ne doit pas être modifié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, et, en particulier, 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 c'est la version en cache de la page qui est affichée, utiliser le bouton de rafraîchissement pour recharger la page depuis le serveur. Si la fonction de déconnexion renouvelle les cookies de session, restaurer les anciennes valeurs des cookies de session et recharger une page d'une 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 s'assurer que la fin de session s'effectue 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 une page 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 délais d'expiration de session :
Essayer de déterminer le délai d'expiration d'une session en accédant à la zone authentifiée de l'application web à des intervalles de temps croissants. La durée de vie de la session correspond approximativement au délai constaté au moment de la déconnexion.


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


Le délai d'expiration 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 d'une heure ou plus peut être acceptable.


Tester les fins de session en environnement d'authentification unique SSO (single sign-off) :
D'abord, se déconnecter de l'application. Vérifier ensuite 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 lorsqu'il accéde à une URL d'entrée de l'application. Une fois connecté à 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

Références

Whitepapers


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