Je me trompe peut-être, mais je pense que la demande de fermeture de la fenêtre du navigateur après la déconnexion est courante, bien que l'on ne sache pas vraiment quels sont les risques de ne pas fermer une fenêtre de navigateur (en supposant que le navigateur est complètement à jour) et pourquoi, plus important encore, les navigateurs ne sont pas en mesure d'atténuer la menace sans fermer la fenêtre du navigateur. Enfin, la fermeture du navigateur est-elle meilleure que la simple fermeture d'une fenêtre/d'un onglet dans le navigateur?
Après un peu de recherche, il semble que certaines banques donnent ce conseil à la suite d'une attaque contre une banque qui a permis à des utilisateurs ou à des sites Web malveillants de réutiliser des cookies persistants après la déconnexion d'un utilisateur, prétendument parce que d'autres onglets du navigateur ont été laissés ouverts sur le site en question et donc le navigateur n'avait pas encore effacé les cookies.
La raison pour laquelle une telle vulnérabilité serait possible indique que l'un des deux mécanismes de sécurité suivants a échoué:
En ce qui me concerne, je peux déjà conclure que ce "conseil" est un théâtre de sécurité utilisé par certains sites Web pour rejeter leurs propres responsabilités sur les utilisateurs. Ce qui est évidemment très faux car cela incite les utilisateurs à gaspiller leurs efforts et leur temps à appliquer des mesures stupides au lieu de régler le problème là où il se produit.
Les sites Web ont deux fonctions lors de la déconnexion d'un utilisateur, selon OWASP :
Ainsi, dans un monde où les développeurs de sites Web respectent leurs devoirs, il ne devrait y avoir aucune base pour suivre de tels conseils stupides. Et si les sites Web ne le font pas, ils sont susceptibles de être responsables de ne pas prendre les moyens nécessaires pour protéger les données personnelles des utilisateurs .
Vous devez fermer votre navigateur Web (pour éviter la divulgation d'informations privées) si ...
Il se peut que quelqu'un accède à l'ordinateur après
La réponse HTTP (des informations sensibles) ne définit pas correctement l'en-tête Cache-Control
Par exemple, allez sur yourbank.com et examinez votre compte. Cliquez sur déconnexion. Cliquez sur le bouton retour. Voyez-vous les informations de votre compte? Sur certains sites, vous le ferez, sur d'autres non, selon cet en-tête de cache.
Allez sur yourbank.com et consultez votre compte. Notez l'URL. Cliquez sur déconnexion. Fermez votre navigateur (toutes les fenêtres/processus). Ouvrez à nouveau votre navigateur avec l'URL indiquée. Voyez-vous les informations de votre compte? Tu ne devrais pas.
L'en-tête HTTP correct est:
Cache-Control: no-store, must-revalidate
Dans le cas où un utilisateur pourrait avoir le même site ouvert sur plusieurs onglets (mais ne se déconnecte que d'un seul), vous pouvez faire recharger la page par le navigateur (affichant ainsi l'écran de connexion) en utilisant l'en-tête suivant
Refresh: N
Où N est le nombre de secondes jusqu'à l'expiration de la session de l'utilisateur + un petit tampon. Il serait toujours vulnérable pendant une période, mais pas pour toujours.
Ces conseils sont souvent donnés pour les solutions d'authentification unique (SSO). C'est pour une collection de systèmes, où un utilisateur ne se connecte qu'une seule fois. L'authentification de l'utilisateur est gérée par un système central appelé le fournisseur d'identité. Après la connexion, deux sessions sont établies avec le système demandé et avec le fournisseur d'identité lui-même. Lors de la visite d'un nouveau système, la session existante avec le fournisseur d'identité est utilisée pour créer une session avec ce nouveau système sans demander à nouveau les informations d'identification.
La réalisation d'une déconnexion unique (SLO) est un problème complexe car vous devez invalider les sessions de chaque système visité. SLO est souvent implémenté en donnant simplement ces conseils pour fermer le navigateur, invalidant ainsi toutes les informations d'identification des sessions.
Cette technique est souvent utilisée lorsqu'un site Web utilise une authentification de base ou Windows, car il n'y a aucun moyen de se déconnecter. Au lieu d'utiliser des cookies, le mécanisme d'authentification est ajouté en tant qu'en-tête d'autorisation à chaque demande envoyée au site Web. Pour l'authentification de base, ce serait le nom d'utilisateur/mot de passe dans une chaîne codée en base64 et pour l'authentification Windows, il contient des valeurs relatives à l'authentification NTLM ou Kerberos. Ainsi, la fermeture du navigateur est la correction la plus rapide et la plus sûre.
Cela contraste avec l'utilisation de l'authentification par formulaire où une session peut être fermée en expirant simplement le cookie et en supprimant la session de l'application.
Il est difficile de savoir ce que pensent les banques, mais il y a un réel avantage à fermer votre navigateur après vous être déconnecté d'une banque ou d'un autre site sensible.
Les navigateurs ne sont pas parfaits et ne seront jamais parfaits. L'espace mémoire du navigateur peut contenir des informations sensibles comme les noms d'utilisateur, les mots de passe, les jetons, les soldes des comptes, etc. Cela DEVRAIT être inaccessible à un attaquant, mais comme nous le savons tous, aucun programme n'est complètement sécurisé. Comme nous l'avons vu dans Heartbleed, un exploit a le potentiel de divulguer ces informations sensibles à des tiers. La fermeture du navigateur et le démarrage d'un processus entièrement nouveau efface la mémoire et supprime cette voie potentielle de fuite.