ASP.NET MVC: Vérifier que l'enregistrement d'édition est autorisé (propriété)

Question

J'ai une application ASP.NET MVC multi-utilisateur. Les utilisateurs ne sont pas censés voir ou faire quoi que ce soit avec les données de l'autre.

Une de mes actions de contrôleur est le POST obligatoire/édition pour éditer un enregistrement (par exemple un contact). Maintenant, voici mon problème: Que se passe-t-il si quelqu'un forge un simple POST à ​​/ Edit (qui se lie automatiquement à ma classe de contact) et modifie les informations de quelqu'un d'autre? Comme chaque enregistrement est identifié par Id, tout ce qui doit être fait est de faire un faux POST avec l'ID XXX et ensuite l'enregistrement # XXX sera écrasé avec tout ce que l'attaquant a fourni. Comment puis-je arrêter cela? La seule chose à laquelle je pensais est de récupérer l'instance originale à chaque fois d'abord dans la base de données, de vérifier qu'elle se trouve dans la portée des objets éditables de l'utilisateur (ceux qu'il verrait d'habitude éditer) et seulement Si cette vérification réussit, continuer avec UpdateModel et valider les modifications de mise à jour.

Y a-t-il un meilleur moyen?

Éditer: Ceci n'est pas une attaque Cross Site/CSRF. Un autre utilisateur connecté peut le faire.

Answer 1

Le chargement de l'enregistrement original d'abord et vérifier le propriétaire semble être une bonne approche à moi. Vous pouvez également ajouter un champ caché contenant l'ID d'enregistrement et le signer cryptrographiquement pour vous assurer qu'il ne peut pas être modifié, ou prendre l'ID d'enregistrement, le hacher en utilisant l'ID utilisateur comme un salt et vérifier cela (en supposant que vous utilisez les fournisseurs de membres, vous devez utiliser le fournisseur ID unique, pas le nom de login)

Answer 2

ce que vous pouvez faire est d'exclure l'ID dans le modèle de liaison avec cette syntaxe:

public ActionResult Edit([Bind(Exclude="Id")] User userToEdit) 

puis chercher l'ID de la Utilisateur connecté en cours à la place, de sorte que c'est seulement l'utilisateur connecté qui peut modifier ses propres éléments et noone elses.

Answer 3

L'autorisation pour la vue/page et l'autorisation pour l'objet particulier sont en réalité deux concepts distincts. La meilleure approche consiste à utiliser un attribut Authorize conjointement avec le système de rôles ASP.NET pour accorder ou refuser l'accès à une page donnée. Une fois que vous avez vérifié que l'utilisateur a accès à la page, vous pouvez vérifier s'il a la permission qu'il demande pour l'objet sur lequel il le demande. J'utilise cette approche dans mon application, et cela fonctionne très bien. En utilisant d'abord le filtre Autoriser, cela améliore considérablement les performances, car la vérification des autorisations d'objets est une opération beaucoup plus lourde.

En outre, j'utilise un système de règles maison brassées pour définir réellement et déterminer si l'utilisateur a accès à l'objet. Par exemple, dans mon système, les administrateurs ont un accès complet à chaque objet. (C'est une règle.) L'utilisateur qui crée les objets a un accès complet à l'objet (également spécifié par une règle). De plus, le gestionnaire d'un utilisateur a un accès complet à tout ce à quoi ses employés ont accès (une fois de plus spécifié par une règle). Mon application évalue ensuite l'objet pour voir si l'une des règles s'applique. sur les règles les plus complexes durent. Si une règle est positive, j'arrête l'évaluation de la règle et quitte la fonction.

Answer 4

Cette question m'a rappelé un article qui couvre un problème similaire (à la lumière des attaques de manipulation d'URL) que j'avais bookmarked. Ils traitent avec un utilisateur authentifié avec les données d'un autre utilisateur.Vous trouverez peut-être utile: link text

Edit: Ce lien doit être correct: Prevent URL manipulation attacks