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

Jcpraud: Corrections

2015-07-05T15:15:57Z

Corrections

Jcpraud at 17:54, 26 November 2014

2014-11-26T17:54:10Z

Jcpraud: Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == Dans cette phase, les testeurs vont vérifier que l'application déconnecte automatiquement une utilisateur qui a été in..."

2014-11-26T17:13:34Z

Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == Dans cette phase, les testeurs vont vérifier que l'application déconnecte automatiquement une utilisateur qui a été in..."

New page

{{Template:OWASP Testing Guide v4}}

== 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.

La
The idle timeout limits the chances that an attacker has to guess and use a valid session ID from another user, and under certain circumstances could protect public computers from session reuse. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time.

Session timeout management and expiration must be enforced server-side. If some data under the control of the client is used to enforce the session timeout, for example using cookie values or other client parameters to track time references (e.g. number of minutes since log in time), an attacker could manipulate these to extend the session duration. So the application has to track the inactivity time on the server side and, after the timeout is expired, automatically invalidate the current user's session and delete every data stored on the client.

Both actions must be implemented carefully, in order to avoid introducing weaknesses that could be exploited by an attacker to gain unauthorized access if the user forgot to log out from the application. More specifically, as for the log out function, it is important to ensure that all session tokens (e.g. cookies) are properly destroyed or made unusable, and that proper controls are enforced at the server side to prevent the reuse of session tokens. If such actions are not properly carried out, an attacker could replay these session tokens in order to “resurrect” the session of a legitimate user and impersonate him/her (this attack is usually known as 'cookie replay'). Of course, a mitigating factor is that the attacker needs to be able to access those tokens (which are stored on the victim's PC), but, in a variety of cases, this may not be impossible or particularly difficult.

The most common scenario for this kind of attack is a public computer that is used to access some private information (e.g., web mail, online bank account). If the user moves away from the computer without explicitly logging out and the session timeout is not implemented on the application, then an attacker could access to the same account by simply pressing the “back” button of the browser.

==How to Test==

=== Black Box testing ===
The same approach seen in the [[Testing for logout functionality (OTG-SESS-006)]] section can be applied when measuring the timeout log out.
<br>

The testing methodology is very similar. First, testers have to check whether a timeout exists, for instance, by logging in and waiting for the timeout log out to be triggered. As in the log out function, after the timeout has passed, all session tokens should be destroyed or be unusable.

Then, if the timeout is configured, testers need to understand whether the timeout is enforced by the client or by the server (or both). If the session cookie is non-persistent (or, more in general, the session cookie does not store any data about the time), testers can assume that the timeout is enforced by the server. If the session cookie contains some time related data (e.g., log in time, or last access time, or expiration date for a persistent cookie), then it's possible that the client is involved in the timeout enforcing. In this case, testers could try to modify the cookie (if it's not cryptographically protected) and see what happens to the session. For instance, testers can set the cookie expiration date far in the future and see whether the session can be prolonged.

As a general rule, everything should be checked server-side and it should not be possible, by re-setting the session cookies to previous values, to access the application again.
<br>

=== Gray Box Testing ===
<br>
The tester needs to check that:
* The log out function effectively destroys all session token, or at least renders them unusable,
* The server performs proper checks on the session state, disallowing an attacker to replay previously destroyed session identifiers
* A timeout is enforced and it is properly enforced by the server. If the server uses an expiration time that is read from a session token that is sent by the client (but this is not advisable), then the token must be cryptographically protected from tampering.

Note that the most important thing is for the application to invalidate the session on the server side. Generally this means that the code must invoke the appropriate methods, e.g. HttpSession.invalidate() in Java and Session.abandon() in .NET. Clearing the cookies from the browser is advisable, but is not strictly necessary, since if the session is properly invalidated on the server, having the cookie in the browser will not help an attacker.

== References ==
'''OWASP Resources'''
* [[Session Management Cheat Sheet]]

@@ Line 3: / Line 3: @@
 == 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.
+Dans cette phase, les testeurs vont vérifier que l'application déconnecte automatiquement une utilisateur qui a été inactif depuis un certain temps, garantissant ainsi qu'il n'est pas possible de "réutiliser" la même session, et qu'aucune donnée sensible ne 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.
+Toutes les applications devraient implémenter une limite d'inactivité sur les sessions. Cette limite définit le délai pendant lequel une session restera active alors qu'il n'y a pas d'activité de l'utilisateur, et la session sera fermée et invalidée passé ce délai d'inactivité après la dernière requête HTTP reçue par l’application web pour une session donné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 minutes 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.
+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, le délai d'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.
+La gestion 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 autres 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.
+Ces deux actions doivent être implémentées avec précaution, afin de d'éviter 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ément, comme pour la fonction de déconnexion, il est important de s'assurer que tous les jetons de session (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 leur réutilisation. 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' : rejeu de cookie). Le fait que l'attaquant doit être capable d'accéder à ces jetons de session (stockés sur le PC de la victime) est bien sûr un facteur atténuant, 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.
+Le scénario le plus courrant pour ce genre d'attaques est l'utilisation d'un ordinateur public 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 simplement appuyant sur 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ê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 de délai.
 <br>
-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.
+La méthodologie de test est très similaire. D'abord le testeur doit vérifier qu'un délai d'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 du délai, tous les jetons de session doivent être détruits ou rendus 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.
+Ensuite, si un délai d'expiration est configuré, le testeur doit comprendre si il est imposé par le client ou par le serveur (ou par les deux). Si le cookie de session est non-persistant (ou , plus généralement, si le cookie de session ne contient pas de données temporelles), le testeur peut considérer que l'expiration du délai 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 du délai. Dans ce cas, le testeur peut essayer de modifier le cookie (s'il n'est pas protégé cryptographiquement) et voir ce qui arrive à la session. Par exemple, le testeur 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.
+En règle générale, tout devrait être vérifié côté serveur, et il ne devrait pas être possible d'accéder à nouveau à l'application en restaurant les anciennes valeurs de cookies de session.
 <br>
@@ Line 37: / Line 37: @@
 <br>
 Le testeur doit vérifier que :
-* LA fonction de déconnexion détruit tous les jetons de session, ou au moins les rend inutilisables.
+* 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.
+* Le serveur vérifie correctement l'état des sessions, 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.
+* un délai d'expiration est imposé correctement par le serveur. Si le serveur utilise un délai d'expiration qui est lu 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.
+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é, mais pas strictement nécessaire; puisque si la session est conrrectement invalidée sur le serveur, la possession des cookies n'aidera pas l'attaquant.
 == References ==
 '''OWASP Resources'''
-* [[Session Management Cheat Sheet]]
+* [[Session Management Cheat Sheet]] : aide-mémoire sur la gestion de session

@@ Line 9: / Line 9: @@
-La
+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.
-Session timeout management and expiration must be enforced server-side. If some data under the control of the client is used to enforce the session timeout, for example using cookie values or other client parameters to track time references (e.g. number of minutes since log in time), an attacker could manipulate these to extend the session duration. So the application has to track the inactivity time on the server side and, after the timeout is expired, automatically invalidate the current user's session and delete every data stored on the client.
+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.
-Both actions must be implemented carefully, in order to avoid introducing weaknesses that could be exploited by an attacker to gain unauthorized access if the user forgot to log out from the application. More specifically, as for the log out function, it is important to ensure that all session tokens (e.g. cookies) are properly destroyed or made unusable, and that proper controls are enforced at the server side to prevent the reuse of session tokens. If such actions are not properly carried out, an attacker could replay these session tokens in order to “resurrect” the session of a legitimate user and impersonate him/her (this attack is usually known as 'cookie replay'). Of course, a mitigating factor is that the attacker needs to be able to access those tokens (which are stored on the victim's PC), but, in a variety of cases, this may not be impossible or particularly difficult.
+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.
-The most common scenario for this kind of attack is a public computer that is used to access some private information (e.g., web mail, online bank account). If the user moves away from the computer without explicitly logging out and the session timeout is not implemented on the application, then an attacker could access to the same account by simply pressing the “back” button of the browser.
+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.
-==How to Test==
+==Comment tester==
-=== Black Box testing ===
+=== Test en boite noire ===
-The same approach seen in the [[Testing for logout functionality (OTG-SESS-006)]] section can be applied when measuring the timeout log out.
+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.
 <br>
-The testing methodology is very similar. First, testers have to check whether a timeout exists, for instance, by logging in and waiting for the timeout log out to be triggered. As in the log out function, after the timeout has passed, all session tokens should be destroyed or be unusable.
+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.
+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.
 <br>
-=== Gray Box Testing ===
+=== Test en boite grise ===
 <br>
-The tester needs to check that:
+Le testeur doit vérifier que :
-* The log out function effectively destroys all session token, or at least renders them unusable,
+* LA fonction de déconnexion détruit tous les jetons de session, ou au moins les rend inutilisables.
-* The server performs proper checks on the session state, disallowing an attacker to replay previously destroyed session identifiers
+* Le serveur vérifie correctement l'état des sessoins, empêchant un attaquant de rejouer des identifiants de sessions détruits.
-* A timeout is enforced and it is properly enforced by the server. If the server uses an expiration time that is read from a session token that is sent by the client (but this is not advisable), then the token must be cryptographically protected from tampering.
+* 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.
-Note that the most important thing is for the application to invalidate the session on the server side. Generally this means that the code must invoke the appropriate methods, e.g. HttpSession.invalidate() in Java and Session.abandon() in .NET. Clearing the cookies from the browser is advisable, but is not strictly necessary, since if the session is properly invalidated on the server, having the cookie in the browser will not help an attacker.
+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.