2010-05-18 8 views
6

Je suis en train de concevoir une application web dans ASP.NET/C# où chaque utilisateur enregistré a la possibilité d'ajouter/modifier/supprimer des lignes en fonction de son identifiant utilisateur.Approche de sécurité dans une application web

Prenez cet exemple:

Je vais modifier mon itinéraire sur la page /route.aspx?routeid=854 qui me appartient (user-id: 1).

Mais parce que je suis un gars curieux, j'essaie d'accéder à /route.aspx?routeid=855 qui appartient à un autre utilisateur (user-id: 2).

Comment puis-je éviter au mieux que des personnes accèdent aux données d'autres personnes? Devrais-je envoyer chaque identifiant d'utilisateur (de la session) avec chaque appel de base de données, devrais-je valider l'utilisateur/mot de passe sur chaque chargement de page ou quelle est l'approche la meilleure et la plus sûre?

J'espère que je l'ai fait assez clair.

Répondre

3

NE PAS RÉINVENTER LA ROUE

Editer: Stocker UserId - vous n'avez pas à. Vous pouvez l'obtenir à partir du MembershipProvider à tout moment tant que l'utilisateur est connecté bien sûr:

MembershipUser user = Membership.GetUser(); 
Guid UserID = user.ProviderUserKey; 

me semble que vous devez mettre en œuvre le fournisseur d'appartenances ASP.NET. Avoir une lecture de cette ressource: http://odetocode.com/articles/427.aspx

En outre, une bonne série de Scott Guthrie: http://weblogs.asp.net/scottgu/archive/2006/02/24/ASP.NET-2.0-Membership_2C00_-Roles_2C00_-Forms-Authentication_2C00_-and-Security-Resources-.aspx

En général, cette approche: Utiliser l'authentification par formulaire pour valider un utilisateur qui est. C'est le côté Authentification de la sécurité. C'est-à-dire, déterminer l'utilisateur est qui ils disent qu'ils sont, généralement avec un nom d'utilisateur et mot de passe.

La deuxième partie de la sécurité est Autorisation, qui se produit une fois que vous savez qui est l'utilisateur. Cela consiste essentiellement à déterminer à quelles ressources un utilisateur authentifié a accès. Un système mature comprend les entités suivantes:

User: may contain extended profile information captured on registration 
Resource: a page or other resource that can be restricted. 
Group: a group of users who can access resources due to their group membership (groups are granted resource access) 
Role: a type of user such as Administrator/Developer/Salesperson. 

Ainsi, d'accorder un accès utilisateur à routeid 854 (une ressource), vous pouvez accorder la ressource directement à l'utilisateur ou s'il y a plusieurs utilisateurs qui doivent avoir acceses à cette ressource et ces utilisateurs forment un groupe naturel, puis créent ce groupe, accordent la ressource au groupe et ajoutent l'utilisateur au groupe.

Ensuite, vous pouvez accéder à User.Resources par un identifiant de ressource ou vous pouvez protéger une page entière à l'aide

if(!User.IsInRole("RoleName")) 
{ 
    //redirect to access denied page 
} 

Il y a beaucoup de bonnes choses disponibles à l'aide du modèle de fournisseur.

Editer: Quelque chose à savoir si vous décidez de stocker des informations de profil sur vos utilisateurs: L'implémentation par défaut de ProfileProvider n'est pas particulièrement bonne. Scott Guthrie a écrit un bon article sur un fournisseur basé sur une table qui est meilleur: http://weblogs.asp.net/scottgu/archive/2006/01/10/435038.aspx

+0

J'utilise le fournisseur ASP.NET MemberShip pour effectuer la connexion. Mais agréable de voir quelques informations sur les informations personnalisées. :-) Aller à lire plus de cela .. – janhartmann

+0

Good stuff: Il y a aussi un bon exemple de code ici: http://asp.dotnetheaven.com/aspnet/doc/security/membership.aspx#auth –

+0

En ce qui concerne le stockage de l'UserId , regardez le Modifier en haut de ma réponse. –

3

Votre meilleure approche serait d'envoyer l'ID utilisateur à la base de données avec l'ID route pour voir si l'utilisateur peut y accéder.

quelque chose comme:

select * from route where [email protected] and [email protected] 

Si vous utilisez quelque chose comme Linq vous pouvez faire un bien meilleur modèle de sécurité en appliquant la restriction de l'utilisateur comme une fonction réutilisable comme ceci:

public Route Get(int routeId, int userId) 
{ 
    var query repository.Get<Route>().Where(r => r.Id == routeId); 
    query = applySecurityModel(query, userId); 
    return query.FirstOrDefault(); 
} 

private IQueryable<T> applySecurityModel<T>(IQueryable<T> query, int userId) where T : ISecurable 
{ 
    return query.Where(t => t.UserId == userId); 
} 

public interface ISecurable 
{ 
    int UserId { get; set; } 
} 

public class Route 
{ 
    int Id { get; set; } 
    int UserId { get; set; } 
} 
+0

Où est la meilleure façon de stocker cet ID utilisateur? Session? – janhartmann

+0

Et dois-je valider l'utilisateur actuel correspond à cet ID utilisateur sur le chargement de la page? – janhartmann

+1

Sauvegardez le côté serveur userID (par exemple dans l'objet Session) et NON le côté client (par exemple dans un cookie). – Aurril