Je suis interrogé sur les attaques de replay de cookies avec mes sites Web ASP.NET. Authentification des formulaires.
J'ai suivi les conseils ci-dessous pour protéger contre toute attaque, mais pensez que le site est toujours vulnérable si quelqu'un parvient à se mettre au cookie (même pendant une courte période). Existe-t-il un moyen de détruire complètement la session d'authentification des formulaires sur la déconnexion afin que même si quelqu'un avait volé le cookie, il n'y aurait aucune chance de l'utiliser malicieusement
Conseil suivi était
Nous pensons que nous avons pris toutes les mesures responsables, nous pouvons pour protéger contre cela dans les limites d'ASP.NET. S'il vous plaît voir la réponse détaillée ci-dessous.
Cependant, nous avons mis en œuvre les étapes recommandées de Microsoft pour défendre à ce sujet (voir http: //support.microsoft.com/default.aspx?scid=kb;en-us ;900111 )
· Le cookie d'authentification n'est jamais écrit à une machine client la rendant difficile à voler.
· L'application est exécutée via SSL afin qu'un cookie n'est jamais émis sur une connexion non sécurisée
· Nous appliquons l'expiration absolue avec un délai d'attente de 15 minutes qui signifie que tout problème de cookie est inutile après cette limite de temps
· Nous utilisons des cookies httponly afin que personne ne puisse pro grammaticalement intercepter ou altérer ce cookie.
Donc, même si les précautions ci-dessus étaient cassées, que nous pensons très improbablement, un utilisateur malveillant n'aurait que 15 minutes de fenêtre pour casser les précautions et se connecter avec succès
4 Réponses :
Y a-t-il un moyen de détruire complètement la session d'authentification des formulaires sur déconnexion pour que même si quelqu'un avait volé le cookie, il y aurait aucune chance de l'utiliser malicieusement
La voie consiste à garder une piste sur votre serveur que l'utilisateur est déconnecté et à quelle heure, alors même si sa page allait voir une page à l'aide d'un cookie authentifié valide, vous vérifiez si cet utilisateur est également enregistré sur vos enregistrements de serveur. ou pas.
Cela signifie que vous devez avoir une table supplémentaire sur votre base de données pour conserver et vérifier la déconnexion de connexion de votre statut de vos utilisateurs et que 100% comptent sur le cookie d'authentification.
Y a-t-il un moyen de détruire complètement la session d'authentification des formulaires sur la déconnexion
Dans le pire scénario que le cookie est volé, vous ne pouvez en réalité pas.
Pourquoi est-ce que cela, car l'authentification de la forme est réellement conserver sur la cookie toutes les données (comme lors de l'expiration de l'utilisateur, etc.). Donc, vous ne pouvez pas supprimer cela, est sur le cookie et la variante consiste à synchroniser cela avec vos données personnalisées sur le serveur et à avoir un niveau de sécurité supplémentaire.
La section Données utilisateur du cookie peut être utilisée pour stocker des informations supplémentaires que vous pouvez utiliser pour corréler les cookies des formulaires avec des informations persistantes côté serveur. Ainsi, vous pouvez réellement détecter si un cookie est réutilisé après la fin de la session.
@Wiktorzychla mais si le pirate informatique obtient et remplace à la fois le cookie de session avec le cookie connecté? Ensuite, c'est par passer votre chèque.
Il existe un seul cookie de formulaires cryptés, avec GUID dans les données de session. Ce guidon ne correspond pas à une session latérale du serveur, mais est juste un jeton de garde unique supplémentaire.
Une idée simple est de générer un GUID aléatoire et de le stocker dans la section Données utilisateur du cookie. Ensuite, lorsqu'un utilisateur se déconnecte, vous récupérez le GUID à partir des données utilisateur et écrivez-le dans un référentiel latéral serveur avec une annotation que cette "session" est terminée.
Ensuite, demandez à un module HTTP qui vérifie chaque demande si le GUID de la section UserData de votre cookie ne pointe pas vers une session terminée. Si oui, résiliant la demande avec un avertissement selon lequel le cookie expiré est réutilisé.
Cela vient avec un coût d'une recherche supplémentaire par demande.
Un coût supplémentaire est que cette approche n'appelle pas bien, car dans une application Web fortement utilisée, vous aurez bientôt une énorme table pleine de GUID. Ne serait-il pas préférable de stocker le GUID de la session actuelle de la ligne d'utilisateur de la base de données et de la définir sur NULL lorsque l'utilisateur se déconnecte? De cette façon, vous aurez un maximum de
@ TO0OM: Cela pourrait conduire à des problèmes suivants lorsque le même utilisateur dispose de plusieurs sessions indépendantes actives (par exemple dans différents navigateurs) et se termine par certains d'entre eux sans terminer les autres.
C'est vrai. Si l'on veut prendre en charge plusieurs sessions simultanées, une table des indicateurs de session distincts avec une relation une à plusieurs personnes pourrait résoudre le problème. Je n'aime tout simplement pas l'idée de stocker des Guidites expirées, car si vous prenez cela au sérieux, vous devez les stocker pour toujours afin de ne pas réactiver les anciennes sessions plus tard. Stockage des GUDS actives, peut-être combiné à une limite plausible de 10 sessions simultanées, limite le nombre maximal de GUIDS Il faudrait stocker.
@ TO0OM: une solution de contournement éventuelle serait de stocker simplement des GUID pour une période limitée, je ne pense pas avoir besoin d'une histoire illimitée.
@Wiktorzychla Je voudrais vous tromper du côté de la prudence si un utilisateur clique sur le bouton "Déconnexion" - Détruisez toutes les sessions du côté serveur de l'identité. Si l'utilisateur souhaite conserver deux sessions sur différents agents utilisateur, ou des machines différentes, elles ne vont probablement pas cliquer sur "Déconnexion". Inversement, vous ne voudrez pas supposer que lorsque l'utilisateur a fait cliquez sur "Déconnexion" qu'elles signifiaient "juste cette session, pas les autres" - hypothèse à haut risque imo. Terminez tous et enregistrez la complexité de suivi de la session côté serveur.
@Mattkocaj: Inversement, vous ne voudriez pas supposer que lorsque l'utilisateur a cliqué sur "Déconnexion" qu'ils signifiaient "juste cette session, pas les autres Voici comment fonctionne la plupart des sites de gros. Vous cliquez sur Déconnectez-vous sur un appareil mais restez connecté partout ailleurs.
@Wiktorzychla Je vois ton point. Mon problème est que beaucoup de ces sites seraient vénérables à une attaque de replay de cookie précisément parce que la "session" n'est pas suivie côté serveur, mais simplement par le client ayant déclaré cookie. Si un utilisateur va aller à la difficulté de cliquer sur "Déconnexion" et j'essayais d'aborder ce Cookie Replay Attack - Protection contre la protection , alors je voudrais échanger l'UX pour la sécurité et détruire toutes les sessions . La complexité de l'OMI est un coût qui a une incidence sur la sécurité de sorte que je choisirais la logique plus simple, la destruction de toutes les sessions et une protection appropriée de replay biscuit. Mais c'est juste moi.
J'ai mis en place un système qui stocke la SessionID dans le cookie d'authentification sur la première demande authentifiée, puis vérifie la session active correspond au cookie sur les demandes suivantes. Détails sur cette réponse. Cela évitait le suivi côté serveur suggéré dans la réponse de @ Wiktorzychla.
Ceci pourrait probablement être amélioré en stockant un hachage de demande IP + Demande.Browser + SessionID dans la session et le cookie authentifiant, plutôt que de la sessionID.
Vous pouvez facilement invalider les billets d'authentification des formes "plus âgés que la date x".
A Vous pouvez, par exemple, faites ceci:
Lorsque vous souhaitez invalider un utilisateur particulier - il suffit de réinitialiser cette date dans la base de données à la date actuelle.
J'ai blogué à propos de ici < / a> Si vous avez besoin d'échantillons de code réels.
Un cas d'utilisation très couramment consiste à "Invalider toutes les sessions créées avant le dernier changement de mot de passe". formesAuthenticationticket a une propriété intégrée appelée émise qui vous permet de le faire.
validsince
Application_acquirequestState (dans global.asax)
de Token (code> émît est plus ancien que la date de la base de données - Déconnexion!
Utilisez-vous HSTS et définissez-vous le drapeau Secure sur les cookies?