« Retour

30 Days of Security Testing – Partie 3/4 : Découvrir les outils

Le principe

Voici notre troisième article consacré au défi lancé par Ministry of Testing au mois de février : 30 Days of Security Testing.

  1. Compulser la documentation
  2. Apprendre les bonnes pratiques
  3. Découvrir les outils
  4. Aller plus loin

Les challenges

Défi 3 : Use a security tool – Examples: ZAP or BurpSuite & Défi 8 : Utiliser un outil de proxy pour étudier le trafic d’un site web ou d’une application mobile

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.

Défi 6 : Explorer Google gruyere, HackYourself First, Ticket Magpie et The BodgeIt store

Google GruyereHack Yourself FirstTicket 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.

Défi 13 : Intégrer un aspect de sécurité dans une user story

Ce défi en cache un autre : comment intégrer les tests de sécurité à un cycle de développement agile ?

Approche « utilisateur honnête »

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 :

  • Lorsque l’utilisateur modifie les paramètres de l’URL en entrant une chaîne de caractères aléatoire (incluant ou non des caractères spéciaux), il est redirigé sur une page d’erreur indiquant « La ressource demandée n’existe pas. »
  • Lorsque l’utilisateur effectue une traversée de chemin, si le répertoire parent ne redirige sur aucune page, il doit rediriger vers la page d’erreur précédemment évoquée. »

Vérifions que cette user story est conforme au modèle INVEST :

  • Indépendante : (oui)
  • Négociable : oui, car la mention « quels que soient les caractères que j’ajoute » peut être précisée selon les besoins du client.
  • Valorisable : oui, et l’intérêt est double : une meilleur expérience client et une meilleure protection des informations techniques du produit.
  • Estimable : (oui)
  • Suffisamment petit : à valider selon la complexité de l’architecture technique du site.
  • Testable : oui, des critères d’acceptabilité sont présents.

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.

Approche hacker

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 :

  • Lorsque l’utilisateur modifie les paramètres de l’URL en entrant une chaîne de caractères aléatoire (incluant ou non des caractères spéciaux), il est redirigé sur la stack d’erreur générée automatiquement par le framework.
  • Lorsque l’utilisateur effectue une traversée de chemin, si le répertoire parent ne redirige sur aucune page, il doit rediriger vers la stack d’erreur. »

Une autre appellation de ce type d’US : abuser story.

Approche implicite

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.

Défi 16 : Trouver comment créer une tiger box

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.

Défi 25 : Trouver et utiliser un outil de sécurité mobile

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 :

  • automatique, par application. A chaque fois qu’il souhaite les utiliser, l’utilisateur déverrouille avec un code d’accès les applications qu’il a choisies.
  • automatique, par géolocalisation. L’appareil devient inutilisable s’il sort d’un périmètre défini par l’utilisateur.
  • manuel, à distance.

L’application avertit l’utilisateur lorsqu’il reçoit des SMS ou MMS malveillants.

Davantage d’informations dans cette documentation.

Conclusion

  • Il existe des sites web spécialement conçus pour qu’on les hacke afin de se former aux tests de sécurité.
  • Des outils permettent d’établir un diagnostic rapide des failles de sécurité les plus connues. Les scans sont si rapides qu’ils peuvent être faits en environnement de test ou de préproduction à chaque nouveau déploiement de l’application.
  • Il est possible d’inclure des outils de test de sécurité dans une chaîne d’intégration continue. Le test de sécurité agile est en pleine expansion.

Un avis ? Un commentaire ?

Cet espace est pour vous.