Les tests de sécurité
Les tests automatiques sont des outils indispensables pour valider le nombre important de cas d’espèce requis par la volonté
de disposer du meilleur degré de sécurité.
Nous avons discuté de l’importance des tests de sécurité et des différents options dans l’article
La sécurité et Agile .
Les modalités pour créer, exécuter et maintenir ces tests sont divers et le choix n’est jamais simple.
Nous proposons ici une solution qui assure un esprit agile autour des tests de sécurité.
Behavior Driven Development
Behavior Driven Development (BDD, à ne, bien évidemment, pas confondre avec Base De Données) est
une technique Agile qui cible la rupture naturelle qui existe entre
développeurs et analystes fonctionnels
[1]
. Cette méthodologie se propose de remédier à cette rupture en fournissant des techniques et des outils communs utilisables
dans les mêmes conditions à la fois par les développeurs et par les analystes fonctionnels dans l’optique de facilite leur
communication mutuelle. L’une de ces techniques est l’utilisation d’un langage omniprésent (ubiquitous language).
BDD (
Behavior Driven Development) promet aussi la standardisation des critères d’acceptation par une meilleure formalisation
puis l’automatisation des tests fonctionnels. Dans ces conditions, une fonctionnalité est finalisée quand tous les tests
automatiques passent. On peut ainsi dire que les principes du
Test Driven Development qui valent pour les algorithmes, les structures de données et les classes lors des
tests unitaires, deviennent grâce à BDD applicable aux
tests fonctionnels.
Afin de remplir cet objectif,
BDD(
Behavior Driven Development)
se propose de remplacer les classiques documents de spécification avec des spécifications exécutables :
des test automatiques qui servent simultanément comme documentation et comme une garantie de la qualité du projet.
Pour faciliter la participation de chaque membre de l’équipe,
BDD
(Behavior Driven Development) impose l’utilisation d’un langage simple mais formel donc apte à être compris et
maîtrisé par des non-informaticiens. Un de ces langages standardisés est le langage Gherkin
[2]
.
Le texte est très proche de la communication naturelle, décrit la fonctionnalité et vérifie la solution préparée par l’équipe.
Quelques
avantages de BDD (
Behavior Driven Development)
:
- Automatise
les tests d’acceptation - Rend les spécifications exécutables. Nous évitons ainsi la désynchronisation entre des documents, spécifications et cahiers
de tests, et la solution implémentée - Facilite la collaboration entre développeur et analyste fonctionnel
- Standardise les critères d’acceptation
SpecFlow
SpecFlow est un outil
Open Source qui permet l’application de BDD aux
projets .NET, dans Visual Studio
[3]
.
L’accent est mis sur la simplicité et l’automatisation des tâches ancillaires afin que toute l’équipe puisse l’utiliser sans
apprentissage spécifique.
Quelques
avantages de SpecFlow :
- S’intègre dans Visual Studio, la création et l’exécution des spécifications de même que l’implémentation des tests sont
réalisées dans le même environnement que l’implémentation de la solution - Implémente Gherkin comme langage de spécification
- Est compatible avec plusieurs libraires des tests unitaires (NUnit, MsUnit, xUnit, MbUnit)
Tests de sécurité et BDD, une association bénéfique
Nous estimons que
les techniques de BDD (
Behavior Driven Development)
s’appliquent bien aux besoins des projets en matière de
tests de sécurité.
Comme nous l’avons démontré dans un article précédent, les critères de sécurité sont souvent négligés par les équipes de
développement. Nous rappelons que les raisons principales à cet état de fait sont que le sujet de la sécurité est délicat,
complexe, que peu de développeurs possèdent des compétences de haut niveau dans ce domaine et que l’impact n’est pas visible
avant la mise en oeuvre opérationnelle de la solution.
BDD permet à la sécurité de devenir une préoccupation active de toutes les parties prenantes du projet en mettant
en lumière les besoins de sécurité et en imposant une formulation expressive de ces besoins. Exprimer ainsi les besoins
permet de mieux cerner les problématiques sous-jacentes et, in fine, de faire progresser les connaissances en la matière
des parties prenantes.
Des avantages dans l’
utilisation de BDD pour les tests de sécurité :
- La sécurité retrouve son statut d’exigence fonctionnelle
- Les exigences de sécurité sont compréhensible par toute l’équipe
- La «Définition Of Done» et les tests d’acceptation intègrent ces exigences de sécurité
Tests de sécurité et BDD, un cas d’emploi
Un petit exemple va bien cimenter la solution que nous proposons. Pour ce cas spécifique on focalise sur la protection sur
les attaques CSRF (Cross Site Request Forgery)
[4]
sur un site Asp.net MVC. Toutes les formulaires html d’un site web (publique ou même intranet) sont susceptibles a des attaque
CSRF ; un utilisateur doit juste visiter un page malvoyante ou infectée et l’attaque est exécutes sur n’importe quel site.
Pour minimiser les risques CSRF sur http POST on peut se protéger en utilisant des jetons de sécurité au niveaux du formulaire.
Cette valeur unique nous garantit que le formulaire vient après un action délibérée de l’utilisateur et pas d’une manière
automatique.
Pour assurer que notre site a du protection CSRF et pour garantir le non-régression nous allons créer des tests SpecFlow.
L’exécution de ces tests nous garantir continument que l’application reste protégée
L’image ci-dessous présente
la spécification SpecFlow pour
les test CSRF d’un formulaire html.
Comme demandé par
BDD le texte est bien compréhensible par tout l’équipe tant qu’elle serve comme un test automatique de sécurité.
L’implémentation effective de ces tests peut être réalisée avec NUnit et un outil d’automatisation de l’interface web. (comme
Selenium ou Watin)
[5]
Comme exemple d’implémentation du premier scenario en utilisant NUnit et Watin :
Références
- https://wiki.openmrs.org/display/docs/Behavior+Driven+Design+in+OpenMRS
-
https://github.com/cucumber/cucumber/wiki/Gherkin
http://en.wikipedia.org/wiki/Behavior-driven_development - http://www.specflow.org/getting-started/
- http://en.wikipedia.org/wiki/Csrf
- http://docs.seleniumhq.org/
Cet article a été rédigé par Irinel Matei, ex expert .Net Pentalog