Sécurité web offensive : s’entraîner avec Juice Shop

On commence à en parler souvent sur ce blog, mais le meilleur moyen de comprendre les best practices de sécurité c’est d’apprendre à attaquer. Il existe pour ça de très nombreuses ressources de qualité ! Mais c’est en variant les ressources qu’on comprend parfois mieux les subtilités de certains types d’attaques. Les CTF sont un très bon terrain de jeu, mais il faut être dispo à un moment précis. Que diriez-vous donc d’un équivalent mais sur votre machine ? C’est à cet effet qu’OWASP a créé Juice Shop !

Juice Shop est un projet en node contenant toute une flopée de failles aussi diverses que variées. Soit le terrain de jeu idéal pour se former à l’attaque. Je vous propose donc un petit tour d’horizon de ce que propose le projet et comment l’installer.

Installation de Juice Shop

Le projet est simplifié au mieux donc l’installation est au plus simple. Il y a certaines conditions à respecter si vous voulez le déployer sur un env spécifique. Mais partons du principe que nous voulons le lancer sur notre propre machine: rien de compliqué ! Un git clone, un install, un start:

git clone https://github.com/juice-shop/juice-shop.git --depth 1
cd juice-shop
npm install
npm start

Vous pouvez désormais visiter http://localhost:3000/ et vous verrez ceci:

Notons que l’installation peut également directement se faire depuis leur image Docker ou Vagrant si vous préférez.

Notons que comme l’instance prend en compte la progression de l’utilisateur, une instance est supposé être utilisée par un seul utilisateur.

Les challenges

Le gros plus de Juice Shop c’est que les failles sont traquées sous forme de challenges. Pour chacun vous pouvez avoir un (plus ou moins) petit coup de pouce si vous le souhaitez. Vous pouvez donc tenter de les éviter et de tout faire en mode black box. Mais si vous voulez travailler en mode white box avec lecture du code source et une piste de ce que vous cherchez, c’est possible !

Pour ce qui est des vulnérabilités couvertes (zappez vite cette partie si vous ne voulez vraiment aucun indice), vous y trouverez principalement des données sensibles mal cachées, de mauvaises validations de forms, des access controls mal gérés, des XSS, des failles d’authentification, … Voilà la liste exhaustive et la répartition donnée par OWASP:

Les outils nécessaires

Niveau navigateurs ils recommandent un Firefox ou un Chromium. Les challenges nécessiteront de pouvoir inspecter le code source, observer les calls qui sont faits, pouvoir les modifier et les renvoyer, analyser le Javascript, …

Ils recommandent également d’utiliser un proxy intercepteur (et proposent par défaut le leur: ZAP (Zed Attack Proxy). Pour le coup j’ai l’habitude de mon côté d’utiliser la suite Burp. Travaillez avec vos outils de prédilection, le tout est que vous ayez de quoi avancer sur tout et que vous soyez à l’aise.

Pour débuter, soyez discrets. Infiltrés. Marchez le long du Happy Path ! Le « Happy Path », c’est le parcours utilisateur type, la façon dont le site est supposé être utilisé. En clair: explorez le projet comme si vous étiez un utilisateur innocent. En faisant ça depuis Burp directement, ça vous permettra en passant de faire un petit mapping du projet. À partir de là vous avez une bonne connaissance du projet, des différentes pages dispo et surtout une liste de toutes les routes (front et api) avec le payload d’entrée et ce que l’endpoint retourne.

Mais par où commencer ?

Comme je vous l’ai dit, les failles sont traquées sous forme de challenge. Ils sont tous affichés avec leur état de complétion sur le scoreboard. Scoreboard vous dites ? Lequel ?

Le premier challenge proposé est de trouver le scoreboard. Si vous ne l’avez pas vu pendant le Happy Path, c’est donc normal. Il va falloir partir en exploration plus profonde. Une exploration de choses qui ne sont pas forcément accessibles depuis le navigateur !

Je vous laisse donc commencer votre recherche ! Bon courage et bonne exploration du Juice Shop !