Question

Comment vous assurez-vous correctement qu'un utilisateur ne modifie pas les valeurs de chaîne de requête ou les valeurs des actions url? Par exemple, vous pouvez avoir une action Supprimer un commentaire sur votre commentController qui prend un commentID. L’URL de l’action peut ressembler à / Comments / Delete / 3 pour supprimer le commentaire portant l’ID 3.

Maintenant, évidemment, vous ne voulez pas que quiconque puisse supprimer le commentaire 3. Normalement, le propriétaire du commentaire ou un administrateur est autorisé à le faire. J'ai vu cette sécurité renforcée de différentes manières et j'aimerais savoir comment certains d'entre vous y parviennent.

Faites-vous plusieurs appels à la base de données pour récupérer le commentaire et vérifier que l'auteur du commentaire correspond à l'utilisateur invoquant l'action de suppression?

À la place, transmettez-vous les commentaires CommentID et UserID à la procédure stockée qui supprime et effectuez une suppression lorsque UserID et CommentID sont égaux aux valeurs transmises?

Est-il préférable de chiffrer les valeurs de la chaîne de requête?

Était-ce utile?

La solution

Vous n'en avez pas.

C’est une règle de programmation fondamentale, en particulier à l’époque actuelle: vous ne faites confiance à aucune donnée provenant de l’utilisateur, du navigateur, du client, etc.

C’est également une règle de programmation fondamentale que vous ne devriez probablement pas essayer d’implémenter le cryptage et la sécurité vous-même, à moins de savoir vraiment ce que vous faites. Et même si vous savez ce que vous faites, vous ne resterez qu'une longueur d’avance sur les retardateurs. Les plus malins vont encore se moquer de vous.

Effectuez la requête supplémentaire pour vous assurer que l'utilisateur connecté dispose du bon ensemble d'autorisations. Cela simplifiera d'autant plus la vie de chacun.

Autres conseils

Le chiffrement et le déchiffrement des paramètres de requête est un processus trivial et il existe de très bons exemples sur la façon de le faire en utilisant un HttpModule ici sur StackOverflow.

"Vous ne savez pas", "Vous ne pouvez pas" ou "Ce n'est pas facile" ne sont tout simplement pas des réponses acceptables de nos jours ...

Vyrotek: La méthode de saisie n’est pas importante. GET, POST, crypté / obscurci GET - pas de réelle différence. Quelle que soit la manière dont votre application reçoit des commandes, pour effectuer une action administrative, vous devez vous assurer que l'utilisateur émetteur est autorisé à effectuer les tâches qu'il souhaite. La vérification de l'autorisation doit avoir lieu APRÈS que la commande soit reçue et AVANT qu'elle soit exécutée. Sinon, ce n'est pas du tout une sécurité.

Envisagez d'utiliser la technique décrite dans l'article de Stephen Walther Astuce n ° 46 & # 8211; Ne pas utiliser les liens de suppression, car ils créent des trous de sécurité qui utilisent [AcceptVerbs (HttpVerbs.Delete)]

Vous pouvez également autoriser uniquement les actions de post-suppression à supprimer l'action du contrôleur en utilisant l'attribut Accepter les verbes, comme indiqué ci-dessous.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Delete(int? id)
{
    //Delete
}

Ensuite, vous pouvez également utiliser le jeton antiforgery comme indiqué ici:

http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

J'ai fait des choses géniales: prenez la chaîne de requête, compressez-la en Base64 ou encodez-la simplement en hexadécimal, de sorte que " commentid = 4 & ampid; userid = 12345 " devient "code = 1a2b23de12769"

C’est essentiellement "La sécurité par l’obscurité". mais cela fait beaucoup de travail pour quelqu'un qui tente de pirater le site.

Vous ne pouvez pas facilement faire cela.

J'ai de bons souvenirs d'un site qui utilisait des URL d'action pour les supprimer.

Tout allait bien jusqu'à ce qu'ils commencent à chercher dans l'intranet.

Ooops, au revoir les données.

Je recommanderais une solution selon laquelle vous n'utilisez pas de chaînes de requête pour tout ce que vous ne souhaitez pas modifier.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top