Ce n'est pas une question triviale et simpliste. Vous devez prendre en compte plusieurs aspects différents, ainsi que plusieurs mécanismes et contre-mesures différents qui s'appliquent à plusieurs menaces différentes dans plusieurs scénarios différents qui sont affectés par plusieurs clients différents. Examinons-les un à la fois. (Il y aura un TL; DR à la fin ...)

• Si vous utilisez un ordinateur public: DÉCONNEXION.
  Tout service sur lequel vous conservez un compte ne doit pas être laissé connecté sur une machine accessible au public.

• Si vous utilisez un service Trivial non sensible: RESTEZ CONNECTÉ.
  Cela s'applique uniquement aux comptes temporaires jetables, tels que comme pour la radio Internet, où donner l'accès n'est rien de plus qu'une nuisance.

• Si vous utilisez Public Wifi: LOG OUT.
  Étant donné que le réseau n'est pas de confiance par nature, il y a une grande évidence MENACE: vol de cookies de session. Il est possible que votre session ait été piratée et que quelqu'un - soit quelqu'un d'autre sur le réseau, soit le hotspot lui-même - ait volé votre cookie de session. Bien sûr, si c'était le cas, vous ne le sauriez pas, mais vous ne pourrez peut-être pas vraiment vous déconnecter non plus (s'il s'agit d'un réseau malveillant ou du MITM, ils contrôlent toute votre connexion - ils pourraient simplement abandonner votre demande de déconnexion).

  Cela dit, le vol par un tiers de uniquement votre cookie de session EST une menace valide (par exemple FireSheep), et la déconnexion explicite empêche une utilisation illimitée. (Fondamentalement, le dommage a peut-être déjà été fait, mais cela l'empêche de continuer.)

  Encore mieux serait d'aller sur un réseau de confiance, de se connecter et de se déconnecter explicitement, juste au cas où le MITM a bloqué votre déconnexion. Mieux encore est de changer votre mot de passe sur le site de confiance ... Mais mieux vaut ne jamais accéder à un site non trivial et sensible à partir d'un réseau non approuvé.

• Si vous utilisez des applications qui durent toute la journée: RESTEZ CONNECTÉ.
  Pour les services que vous utilisez toute la journée et que vous souhaitez accéder rapidement / facilement, par ex. Facebook, e-mail, etc. - S'il s'agit de votre propre ordinateur privé (ou professionnel) sur un réseau de confiance, il est judicieux de laisser votre navigateur connecté à long terme.

  MENACE : Spectateur malveillant

  Verrouillez votre ordinateur chaque fois que vous vous éloignez, même pour prendre une tasse de café. Ou verrouillez votre bureau si vous avez une porte physique que personne d'autre ne peut franchir. (Ou ayez un bureau à domicile, wheee!) Déconnectez-vous et reconnectez-vous périodiquement. Surveillez tous les messages que vous publiez.

  MENACE: d'autres sites peuvent enregistrer que vous êtes connecté (par exemple pour vous montrer cette importante icône "J'aime" de Facebook). Cela fait partie du compromis qui s'applique, alors qu'il y a des implications plus larges qui sont hors de portée de cette réponse.

• Si vous utilisez Toute application qui utilise l'authentification de base HTTP (par exemple de nombreux routeurs): DÉCONNEXION ET FERMETURE TOUT DE LA FENÊTRE DU NAVIGATEUR. Voici où cela devient intéressant, et cela s'applique également à la section suivante.

  Lorsque vous vous connectez à une application Web en utilisant Basic AuthN, le navigateur met en cache votre mot de passe et l'envoie à chaque demande. Le mécanisme BasicAuth du navigateur n'a aucune notion de session. Même si vous vous déconnectez à plusieurs reprises, l'application Web n'a aucun moyen - ni côté serveur ni côté client - de "tuer" la session. Le seul moyen d'effacer ces identifiants mis en cache est de tuer le processus du navigateur.

  CEPENDANT . Votre choix de navigateur est important pour ce concept de «processus de navigateur». Exemple:

  • Firefox : toujours un seul processus, quel que soit le nombre d'onglets et de fenêtres que vous ouvrez.

  • Chrome : chaque onglet est un processus distinct. Cependant, il existe un autre processus parent «global». Tous les processus d'onglet sont des processus enfants de celui-ci (alias "processus de travail" dans le langage Windows), et ils partagent tous la mémoire de processus via le parent . Ceci est également vrai si vous ouvrez une nouvelle fenêtre. Ainsi, alors que l'utilisation abondante par Chrome de processus enfants avec un parent partagé rend ses onglets particulièrement vivants et robustes, l'inconvénient est l'état du processus de partage. En d'autres termes, le seul moyen de supprimer les informations d'identification BasicAuth mises en cache de Chrome est de fermer toutes les fenêtres Chrome, toutes les dernières. Fermer l'onglet à lui seul n'aidera pas.

  • IE : le modèle d'onglet / processus est identique (ou similaire) à Chrome ... à une exception près. Par défaut , IE ouvre également tous les onglets d'un enfant du processus parent. (En fait, ce n'est pas précis à 100% - certains onglets partagent un processus enfant avec d'autres onglets - mais cela n'a pas d'importance en réalité). Cependant, si vous ajoutez " -NoFrameMerging " à la ligne de commande IE, cela créera un processus parent IE complètement nouveau. La différence ici est que vous pouvez par ex. créez une nouvelle fenêtre parent juste pour vous connecter à votre routeur, puis fermez juste cette fenêtre lorsque vous avez terminé. Cela efface votre cache BasicAuth, sans toucher à aucune autre fenêtre IE ouverte. (Remarque: il est en fait possible de le faire aussi avec Chrome! Cependant, cela est beaucoup plus complexe et vous oblige à créer un autre profil de navigateur sur votre ordinateur.)

• Si vous utilisez des applications sensibles, par exemple applications bancaires - TOUJOURS DÉCONNEXION EXPLICITE ET FERMER TOUTES LES FENÊTRES DU NAVIGATEUR .

  MENACE: spectateur malveillant Le verrouillage de votre ordinateur, comme ci-dessus, aurait du sens, mais il n'est pas nécessaire de faire le compromis d'avant. Déconnectez-vous simplement.

  Session Timeout: De plus, les applications les plus sensibles (par exemple bancaires) devraient implémenter une forme de timeout d'inactivité automatique, donc si vous sortez pour l'après-midi, votre session mourra automatiquement à un moment donné. Cela pourrait ne pas aider avec cette menace, car le spectateur malveillant peut simplement sauter sur votre ordinateur si vous sortez pendant 4 minutes et demie pour remplir votre café.

  MENACE: le vol de cookies de session

  Espérons que les applications sensibles empêchent activement cela, avec par exemple HTTPS, IDS, détection de géo / fraude, etc. Cela dit, il est toujours logique de fermer cette "fenêtre d'opportunité", juste au cas où - défense en profondeur, et tout ça.

  Session Timeout: As avant, les applications les plus sensibles (par exemple bancaires) devraient implémenter une forme de délai d'inactivité automatique, et aideront également à minimiser cette menace. Cependant , même si vous savez avec certitude que cette application met en œuvre correctement les délais d'inactivité, il existe toujours une fenêtre d'opportunité pour l'attaquant. Cela dit, dans une application relativement sécurisée, ce n'est pas vraiment une menace.

  MENACE: Cross Site Request Forgery (CSRF)

  C'est celui dont vous devez vous soucier.

  Supposons que vous soyez connecté à votre banque. Dans la même fenêtre, dans un onglet différent, vous parcourez un site Web douteux. Lors de la consultation de ce site Web, il se peut que vous testiez subrepticement divers sites bancaires bien connus, pour voir si vous êtes connecté à l'un d'entre eux. Si c'est le cas, il montera l'attaque CSRF (tous les sites bancaires ne sont pas vulnérables à cela, mais beaucoup le sont toujours). CSRF'd!

  D'accord. Dites maintenant que vous êtes plus intelligent que cet autre type et ne parcourez pas les sites suspects en même temps que votre site bancaire est ouvert. Donc, après avoir terminé sur votre banque, vous fermez soigneusement l'onglet. Seulement alors vous ouvrez un nouvel onglet pour accéder au site douteux. Eh bien, le problème est que vous êtes toujours connecté et le restera pendant un certain temps (généralement environ 30 minutes, mais cela peut être aussi peu que 10 ou jusqu'à une heure ...). CSRF'd! .

  (Notez que le délai d'expiration de la session ici aide, en raccourcissant la fenêtre d'opportunité, mais il y a encore une chance que cela se produise dans la fenêtre).

  Hmm. Eh bien, je sais, ouvrons une nouvelle fenêtre de navigateur! Utilisez-le pour le travail bancaire, puis fermez à nouveau l'onglet et ouvrez à nouveau un nouveau pour les sites de logiciels malveillants avec lesquels j'aime jouer. Oups, consultez la section ci-dessus sur l'authentification de base - votre choix de navigateur est important.

  À moins que vous n'utilisiez la "navigation privée / privée" ou l'indicateur " -NoFrameMerging " IE, vous êtes toujours dans la même famille de processus , et cette session toujours ouverte sera partagée entre toutes vos fenêtres, au moins jusqu'à ce que le serveur atteigne le délai d'inactivité. En supposant qu'il n'a pas déjà été coopté. CSRF'd!

  D'accord, encore un, juste un. J'ai lu ce post trop long quelque part, sur la façon dont je dois toujours me déconnecter de mes applications sensibles - c'est donc exactement ce que je fais avant de revenir sur mes sites criminels. Malheureusement, l'application a "oublié" de se déconnecter correctement, elle me redirige simplement hors de l'application (ou efface mon cookie, ou ...) au lieu de l'invalider sur le serveur ... CSRF'd!

Alors, TL; DR?

• Si vous vous souciez de votre compte sur ce site: DÉCONNEXION.
• Si vous vous souciez de votre compte et qu'il utilise l'authentification de base: DÉCONNEXION ET FERMETURE DE TOUS LES ONGLETS ET FENÊTRES DU NAVIGATEUR.
• Si vous ne vous souciez pas de votre compte - peu importe ce que vous faites, alors arrêtez de demander :-).

_{P.S. Je n'ai pas traité de choses comme les cookies Flash, les sessions non http et l'authentification Windows intégrée. Trop c'est trop.}

Lors de la connexion à un service Web, un cookie est installé dans votre navigateur. Ce cookie a une valeur d'identification unique qui vous identifie lorsque vous utilisez le service Web et, éventuellement, lorsque vous revenez plus tard. Si, d'une manière ou d'une autre *, cet identifiant a été volé, la personne qui le possède pourrait éventuellement utiliser votre compte comme s'il s'agissait de vous.

La déconnexion invalide généralement cet identifiant pour vous et l'adversaire. Aucun de vous ne pourra utiliser l'identifiant pour dire au service Web " Bonjour, je suis Angelo Hannes ". Cela a pour effet secondaire malheureux de vous forcer vous à saisir à nouveau votre nom d’utilisateur et votre mot de passe pour vous connecter.

«Alors, que dois-je faire alors?», Demandez-vous. En fait ça dépend. Certains services Web sensibles (banques, sites Web gouvernementaux, compagnies d'assurance, etc.) ont un temps de session court, c'est-à-dire qu'ils invalident l'identifiant après 10 à 15 minutes de non-utilisation du service. D'autres services Web sensibles (boîte de réception de courrier électronique, qui contrôle pratiquement tous vos autres comptes) n'invalident pas vraiment la session très souvent, mais ils appliquent des restrictions d'adresse IP (si vous utilisez la même session à partir d'une adresse IP différente, la session est invalidé).

TL; DR

• Ordinateur public, extra paranoïaque, vous pensez que votre session a été compromise, ou vous vous souciez vraiment de ce service? Déconnexion

• Ordinateur privé, vous pensez que votre session est sécurisée, et vous ne vous souciez vraiment pas de ce service? Vous pouvez rester connecté .

* Votre session peut être volée en utilisant des problèmes connus dans le service (sans utiliser HTTPS, pour exemple) ou certaines vulnérabilités zero-day telles qu'une attaque XSS nouvellement découverte dans le service, une nouvelle vulnérabilité dans votre navigateur qui divulgue des informations sur les cookies, ou certains logiciels malveillants installés sur l'ordinateur que vous utilisez qui vole des informations de session (enfin, en ce sens cas il aurait déjà volé votre nom d'utilisateur et votre mot de passe).

Je vais essayer de répondre à cette question d'une manière inverse à celle déjà publiée ci-dessus.

Quels sont les risques associés aux sessions inactives dans les applications Web?

• Vol de cookies de session via XSS (si la session n'est pas liée à l'adresse IP)
• Falsification de requêtes intersites (en veille mais session toujours authentifiée).
• Attaques de l'homme au milieu (à l'aide d'un cookie de session reniflé utilisant SSLStrip ou en raison de divulgations d'informations HTTPS mixtes)
• Ouvrez le terminal (vous êtes parti pour une pause déjeuner avec PayPal ouvert à côté d'< insérez le nom du cybercriminel aléatoire ici> et êtes revenu pour voir votre compte vide parce que vous ne vous êtes pas déconnecté)

Délai d'expiration Comme indiqué précédemment, certaines applications critiques pour la sécurité, telles que les sites Web bancaires, ont des délais d'expiration faibles, généralement de cinq à dix minutes. Cependant, ces applications ont généralement également des jetons de prévention CSRF à séquençage aléatoire et des adresses IP liées aux sessions. Par conséquent, même si votre cookie est compromis, il n'y a rien qu'un attaquant distant puisse faire avec lui si la sécurité a été mise en œuvre correctement.

D'autres sites Web comme FaceBook ne temporisent pas les sessions en général pour une meilleure facilité d'accès ou d'utilisation . Cependant, ils prennent en charge la notification de connexion, la liaison IP au cookie. Des applications comme Gmail ou DropBox prennent en charge l'authentification par SMS en 2 étapes pour améliorer encore la sécurité et rendre le vol de session inutile s'il provient d'un nouveau PC non fiable.

Par conséquent, le seul souci que j'aurais est laisser les sessions ouvertes sur:

• Terminaux publics (où vous devriez de toute façon utiliser la navigation privée. Ctrl + Maj + P sur FF)
• Sites Web peu sécurisés (Où l'utilisateur est responsable de la préservation de la confidentialité de ses cookies contre les monstres de cookies maléfiques).

L'une des plus grandes menaces pour ne pas se déconnecter est l'utilisation d'un ordinateur public. Selon la configuration du navigateur, la simple fermeture du navigateur peut ne pas mettre fin à une session. Si l'utilisateur oublie de déconnecter l'utilisateur de son système d'exploitation (ou qu'il ne peut même pas le faire), quelqu'un d'autre peut accéder à son application Web. Ce n'est bien sûr pas un cas très probable. Mais les applications Web sont souvent accessibles à un grand groupe d'utilisateurs et certains utilisateurs peuvent utiliser des ordinateurs publics (universités, écoles, bibliothèques).

Puisqu'une session a un délai d'expiration, je ne suis connecté que très peu de temps après avoir utilisé l'application Web.

Ce n'est pas forcément vrai. Selon la façon dont le site implémente sa gestion de session, il peut utiliser un délai d'expiration arbitrairement long et peut même utiliser des sessions qui survivent au redémarrage du navigateur / du système d'exploitation.

En fin de compte, vous devez vous déconnecter explicitement ou non dépend de ce qu'est l'application Web . Les sites bancaires implémentent généralement un délai d'expiration très court, les sites de réseaux sociaux implémentent généralement une connexion essentiellement permanente, surtout s'ils sont également des fournisseurs d'identité (OpenID, etc.).

Voler un cookie de session n'est généralement pas facile, mais c'est possible et la déconnexion explicite empêche cela, vous devez généralement vous déconnecter explicitement pour les sites de grande valeur.

Ne supposez pas qu'un service a un délai d'expiration. Même s'il a un délai d'expiration, un attaquant pourrait simplement collecter votre cookie et l'utiliser avec un simple script qui continue à envoyer un ping au service, à envoyer votre cookie, à actualiser l'horodatage "dernière vue". Les propriétaires de sites Web peuvent se protéger de plusieurs façons, mais ne faites pas confiance aux propriétaires de sites Web. Voler un cookie n'est pas aussi difficile qu'il n'y paraît (une recherche sur youtube peut vous montrer exactement à quel point c'est facile), et votre meilleure protection dans ce cas est en effet de vous déconnecter.

Si vous ne vous déconnectez pas, le cookie de connexion restera valide pendant une période donnée (selon l'implémentation), car le serveur (sur lequel l'application Web s'exécute) ne sait pas que vous avez fermé votre navigateur. Si quelqu'un a volé votre cookie, il ou elle peut l'utiliser pour se connecter à l'application et même en prolonger la validité, car la plupart des implémentations ont une expiration glissante.

Du point de vue de la sécurité, à mon avis, la réponse est simple. Lorsque vous avez terminé la déconnexion d'un site. Et lorsque vous avez terminé votre navigation, effacez votre cache et supprimez l'historique, etc. Vous pouvez même configurer votre navigateur pour tout effacer lorsque vous fermez le navigateur. Laissez le moins de traces possible de ce que vous avez fait.

Et veuillez ne pas cliquer sur des pop-ups ou des liens amusants dans les e-mails. Méfiez-vous des redirections du site où vous pensez être vers un autre site.