Techniquement, même si le contenu du cookie devait être chiffré, si les cookies sont correctement copiés dans le nouveau navigateur et que le nouveau navigateur envoie les mêmes en-têtes HTTP (même chaîne d'agent utilisateur, référent est comme prévu, l'ordinateur a la même adresse IP adresse, et tous les autres en-têtes que le serveur aurait pu stocker auparavant et comparer), le serveur ne serait théoriquement pas capable de faire la différence entre le navigateur d'origine et le nouveau navigateur .

Je suppose que vous essayez de copier le ou les cookies d'un site qui vous connecte automatiquement à chaque fois que vous ouvrez votre navigateur et que vous ne vous êtes pas déconnecté.

Certains sites pourraient utiliser d'autres moyens pour détecter s'il s'agit d'un cookie / session volé, mais c'est une bataille perdue car tous ceux-ci peuvent encore être usurpés. Par exemple:

• Vérifiez si l'adresse IP a changé
• L'agent utilisateur est-il le même
• Vérifiez si le référent a un sens
• Tout autre en-tête HTTP qui le navigateur envoie

Pour répondre à votre question, vous devriez pouvoir le faire fonctionner si vous avez affaire à un site de connexion automatique et que vous ne vous êtes pas déconnecté. Assurez-vous que tous les en-têtes HTTP envoyés par votre nouveau navigateur sont les mêmes, que l'adresse IP est la même, que le référent est celui attendu, le même agent utilisateur.

Notez que peut-être aussi le service que vous utilisez utilise un deuxième cookie que vous avez oublié de copier, et crée ainsi une anomalie et vous expulse.

Le contenu d'un cookie est défini par l'application et il existe toutes sortes de façons de l'utiliser. Voici une courte liste de certaines des raisons possibles pour lesquelles votre effort a échoué.

1. Le cookie est lié à l'adresse IP, à l'empreinte digitale de l'appareil ou à d'autres données non-cookies que vous n'avez pas capturées .
2. Le cookie d'origine contient une expiration et il est passé.
3. Le cookie est à usage unique, c'est-à-dire que le serveur fait pivoter la valeur à chaque demande / réponse et invalide toute valeur de cookie qui a déjà été utilisé.
4. Le cookie était lié à une session qui n'existe plus sur le serveur (potentiellement parce que vous vous êtes déconnecté).
5. Le cookie est associé à un élément masqué dans la page (par exemple, un jeton CSRF) et vous n'avez pas capturé ou recréé cette valeur.
6. Le serveur est équilibré en charge, avec un état de session dans proc et un mécanisme de persistance de session temporaire appliqué par l'équilibreur de charge. Dans votre nouvelle session, votre client s'est vu attribuer un nœud différent dans la batterie de serveurs où la session n'existe pas.
7. Le serveur Web utilise un moteur de règles pour détecter les activités suspectes et votre cookie usurpé a été présenté hors de séquence ou à un moment inattendu.
8. Les cookies étaient corrects, mais vous avez gâché un autre détail, comme l'en-tête du référent.

1. Les cookies eux-mêmes ont peut-être été signés ou cryptés, et non la connexion qui les a délivrés.
2. Le serveur a peut-être supprimé la session de sa base de données lorsque vous vous êtes déconnecté.

Comme mentionné, lorsque vous vous êtes déconnecté, le serveur a invalidé le cookie que vous venez de voler, le rendant inutile d'essayer de faire semblant d'être vous-même.

Donc, si vous voulez vraiment tester en essayant de voler vos cookies pour tester ce qui est nécessaire pour voler votre session à ce service Web particulier, vous devrez exporter vos cookies et les importer dans un nouveau navigateur / mode de navigation privée sans vous déconnecter dans l'onglet de votre navigateur d'origine.

Mais , juste pour noter, les cookies sont également souvent comparés à une multitude d'autres critères. Nous pouvons vérifier IP, user-agent, etc. https://wingsdream.wordpress.com/tag/mitigating-http-session-hijacking/

Nous pourrions également concevoir des stratégies encore plus intelligentes, comme un système d'actualisation continue des jetons ou des empreintes digitales du navigateur, pour vérifier que la personne en possession de ce cookie est la personne à qui nous avons donné ce cookie et qu'il n'a pas été volé. Ainsi, même si vous «volez» les cookies d'authentification, vous ne pourrez toujours pas vous authentifier avec eux.

La session a été invalidée sur le serveur. Les sites Web sécurisés le font pour empêcher exactement le type d'attaque que vous décrivez. Lorsque vous vous déconnectez, le serveur supprime la session de sa propre base de données, de sorte que même si les mêmes cookies de session sont à nouveau utilisés, ils ne sont pas acceptés par le serveur. C'est pourquoi il est important de se déconnecter correctement du site Web au lieu de simplement fermer votre navigateur, même si votre navigateur ne conserve pas les cookies.

Les sites Web non sécurisés peuvent laisser la session traîner sur le serveur afin que même une fois que vous vous êtes "déconnecté" (c'est-à-dire que vous avez supprimé les cookies de votre navigateur), les mêmes cookies de session peuvent encore être utilisés ultérieurement.

Essayez de répéter votre test, mais cette fois, ne vous déconnectez pas préalablement. Connectez-vous au site Web, puis supprimez manuellement les cookies de votre navigateur. Si vous visitez à nouveau le site Web sans les cookies, vous ne serez pas connecté. Maintenant, restaurez les cookies et essayez à nouveau de visiter le site Web, et vous devriez vous reconnecter.

Pour les sites simples, la copie des cookies devrait suffire. Un site plus "sécurisé" épingle votre session comme d'autres l'ont mentionné à d'autres facteurs tels que l'IP.

Il est également possible qu'il y ait du code javascript qui vérifie d'autres valeurs persistantes comme le stockage local / de session, IndexDB, etc. sur. Essayez de les regarder. Il serait également possible qu'il s'agisse d'une application à site unique où toutes les données sont chargées via ajax et oAuth avec une forme de stockage persistant. Aucun cookie nécessaire car le secret est stocké ailleurs.

Dans de nombreux cas, voler des cookies EST suffisant pour vous authentifier, il y a de fortes chances que vous ayez fait quelque chose de mal.

Remarque, TLS / cryptage ne sont pas pertinents ici. Au moment où vous lisez le cookie de l'en-tête, le trafic a déjà été déchiffré. Tout ce que Chrome vous montre est déjà déchiffré, le chiffrement est entièrement transparent.

Pour répondre à la question. Les schémas d'authentification varient. Parfois, ils n'utilisent que des cookies, auquel cas les voler suffira. Parfois, ils n'utilisent pas du tout de cookies. Parfois, ils utilisent un mélange de cookies et d'autres données.

Il existe une infinité de systèmes de cookies. Il n'y a pas de réponse simple pour tous.