Ça manque de précision cette discussion quand même.
Déjà une session ce n’est jamais "chiffré", c’est un simple ID unique généré aléatoirement et qui identifie côté serveur un fichier de stockage contenant des données sessions (ex IP, statut de connexion). La première fois (ou quand une précédente session à expiré), le serveur transmet un nouvel identifiant à l’utilisateur en lui soumettant l’ajout d’un cookie. Par la suite, l’utilisateur doit renvoyer systématiquement à chaque requête HTTP(S) son précieux cookie et c’est grâce à ça que le serveur peut récupérer les informations sur l’individu - pour plus de sécurité, il peut vérifier la localisation à partir de l’IP et ainsi fermer automatiquement la session si celui-ci se connecte soudainement à l’autre bout de la planète.
Ensuite y’a pas un codage différent selon les navigateurs. C’est juste qu’ils ont leur répertoire respectif, isolé les uns des autres. La représentation des cookies dans le navigateur ne change pas.
Il suffit d’exécuter cette commande dans la console du navigateur (F12) pour s’en rendre compte : document.cookie
Sur ZDS, on va avoir ceci : "hasConsent=true; csrftoken=3W67DfS8DKVIttPXCxQ8S[...]yOjsfeeQSQFZJkz"
Un cookie de consentement nommé 'hasConsent' autorisant le prélèvement d’informations statistiques sur le site. Et un cookie de session nommé "csrftoken", en l’occurrence celui-ci est prévu pour se protéger d’une attaque CSRF sur Django.
En PHP, le nom du cookie c’est PHPSESID. Sur Google, c’est probablement SID - nommage fréquemment utilisé sur des web app.
En principe pour déplacer une session, tu peux simplement copier la combinaison clé-valeur du cookie et l’ajouter dans le navigateur de ton choix. Selon le niveau de sécurité choisi par le site, ça peut fonctionner ou bloquer. Typiquement si vous z’êtes malveillant et que vous arrivez à retrouver la partie tronqué de mon cookie de session, vous pourriez être considéré en tant que tel Yarflam.