Tests de charge & Anti Forgery Tokens

Introduction

Lorsque l’on effectue des tests de charges, nombre de paramètres sont à prendre en compte et notamment l’utilisation d’anti forgery tokens. En effet, dans ce cas précis, si aucun traitement spécifique n’est prévu, le test échouera systématiquement et la campagne de mesure ne pourra pas avoir lieu. Je vais donc vous montrer comment détecter l’utilisation de ces tokens et comment les gérer avec l’aide de Visual Studio.

Qu’est-ce qu’un anti forgery token et à quoi ça sert ?

Ces tokens sont utilisés pour contrer les attaques de type « cross-site request forgery » (CSRF). Ce type d’attaque consiste à envoyer à la victime un lien vers un site qui sera exécuté avec ses droits d’accès. En effet, nombre de sites utilisent une authentification via celle intégrée à Windows ou encore via les cookies. Dans ce cas, si la victime reçoit par mail un lien alors qu’elle est authentifiée, ce dernier pourra être exécuté avec ses permissions.

Pour éviter ce problème, il est possible de mettre en place un token de type « anti forgery ». Concrètement, la méthode effectuant l’action de modification attend un token qui sera généré par la page donnant accès au formulaire de modification. Si le token attendu n’est pas le même que celui généré, la requête échouera. Avec ce mécanisme, il n’est donc plus possible de transmettre un lien à une tierce personne car ce dernier sera systématiquement rejeté.

Diagnostic du problème

Prenons comme exemple l’étape de login du site de démonstration MusicStore. Si l’on enregistre puis que l’on rejoue cette action via un test de charge, on obtiendra invariablement l’erreur suivante :

En examinant le token généré lors de l’appel au formulaire :

Et celui donné en paramètre à l’action de login :

Nous voyons qu’ils sont différents. En effet, le premier est systématiquement généré lors de l’appel à la page tandis que le second est enregistré dans les paramètres du test. C’est cette différence qui fait échouer l’opération.

Solution

Pour résoudre ce problème, la solution semble évidente, il faut récupérer lors du premier appel le token et ensuite le passer en paramètre lors du second. Je vais donc vous montrer comment réaliser cette opération. Pour cela, rendez-vous dans l’onglet « Response » de l’appel au formulaire et sélectionnez l’ensemble de la valeur du champ « __RequestVerificationToken ». Puis, à l’aide d’un clic droit, sélectionnez l’option « Add Extraction Rule ». Cette action aura pour effet de créer une nouvelle entrée dans la rubrique “Extraction Rules” du test.

Pour plus de clarté, renommez cette nouvelle règle via ses propriétés :

Dans la section « Form Post Parameters » de l’étape d’appel du formulaire, vous pouvez voir le token avec une valeur déterminée. C’est cette valeur « en dur » qu’il faut remplacer par notre règle d’extraction.

Pour cela, allez dans les paramètres et dans la rubrique « value », sélectionnez la règle précédemment créée.

Vous devriez alors voir dans la définition du test la sélection de cette nouvelle règle :

Lancez de nouveau le test. La valeur du token sera alors récupérée et donnée en paramètre au formulaire. Le test se déroulera alors normalement :

Conclusion

Cet article montre comment utiliser les règles d’extraction dans le cas précis des « anti forgery tokens » mais cette technique est, bien sûr, adaptable à d’autres situations. Si vous souhaitez en savoir d’avantage, n’hésitez pas à nous rejoindre lors de l’Atelier Tests de Charge prévu en fin de mois.