Je porte une application ASP.NET à MVC et devez stocker deux éléments relatifs à un utilisateur authentifié: une liste de rôles et une liste d'ID d'élément visible, pour déterminer ce que l'utilisateur peut ou ne peut pas voir.
Nous avons utilisé WSE avec un service Web dans le passé et cela rendait les choses incroyablement complexes et impossibles à déboguer correctement. Maintenant, nous tapons le service Web que je cherchais à simplifier considérablement la solution simplement pour stocker ces choses à la session. Un collègue a suggéré d'utiliser les rôles et les fournisseurs d'adhésion, mais à la recherche de cela, j'ai trouvé un certain nombre de problèmes:
a) il souffre de problèmes similaires mais différents au WSE en ce sens qu'il doit être utilisé de manière très contrainte de manifester cela difficile même d'écrire des tests;
b) la seule option de mise en cache pour les résultats du processeur est basée sur des cookies que nous avons rejetés sur des motifs de sécurité;
c) il n'introduit aucune fin des complications et des bagages extra non désirés;
Tout ce que nous voulons faire, en un mot, stockez deux variables de chaîne dans une session d'utilisateur ou quelque chose d'équivalent de manière sécurisée et de les renvoyer lorsque nous devons. Ce qui semble être un travail de dix minutes a jusqu'à présent pris plusieurs jours d'investigation et pour susciter le problème que nous avons maintenant découvert que les identifiants de session peuvent apparemment être trompés, voir
Je suis parti en pensant qu'il n'y a pas de moyen facile de faire ce travail très simple, mais je trouve cela impossible à croire.
Quelqu'un pourrait-il:
a) fournit des informations simples sur la manière de sécuriser les sessions ASP.NET MVC, car je croyais toujours qu'ils étaient?
B) suggère un autre moyen simple de stocker ces deux variables de chaîne pour obtenir des rôles d'utilisateur connectés, etc. sans avoir à remplacer un cauchemar complexe avec un autre comme décrit ci-dessus?
merci.
7 Réponses :
Le seul moyen de faire une cinnection sécurisée est d'utiliser SSL. Quelque chose de moins que cela, et vous devez simplement faire l'évaluation quand c'est "assez sûr".
Une variable de session fonctionne bien pour stocker une valeur, à l'exception de l'exception du serveur Web pour laquelle le serveur Web peut être recyclé de temps en temps, ce qui entraînera la perte de la session. Lorsque cela se produira, vous devrez ré-authentifier l'utilisateur et définir à nouveau la variable de session.
La variable de session elle-même est totalement sûre en ce sens qu'elle ne quitte jamais le serveur que si vous le copiez spécifiquement à une réponse.
J'aurais dû dire, nous utilisons SSL donc pas de problèmes là-bas. En outre, nous n'avons jamais eu de problème avec le recyclant de sessions, donc je ne suis pas inquiet à ce sujet.
Comme pour les variables de session étant complètement sûres: c'est ce que je pensais, mais l'article que j'ai lié à suggère que l'on peut tromper un utilisateur à joindre une session existante, de différentes manières et ainsi la partager avec l'utilisateur authentifié qui se connecte et Il stocke ainsi tous leurs propres rôles à utiliser par l'autre personne. La solution évidente à celle-ci était de stocker l'adresse IP de la session et de le vérifier à chaque fois, mais apparemment, il est facile de simuler cela dans la demande. Tandis que j'ai été incapable de faire de la manière suggérée des moyens de
Rejoindre un travail de session existant, je préférerais savoir pourquoi ils ne sont pas que de compter sur mes compétences évidentes en tant que pirate informatique. Si j'étais confiant sur cela, je pense que nous avons résolu le problème mais jusqu'à présent, je ne suis pas.
J'ajouterais que je peux éviter que je puisse corriger un cookie de session manuellement, mais qui s'appuie sur la connaissance de l'ID de session à définir et que nous utilisons SSL, je ne pense pas que ce soit un problème. Le piratage s'appuierait sur l'envoi d'un lien vers un utilisateur qui les a obtenu, pas le pirate informatique, de rejoindre une session existante (instanciée par le pirate informatique), puis de vous connecter à elle.
La connexion SSL a sa propre carte d'identité de session qui n'est pas stockée dans un cookie, de sorte que l'article à propos de l'entrepoiffage de la session ID Cookie ne s'applique pas. L'ID de session SSL n'est pas exposé, et même si vous parvenez à la saisir, vous ne pouvez pas la réutiliser dans une autre connexion SSL.
Avez-vous envisagé de configurer une étiquette d'autorisation personnalisée dans MVC. J'ai donné un exemple de cela dans un autre Question .
Lors de l'autorisation initiale (écran de connexion ou démarrage de session), vous pouvez également semer une valeur de session avec l'adresse IP également. Ensuite, dans votre autorisation personnalisée, vous pouvez également vérifier que la propriété intellectuelle correspond toujours également. Cela aidera à s'assurer que quelqu'un ne «volera» de la session de la personne. Chaque fois que vous accédez à vos données de session, assurez-vous de transmettre l'adresse IP du demandeur et d'avoir un chèque dessus.
essayez-vous de contrôler l'accès aux fonctions au niveau du client? C'est la seule raison pour laquelle j'exposerais les rôles et les éléments pour contrôler les fonctions latérales du client.
Alternativement, vous pouvez créer une fonction pour obtenir les éléments que les rôles de l'utilisateur sont autorisés à utiliser, puis même si la fonction est appelée en dehors des éléments rendus à l'application Web, vous pouvez empêcher l'utilisateur de y accéder.
4Guys semble montrer comment contrôler les fonctions avec les rôles. < / p>
L'approche que j'ai utilisée dans le passé est d'utiliser un cryptage symétrique d'un cookie aux côtés de SSL. Cryptez les informations de l'utilisateur dans la réponse et la déchiffrer dans la demande. Je ne prétends pas que cela est infaillible ou 100% sécurisé et je ne voudrais pas faire cela sur une demande bancaire, mais c'est assez bon pour de nombreuses fins.
Le problème principal avec les variables de session est que si vous les stockez InproC plutôt que de les persister, vous devez appliquer des sessions «collantes» à votre équilibrage de la charge dans un environnement de ferme Web. Guffa est correct que sans que ces variables de session de persévérance soient occasionnellement perdues, ce qui entraînera une mauvaise expérience utilisateur.
Les sessions collantes peuvent entraîner un équilibrage irrégulier de la charge, ce qui réduit peut-être la valeur de pouvoir augmenter.
Si vous voulez bien persister les sessions afin qu'elles puissent être accessibles par tous les serveurs de votre ferme Web, vous risquez peut-être mieux d'utiliser un GUID pour identifier l'utilisateur, crypter ceci dans un cookie et récupérer l'enregistrement d'utilisateur de votre magasin de données à chaque fois.
Ma question évidente est que pourquoi voulez-vous stocker un rôle d'utilisateur en session?
Voici ma réponse à votre requête, comment cela vous aide. J'ai joint une petite demande de démonstration pour que vous envisagez de regarder et de comprendre mes points. Lorsque vous ouvrez ce projet dans Visual Studio, cliquez sur l'onglet Projet en haut et sélectionnez Configuration ASP.NET. De la page qui montrera que vous pouvez effectuer les trucs d'administration des utilisateurs.
Vous devez stocker les rôles d'un utilisateur de manière sécurisée? La réponse à cette question est qu'il n'est pas nécessaire de vous inquiéter de stocker le rôle de tout utilisateur, lorsque nous avons le cadre d'adhésion, de profils et de rôles ASP.NET pour nous aider à sortir. Tout ce que vous avez à faire est de créer un rôle dans la base de données ASPNET et d'attribuer ce rôle à l'utilisateur.
Ensuite, vous voulez stocker deux chaîne de manière sécurisée. Je vous suggère de votre profil d'utilisateur pour stocker des informations spécifiques à l'utilisateur. De cette façon, vous avez les informations à votre disposition où que vous souhaitiez dans la classe Profilecommon.
Veuillez consulter la demande de démonstration ci-jointe placée à la fin de mon blog http://blogs.bootcampedu.com/blog/post/reply-a-httpstackoverflowcomQuestions1672007USER-Roles-Phy-not-store-in-session.aspx
stocker les informations sur le rôle de l'utilisateur dans une session de côté serveur est en sécurité fournissant une session ne peut pas être détournée. Repasez cela plus largement, peu importe où les informations de rôle utilisateur sont stockées si une session authentifiée est détournée.
Je conseille de ne pas mettre trop confiance dans l'article que vous avez lié à, mais le rapport vintage de 2002 liée à votre lien est d'intérêt. Voici mes emporter:
n'accepte pas les identifiants de session intégrés aux URL.
Concentrez votre temps sur l'élimination des dangers de script croisés croisés I.E. Scannez tous les données fournies par l'utilisateur et analysez le script Java exécutable.
Émettre des cookies pour des domaines complets (par exemple myapp.mydomaine.com)
hébergez votre domaine à un opérateur DNS de haute classe par ex. celui qui permet uniquement à DNS change d'une adresse IP distante préréglée.
Ne pas émettre des cookies de session persistantes.
RUISSUE Un cookie de session Si une personne arrive à une page de connexion avec une sessionId déjà associée à une session authentifiée.
mieux encore, émettez toujours un nouveau cookie de session sur une authentification réussie et abandonner la session précédente. (Peut-il être configuré dans IIS?)
Juste une suggestion, vous pourriez envisager d'utiliser cette petite bibliothèque:
http://www.codeproject.com/kb/aspnet/univar.aspx
Il a une implémentation côté serveur de la cookie dans laquelle tous les cookies peuvent être stockés sur le serveur lors de l'authentification ASP.NET permettent d'identifier l'utilisateur. Il prend en charge le cryptage et est également très flexible, il est très facile de passer d'un type de stockage à un autre.