Un avis ? Un commentaire ?
Cet espace est pour vous.
Voici notre troisième article consacré au défi lancé par Ministry of Testing au mois de février : 30 Days of Security Testing.
Comme nous privilégions les solutions open-source, notre choix s’est tourné vers ZAP (Zed Attack Proxy, anciennement WebScarab). ZAP est une application lourde qui peut être enrichie par une gamme d’extensions. BurpSuite nous a semblé prometteur, mais comme les fonctionnalités qui nous intéressaient le plus sont payantes (voir le tableau des formules), nous l’avons laissé de côté.
La prise en main de ZAP est très rapide. Une fois l’installation terminée, l’utilisateur est invité à entrer une URL à attaquer. Après validation, le diagnostic commence.
Attention, il faut avoir une autorisation écrite pour attaquer un site qui n’est pas à soi. Pour tester ZAP, nous avons d’abord lancé une analyse en local sur notre test ISTQB.
Après quelques secondes, une liste d’alertes est générée, qui affiche les failles de sécurité identifiées.
Dans le détail de chaque alerte, il est clairement expliqué en quoi la pratique mise en avant est dangereuse, par exemple, ci-dessous, la corrélation directe entre absence d’en-tête X-Frame-Options et risque de ClickJacking. Dans cet exemple, la traduction française est prise en charge, mais ce n’est pas toujours le cas.
Dans un deuxième temps, nous avons réalisé une attaque sur une de nos applications de test, qui contient un formulaire d’inscription. Et là, ZAP s’en donne à coeur joie : en une minute, une centaine de nouveaux comptes sont créés. Aucune alerte n’apparaît, mais le problème est bien visible.
Google Gruyere, Hack Yourself First, Ticket Magpie et The BodgeItStore sont de sites à vocation pédagogique que contiennent de nombreuses failles de sécurité. Ce sont des terrains de jeu où l’utilisateur est encouragé à effectuer des tests de sécurité. Retenez bien ces adresses ; le nombre d’applications dont vous avez le droit de tester la sécurité est très réduit, et celles-ci en font partie.
Lançons un scan ZAP sur Hack Yourself First. Comme promis, une flopée de failles de sécurité sont découvertes :
Rendons-nous sur la page où est diagnostiquée la première erreur.
Maintenant, si nous entrons une valeur inattendue pour le paramètre orderby (par exemple « youpi »), l’erreur n’est pas correctement gérée ; nous obtenons une stack d’erreur qui contient des informations fort intéressantes. Ici, en fin de page, le type et la version du framework utilisé pour développer cette application.
Un comportement à la fois risqué d’un point de vue de la sécurité, et désagréable d’un point de vue UX.
Nous avons découvert un autre site proposant des exercice des hacking, Hack this Site!, qui propose des tutoriels de hacking à niveau croissant.
Ce défi en cache un autre : comment intégrer les tests de sécurité à un cycle de développement agile ?
Si l’on reprend l’exemple précédent d’un point de vue utilisateur, cette user story pourrait être :
« En tant qu’utilisateur (inscrit ou non) de Supercar Showdown, je veux obtenir une réponse compréhensible quels que soient les caractères que j’ajoute à la suite de l’URL, afin que mon expérience sur le site soit fluide et cohérente.
Critères d’acceptation :
Vérifions que cette user story est conforme au modèle INVEST :
Certaines affirmations sont entre parenthèses car elles dépendent du reste du projet (autres US, taille de l’équipe, durée des sprints, complexité de l’application…), élément sur lesquels nous n’avons pas assez d’informations.
Afin d’intégrer pleinement les tests de sécurité aux projets agiles, la fondation OWASP (Open Web Application Security Project, qui est à l’origine du logiciel ZAP) recommande de créer des user stories « diaboliques » (evil user stories), dont le protagoniste n’est autre qu’un hacker. L’enjeu est, à chaque sprint, de s’assurer que ces user stories ne passent pas dans la colonne « terminé ». Nous aurons alors :
« En tant que hacker, je peux accéder aux stacks d’erreur afin de collecter des informations techniques sur l’application. »
Critères d’acceptation :
Une autre appellation de ce type d’US : abuser story.
Une autre approche consiste enfin à intégrer la sécurité dans la définition de « terminé ». Quelques exemples d’implémentation de cette stratégie peuvent être trouvés ici.
Une tiger box est un ordinateur contenant les outils requis pour réaliser un audit de sécurité. Cet ordinateur doit pouvoir mettre à disposition plusieurs systèmes d’exploitation. Cela peut se faire en créant plusieurs options de boot ou en utilisant des outils tels que VirtualBox.
La distribution Linux nommée Kali Linux est une tiger box en soi. Dédiée à la sécurité informatique, elle contient une suite d’outils de test d’intrusion.
La fondation OWASP propose une application mobile de sécurité gratuite nommée SeraphimDroid. Elle identifie rapidement les failles de sécurité d’un téléphone, ajoute un niveau de sécurité supplémentaire en permettant plusieurs types de verrouillage :
L’application avertit l’utilisateur lorsqu’il reçoit des SMS ou MMS malveillants.
Davantage d’informations dans cette documentation.
Cet espace est pour vous.