2009-04-23 4 views
6

Nous avons remarqué qu'il est possible de recréer une copie d'un cookie ASP.NET FormsAuthentication sur une autre machine, ce qui permet la deuxième machine d'authentifier sans avoir besoin de se connecter.Puis-je rendre mon cookie ASP.NET FormsAuthentication plus sûr en l'associant à l'ID de session?

Une solution proposée à ce qui a été pour stocker les ID de session dans FormsAuthenticationTicket.UserData et pour vérifier que les deux valeurs correspondent à Application_AuthenticateRequest().

Nous utilisons:

FormsAuthenticationTicket.IsPersistent = false; 

Cette approche est d'associer cookie FormsAuthentication avec l'ID de session une bonne idée?

+0

Est-ce quelque chose que vous avez réellement essayé? Vous avez effectivement eu une autre connexion de machine en utilisant un cookie d'une autre machine? Je pensais qu'il y avait un cryptage par session. –

+0

Un collègue l'a essayé. Je ne sais pas si un chiffrement a été configuré. – tjrobinson

Répondre

18

Je pense que vous êtes en train de trop penser au problème. La capacité de copier un cookie est simplement un problème inhérent aux cookies - tout le monde peut intercepter n'importe quel cookie et usurper l'identité des données présentes en les installant sur une autre machine. La "sécurité" du cookie d'authentification vient du fait que personne ne peut (soi-disant) fabriquer le cookie à la main pour simuler un utilisateur authentifié. Cependant, une fois le cookie créé, il peut bien sûr être utilisé pour l'authentification. Cela signifie que pour que votre "problème" se produise, vous devez d'abord avoir un utilisateur valide. Si cet utilisateur abuse du système en copiant son cookie sur d'autres machines pour donner accès à tout le monde, c'est exactement la même chose que l'utilisateur qui dit à tout le monde son nom d'utilisateur et son mot de passe, sauf beaucoup plus obtus. Par conséquent, le problème n'est pas la copie du cookie - c'est l'utilisateur lui-même.

Un autre vecteur d'attaque serait si le réseau est compromis et que quelqu'un peut intercepter le trafic pour assembler le cookie via un sniffer ou autre - mais encore une fois, cela est inhérent aux cookies eux-mêmes. C'est ce qu'on appelle le piratage de session, et la seule façon de se protéger contre cela est d'utiliser SSL pour votre site. Si vous êtes vraiment inquiet à ce sujet, je voudrais juste définir votre authentification et vos délais d'attente de session pour être le même, puis dans votre fichier global.asax, il suffit d'appeler FormsAuthentication.Signout() à chaque fois que la session de l'utilisateur expire. Cela invalide l'authentification chaque fois que l'utilisateur a terminé sa session, ce qui l'oblige à se reconnecter plus tard. Bien sûr, cela peut être un désagrément extrême pour vos utilisateurs ...

Je recommande également vivement This MSDN article. Il répond probablement à vos questions beaucoup mieux que je peux.

+0

Merci pour votre réponse - c'est en fait dans le sens de ce que je pensais mais je voulais un deuxième avis avant d'essayer de réparer quelque chose qui n'était pas réellement un problème. Votre FormsAuthentication.Signout() suggéré ne semble pas applicable dans mon cas car le cookie d'authentification expire à la fin de la session, obligeant les utilisateurs à se connecter à chaque nouvelle session. Ou ai-je manqué quelque chose? – tjrobinson

+1

Qu'en est-il du cas où une machine d'un utilisateur est infectée par un virus qui vole son cookie? SSL ne les protégerait pas alors. Je suppose que c'est juste une variante du détournement de session bien que dans ce cas. – tjrobinson

+1

Re: premier commentaire. Je ne pense pas que tu aies manqué quelque chose. J'y ai réfléchi un peu plus la nuit dernière et j'ai pensé que vous pouviez essayer de mettre certaines données utilisateur dans le ticket d'authentification, comme leur adresse IP ou quelque chose, et si ces informations changeaient, les déconnecter automatiquement. Cela rend plus difficile l'usurpation d'identité d'une autre machine ... mais l'adresse IP peut également être usurpée. Ce serait un peu plus sûr si. Re: deuxième commentaire - oui, juste une autre variation. – womp

Questions connexes