2009-03-30 5 views
0

mon client a fait réaliser un audit de sécurité d'un système que j'ai construit pour lui. Ils veulent que cela fonctionne de telle sorte que si un utilisateur se connecte via Internet Explorer, que lorsqu'il se connecte via Firefox sur la même machine (ou via IE sur une autre machine), il tue la première session. Essentiellement, cela signifie stocker des informations de session dans la base de données que j'imagine, puis définir un indicateur actif/inactif par rapport à l'ID utilisateur, l'identifiant de session, le statut si userid a une session active, puis tuer la première session et créer une nouvelle session .Gestion de session utilisateur dans asp.net

Y at-il construit des mécanismes pour ce faire avec le framework .NET ou quelqu'un peut me diriger dans la direction de quelques tutoriels etc.

Un grand merci,

Ed

+0

Pouvez-vous clarifier s'il vous plaît. Si l'utilisateur se connecte à partir d'un autre ordinateur/navigateur, sa session dans les autres navigateurs cesse et continue dans le nouveau navigateur? –

+0

oui correct - l'utilisateur se connecte depuis une autre machine/navigateur et sa session dans les autres navigateurs cesse et continue dans le nouveau navigateur –

+0

@Ian: Je suis d'accord que le "Spec" est trop lâche, et si une autre instance d'IE est utilisée? Est-ce que nous disons que généralement un seul processus de navigateur peut avoir une session active pour un utilisateur? – AnthonyWJones

Répondre

2

Tout d'abord, ajouter un champ à la table de vos utilisateurs pour stocker l'ID de session actuellement utilisé. Cet identifiant est facilement accessible depuis votre code. Lorsque l'utilisateur se connecte, stockez cet ID.

À chaque demande de page, vérifiez que l'ID de session actuel correspond à ce qui était stocké dans votre table utilisateur. Si elle ne correspond pas, effacez les données de session en cours et renvoyez l'utilisateur à l'écran de connexion.

Cela n'empêchera pas l'utilisateur d'utiliser plusieurs onglets dans IE 7 car IE7 utilise la même instance pour chaque onglet; mais cela les empêchera d'utiliser plusieurs instances de navigateur.

La raison pour laquelle cela fonctionne est que chaque navigateur contient son propre espace de cookie. Les sessions sont appariées côté serveur en fonction d'une valeur de cookie qui stocke l'identifiant de session et est renvoyée au serveur à chaque requête. Incidemment, ce n'est pas un moyen très efficace d'éliminer le piratage de session; ce que cela ressemble à la vérification de sécurité essaie d'empêcher. Si vous avez besoin de le faire, mettez à jour votre question et j'irai plus loin.

MISE À JOUR

Une façon d'arrêter le vol de session est de stocker un nombre aléatoire dans la session et comme un cookie sur le navigateur. Lorsque la requête suivante arrive, vérifiez que les valeurs de cookie et de session correspondent. Si ce n'est pas le cas, réinitialisez la variable d'ID de session dans votre table utilisateur. Cela forcera toutes les sessions à se reconnecter. Pour chaque requête de page (post/get), créez une nouvelle valeur aléatoire. L'inconvénient est que les pages ne peuvent pas être mises en signet; mais c'est probablement acceptable.

+0

merci pour la suggestion - cela pourrait fonctionner mais je voudrais que la "nouvelle" session remplace l'ancienne pour que l'utilisateur ne soit pas expulsé. Mais s'ils retournaient au navigateur/pc original et rafraîchissaient ou essayaient d'accéder à quelque chose, ils seraient renvoyés à la connexion –

+0

C'est exactement ce que cela ferait. Chaque fois qu'ils se connectent, il suffit de mettre à jour la table utilisateur avec le dernier ID de session. Lorsque l'ancien fait un get ou un post, il verra qu'il n'est pas à jour alors vous redirigerez vers l'écran de connexion. – NotMe

+0

Ed, c'est essentiellement ce que j'ai fait. Last in wins, sinon vous devez attendre que leur session expire avant de les laisser se reconnecter. – JoshBerke

0

Je blogged sur la façon dont je gère cela. Fondamentalement, l'idée est que nous créons un cookie non persistant, qui a un Guid.

Ensuite, nous stockons ce lié à l'userId dans un endroit sur le serveur (App Cache, DB etc ...). Nous avons ensuite un poller qui frappe le serveur toutes les deux minutes, et si le cookie ne correspond pas à la valeur, nous déconnecter l'utilisateur.

+0

@Josh - approche agréable - certainement m'a donné matière à réflexion –