web-dev-qa-db-fra.com

Comment l'ID de session est-il envoyé en toute sécurité?

J'apprends la gestion de session et j'ai deux questions auxquelles je n'ai pas trouvé de réponses sur le web.

Une fois l'utilisateur authentifié, le serveur crée l'ID de session et l'envoie au client (utilisateur) sous la forme d'un cookie. Ce cookie est ensuite utilisé dans les requêtes que le client envoie au serveur pour s'identifier auprès des autres utilisateurs.

Désormais, dans une session HTTPS, les demandes envoyées entre le client et le serveur sont sécurisées, car les demandes du client sont cryptées à l'aide de la clé publique du serveur, et elles ne peuvent être décryptées qu'à l'aide de la clé privée dont le serveur ne dispose que.

Mais initialement, lorsque le serveur envoie les informations du cookie au client, elles peuvent être interceptées par n'importe qui, même si ce cookie qui contient l'ID de session est crypté à l'aide de la clé privée. Il pourrait être décrypté par toute personne possédant la clé publique. Donc, ma question est:

  1. Comment le serveur s'assure-t-il que l'ID de session créé par le serveur est envoyé en toute sécurité au client.

  2. J'ai appris que le client envoie le cookie pour chaque requête qu'il fait au serveur. Dans une demande GET, comment le client envoie-t-il les informations de cookie, car GET n'inclut pas le corps?

cookiessession-management
14
God_Father

La connexion entre le client et le serveur n'utilise pas le chiffrement à clé publique (qui n'est utilisé que pour l'échange de clé initial). Un algorithme différent est utilisé pour le chiffrement (généralement un chiffrement symétrique), comme AES-256-CBC sur une connexion TLS 1.2. Donc, à moins que vous ne l'ayez intercepté, personne d'autre que le navigateur prévu et le serveur d'origine ne peuvent décrypter le message. L'interception n'est donc pas aussi simple que d'avoir les informations de clé publique du serveur.

Le cookie n'est pas envoyé en tant que demande GET. Il est ajouté aux en-têtes comme Cookie:[Token]; [Other cookies];. Le type de demande sous-jacent n'est pas pertinent pour cela. (Le type de demande par défaut est GET, cependant.)

Je vous suggère de regarder le trafic réseau de votre navigateur vers un site Web auquel vous êtes connecté et de voir ce qui est utilisé où. (C'est facile à faire dans Chrome.)

15
LvB

Réponse 1: si le serveur utilise SSL/HTTPS (vérifié par un certificat tiers non auto-signé), les cookies et les identifiants de session voyagent sous forme de texte chiffré sur le réseau, et si un attaquant (Man in le Moyen) utilise un renifleur de paquets, ils ne peuvent obtenir aucune information. Ils ne peuvent pas décrypter les données car la connexion entre le client et le serveur est sécurisée par un tiers vérifié. Ainsi, HTTPS sans certificat vérifié signifie que le serveur et l'utilisateur ne peuvent pas s'assurer que l'ID de session n'est pas reniflé.

cela signifie que toutes les données (c'est-à-dire les cookies) doivent être envoyées et reçues après l'établissement d'un HTTPS sécurisé entre l'utilisateur et le serveur et peuvent garantir que l'ID de session est envoyé en toute sécurité à l'utilisateur.

également le chiffrement asymétrique juste utilisé pour échanger la clé du chiffrement symétrique (qui est utilisé pour chiffrer les données entre le client et le serveur).

enter image description here

pour une meilleure image clic droit: ouvrir l'image dans une nouvelle fenêtre

Réponse 2: Les cookies sont entièrement gérés par l'en-tête de demande dans les champs d'en-tête HTTP, les cookies côté client sont encodés dans l'en-tête de réponse 'Cookie' et 'Set-Cookie' et du côté serveur sont encodés dans l'en-tête de demande "Cookie" - variable $ Path.

Exemple de demande client:

GET /index.html HTTP/1.1
Host: www.example.com

Exemple de réponse du serveur:

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: foo=10
Set-Cookie: bar=20; Expires=Fri, 30 Sep 2011 11:48:00 GMT
... rest  of the response

Ici, deux cookies (foo=10 et bar=20) sont stockés sur le navigateur. Le second expirera le 30 septembre. Dans chaque demande ultérieure, le navigateur renverra les cookies au serveur:

GET /spec.html HTTP/1.1
Host: www.example.com
Cookie: foo=10; bar=20
Accept: */*
5
Ali