Cookies de session sécurisés

Question

En cherchant des méthodes pour créer des cookies de session sécurisés, je suis tombé sur cette publication: A Secure Cookie Protocol . Il propose la formule suivante pour un cookie de session:

cookie = user | expiration | data_k | mac

où

| Indique la concaténation.
user est le nom d'utilisateur du client.
expiration est le délai d'expiration du cookie.
data_k Sont des données chiffrées associées au client (comme un ID de session ou des informations de panier) chiffrées à l'aide de la clé k.
- k est dérivé d'une clé de serveur privée sk; k = HMAC(user | expiration, sk).
- data_k Pourrait être chiffré à l'aide de AES à l'aide de la clé k.
mac est un HMAC du cookie pour vérifier l'authenticité du cookie; mac = HMAC(user | expiration | data | session-key, k).
- data correspond aux données non chiffrées associées au client.
- session-key Est la clé de session SSL.
HMAC est HMAC-MD5 ou HMAC-SHA1.

Selon le journal, il assure la confidentialité des cookies et empêche les attaques de rejeu et de volume. Pour moi (étant un amateur de sécurité/cryptographie), cela semble assez bon. Quelle est la qualité de cette méthode pour les cookies de session ou les cookies en général?

D.W. · Accepted Answer

Oui, cela ressemble à un assez bon système de protection des cookies.

Un autre schéma plus récent dans ce domaine est SCS: Secure Cookie Sessions for HTTP , qui est un schéma solide, très bien pensé. Je recommande de lire la discussion sur la sécurité de ce document pour avoir une bonne idée des menaces de sécurité.

Pour aider à comprendre le but et le rôle du système de cookies que vous mentionnez, permettez-moi de sauvegarder et de fournir un certain contexte. Il est courant que les applications Web doivent maintenir l'état de session: c'est-à-dire un état dont la durée de vie est limitée à la session en cours et qui est lié à la session en cours. Il existe deux façons de conserver l'état de la session:

Stocke l'état de la session sur le serveur. Le serveur Web alimente le navigateur un cookie de session: un cookie dont le seul but est de contenir une grande chaîne de bits non devinable qui sert d'identifiant de session. Le serveur conserve une table de recherche, avec une entrée par session ouverte, qui mappe de l'identifiant de session à tous les états de session associés à cette session. Cela permet au code d'application Web de récupérer et de mettre à jour facilement l'état de session associé à une demande HTTP/HTTPS particulière. La plupart des frameworks d'applications Web fournissent une prise en charge intégrée pour le stockage de l'état de session côté serveur.

Il s'agit du moyen le plus sûr de stocker l'état de la session. Étant donné que l'état de session est stocké sur le serveur, le client n'y a pas d'accès direct. Par conséquent, les attaquants n'ont aucun moyen de lire ou de modifier l'état de la session (ou de relire les anciennes valeurs). Cela nécessite un travail supplémentaire pour maintenir l'état de session synchronisé sur tous les serveurs, si votre application Web est distribuée sur plusieurs nœuds de calcul principaux.
Stocker l'état de session sur le client. L'autre approche consiste à mettre l'état de session dans un cookie et à envoyer le cookie au navigateur. Désormais, chaque demande ultérieure du navigateur inclura l'état de la session. Si l'application Web souhaite modifier l'état de la session, elle peut envoyer un cookie mis à jour au navigateur.

Si cela est fait naïvement, il s'agit d'un énorme trou de sécurité, car il permet à un client malveillant de visualiser et de modifier l'état de la session. Le premier est un problème s'il y a des données confidentielles incluses dans l'état de session. Ce dernier est un problème si le serveur fait confiance ou se fie à l'état de session de quelque manière que ce soit (par exemple, considérez si l'état de session inclut le nom d'utilisateur de l'utilisateur connecté et un bit indiquant si cet utilisateur est un administrateur ou non; un client malveillant pourrait alors contourner le mécanisme d'authentification de l'application Web).

La proposition que vous évoquez et le dispositif SCS visent à se défendre au mieux contre ces risques. Ils peuvent le faire d'une manière qui réussit le plus. Cependant, ils ne peuvent pas empêcher un client malveillant de supprimer le cookie (et donc d'effacer l'état de la session). En outre, ils ne peuvent pas empêcher un client malveillant de rejouer une ancienne valeur du cookie (et donc de réinitialiser l'état de la session à une valeur plus ancienne), si l'ancienne version provenait de la même session. Par conséquent, le développeur de l'application Web doit être conscient de ces risques et faire attention aux valeurs stockées dans l'état de session.

Pour cette raison, le stockage de l'état de session dans les cookies est un peu plus risqué que le stockage sur le serveur, même si vous utilisez l'un de ces schémas cryptographiques pour protéger les cookies. (Cependant, si vous allez stocker l'état de la session dans les cookies, je vous recommande vivement d'utiliser l'un de ces deux schémas pour protéger les valeurs dans les cookies. )

Pourquoi quelqu'un enregistrerait-il l'état de la session dans les cookies, étant donné qu'il peut tout aussi facilement être stocké côté serveur? La plupart du temps, il n'y a aucune raison de le faire. Cependant, dans certains cas exceptionnels - comme un serveur HTTP qui est extrêmement limité dans la quantité de stockage dont il dispose, ou dans des applications Web à charge équilibrée qui sont distribuées sur plusieurs machines sans une bonne prise en charge de l'état de session synchronisé - il peut y avoir des raisons justifiables d'envisager de stocker l'état de la session dans les cookies, puis d'utiliser l'un de ces schémas est une bonne idée.

P.S. Une rubrique connexe: si vous utilisez ASP.NET View State , assurez-vous de le configurer pour qu'il soit chiffré et authentifié: c'est-à-dire configure ViewStateEncryptionMode to Always et EnableViewStateMac à true; si vous utilisez plusieurs nœuds de serveur, générez une clé cryptographique forte et configurez chaque machineKey de chaque serveur pour utiliser cette clé . Enfin, assurez-vous que vous disposez d'une version à jour du cadre ASP.NET; anciennes versions avait une grave faille de sécurité dans la cryptographie ViewState .

Charlie B · Answer

Quel problème essayez-vous de résoudre?

Il y a deux choses auxquelles je peux penser:

Vous souhaitez configurer des sessions utilisateur sécurisées. Dans ce cas, vous n'avez probablement même pas besoin de générer vos propres cookies de session - ils peuvent être générés via une session SSL avec votre serveur et sont généralement sécurisé pour tous les besoins du site Web. Assurez-vous simplement que le site implémente SSL correctement, et vous utilisez une méthode de génération de session bien connue, telle que celle que l'on trouve dans les langages courants comme PHP ou ASP.
Vous souhaitez stocker des données sécurisées dans le cookie pour une récupération ultérieure. Ceci est beaucoup plus difficile à sécuriser, en raison de nombreux problèmes avec les cookies. Mieux vaut plutôt stocker côté serveur et associer les données à l'utilisateur à l'aide d'une autre méthode. Si vous devez le faire, la méthode que vous décrivez semble assez bonne dans l'ensemble, bien que je ne sache pas comment elle empêche les attaques de relecture, ou d'autres attaques comme l'homme au milieu comme SSL le fait.

N'hésitez pas à me contacter directement si vous souhaitez en discuter plus.

symcbean · Answer

Une partie de la méthode qu'ils proposent consiste à utiliser la clé de session SSL dans le cadre de la charge utile chiffrée - mais cela ne dure que aussi longtemps que la session SSL - c'est-à-dire que vous ne pouvez pas utiliser cette méthode pour les cookies destinés à s'étendre sur plus d'une session de navigateur. Ce n'est pas non plus exactement trivial; mettre la main sur la clé de session SSL, en particulier sur la terminaison SSL, est ailleurs que sur le serveur http.

En pratique, il est beaucoup plus simple d'utiliser une valeur aléatoire pour le cookie comme poignée pour les données stockées côté serveur. Cela peut être lié à des trucs comme un hachage de l'agent utilisateur du navigateur et le nom de réseau (pas adresse IP) du client. Et/ou, si vous devez, la clé de session SSL sur le serveur. Il n'est pas nécessaire de crypter toutes ces données et de les envoyer au client.

Darrell Teague · Answer

Il s'agit d'une mise en œuvre raisonnable car elle résout les problèmes de:

Non-répudiation (la vérification de la valeur n'a pas été modifiée)
Confidentialité (que le contenu crypté ne peut pas être lu)

Cependant, les informations utilisateur sont un peu faibles et si elles ne sont pas incorporées dans les informations chiffrées pour une comparaison ultérieure, elles pourraient être compromises.

Le plus gros problème avec les cookies ou toutes les données accessibles au client est que le client (pirate) peut le modifier ou le copier. Le détournement de session est facile à réaliser malgré SSL (comme indiqué précédemment comme étant suffisant - ce qui n'est pas le cas). Diverses formes de malware, man-in-the-middle, man-in-the-browser et d'autres attaques peuvent capturer le cookie de session, le copier sur une autre machine et maintenant ils peuvent `` posséder '' cette session. Pour un système de carte sur fichier comme Amazon, cela peut être problématique.

Pour fermer la boucle sur cette proposition, l'identification du client doit être raisonnablement unique, puis liée aux données de la section cryptée pour empêcher un autre ordinateur de voler le cookie de session. À part cela, les éléments de la proposition semblent solides.