2009-10-04 5 views
0

J'utilise ASP.NET MVC pour créer une application Web. Dans l'écran principal de l'utilisateur connecté, j'utilise User.Current.Name pour déterminer l'identité de l'utilisateur connecté. Il est mappé à l'ID d'une donnée de modèle de domaine liée à l'utilisateur actuel. Personne d'autre ne devrait pouvoir voir ou éditer cette information (dites son profil).Gestion des droits de sécurité basés sur User.Current.Name dans ASP.NET MVC

J'utilise l'adhésion et les rôles pour garantir que seuls les utilisateurs connectés en particulier le rôle sont en mesure d'invoquer cette action (action Accueil de UserController dans ce cas)

Il va pas HTTPS pour cette application lorsque il est déployé.

Cette approche est-elle considérée comme une approche sûre? Y at-il une chance que l'utilisateur malveillant falsifie son identité pour s'assurer que User.Current.Name renvoie un nom différent? Y a-t-il une configuration supplémentaire requise pour s'assurer que personne ne peut "voler" le cookie d'authentification d'un autre utilisateur?

EDIT: l'authentification par formulaire standard est utilisée.

+0

Vous n'avez pas décrit comment l'utilisateur est authentifié, il est donc presque impossible de répondre si votre approche est sûre. Si, par exemple, vous utilisez un nom d'utilisateur/mot de passe et pas de SSL, c'est loin d'être sûr. –

Répondre

4

OK, donc, en mettant de côté le sniffing HTTP parce que vous n'utiliserez pas SSL, le principal problème est le cookie d'authentification.

Le cookie d'authentification par formulaires/rôles n'est pas crypté par défaut, il est uniquement signé contre la falsification. Vous pouvez chiffrer en utilisant

<forms protection="All" ... /> 

Cela utilisera la clé de la machine spécifiée dans machine.config ou web.config pour chiffrer - donc si vous voulez que les cookies pour vivre dans l'application, vous devrez réutilise set a specific machine key. Vous devez également vérifier les cookies persistants (c'est-à-dire pas d'option "Se souvenir de moi") et veiller à ce que les pages sécurisées nécessitant un accès authentifié soient placées dans des sous-répertoires/contrôleurs séparés des pages accessibles de façon anonyme. Vous pouvez également réduire la durée de vie des cookies, ce qui peut réduire la durée de vie d'un cookie volé.

<forms 
    timeout="10" 
    slidingExpiration="true"... /> 

Vous devez également encodez toutes vos sorties vers des pages Web pour arrêter Cross Site Scripting, comme cela est le principal moyen d'avoir volé des cookies. Le cookie ASP.NET est HTTP-Only, ce qui signifie qu'il ne doit pas être servi via javascript, mais tous les navigateurs ne l'implémentent pas (Safari ne le fait pas).

-2

Tant que vous avez défini la propriété machineKey dans web.conrfig, le cookie est chiffré côté serveur et personne ne peut truquer cette information. Cependant, étant donné que le mécanisme d'authentification standard dans ASP.net MVC est l'authentification par formulaires, vous devez activer SSL pour que personne ne puisse renifler le nom d'utilisateur et le mot de passe lors de la connexion.

Une autre approche consiste à utiliser un mécanisme d'authentification différent. OK, l'authentification des fenêtres, les kerberos, l'utilisation des certificats clients etc.

+0

Merci pour votre réponse. Aucun des mécanismes authentifiés mentionnés ne sont pas une option pour moi. Donc, vous dites essentiellement qu'en plus de renifler le nom d'utilisateur/mot de passe du trafic HTTP, il n'y a pas d'option pour simuler l'identité d'un autre utilisateur dans ce scénario? – Marek

+3

Non true - le cookie n'est pas crypté par défaut. – blowdart

+0

Désolé. J'ai oublié de mentionner pour définir la propriété machineKey dans web.config. Lorsque cela est fait, les deux ticket viewstate et formulaires sont cryptés. –

Questions connexes