Serialisation #1
La sérialisation, c'est l'idée de sauvegarder l'état d'un programme pour pouvoir le reprendre au même état plus tard, comme dans les jeux vidéo par exemple. Mais comme toute fonctionnalité en informatique, il existe des vulnérabilités, même pour la sérialisation sur le WEB !
Niveau : Facile
La sérialisation est souvent un élément oublié lorsque l'on construit des applications ! Pourtant c'est un concept essentiel et plus qu'utilisé au quotidien car il vous suffit d'utiliser le local storage ou d'appuyer sur sauvegardé dans votre jeu préféré et vous venez d'utiliser la sérialisation d'objet !
Pourquoi ce lab ?
Comme toute fonctionnalité, la serialisation a aussi ces vulnérabilités qu'il faut avoir en tête, que ce soit pour les exploiter (à vous les cheat infinies dans les jeux) ou pour s'en prémunir !
Mise en place du lab
La première étape est de télécharger les ressources de ce lab, que vous choisissiez d'être de la Red Team ou de la Blue Team, cela n'a pas d'importance.
Les ressources :
Pour démarrer le lab et lancer l'environnement virtuel, deux choix s'offrent à vous : utiliser une version Node.js installée localement sur votre ordinateur, ou en utilisant l'image Docker.
Avec NodeJS en local :
Je vous recommande fortement d'utiliser un gestionnaire de version de Node, tel que ASDF par exemple. Vous trouverez d'ailleurs dans le dossier un fichier .tool-versions contenant la version Node.js actuellement utilisée.
-
Dézipez l'archive et ouvrez un terminal dans le dossier (serialization-main)
-
Rentrez dans le dossiez du lab
$ cd serialization-main -
Installer les dépendances NodeJS avec npm
$ npm install -
Lancer l'application WEB
$ npm run start
Avec Docker :
Pour docker, il vous suffit de construire l'image localement avec la commande docker build, puis de lancer le conteneur en n'oubliant pas d'exposer le port 3001 sur le port de votre choix
-
Dézipez l'archive et ouvrez un terminal dans le dossier (serialization-main)
-
Rentrez dans le dossiez du lab
$ cd serialization-main -
Construire l'image du conteneur
$ docker build -t serialization . -
Lancer l'application WEB
$ docker run -p 3001:3001 serialization
Dans les deux cas, vous obtenez maintenant un site web vulnérable avec une mauvaise serialization sur le port 3001 auquel vous pouvez accéder avec votre navigateur préféré.
Le site web est une application simple pour s'entraîner à viser en cliquant sur une cible mouvante. Plus l'on clique, plus l'on a de points évidemment !
Red Team
Vos objectifs
En tant qu'attaquant, vous avez deux objectifs :
- Réussir à obtenir un score à plus de 6 chiffres sans jouer !
- Changer le score de quelqu'un déjà présent sur le leaderboard (à la hausse ou à la baisse)
Indice 1 : Comment est stocké le score actuellement ?
Indice 2 : Comment est stocké votre prénom pour le leaderboard ?
Solution (Cliquez pour révéler)
Pour réussir à faire un score à plus de 6 chiffres, il est nécessaire de regarder comment le score est stocké dans l'inspecteur d'élément puis dans le LocalStorage. Lorsque l'on clique sur la cible, on voit que l'élément 'score' s'incrémente aussi. Il suffit alors de changer la valeur en dur pour par exemple 999 999, de recharger la page et de sauvegarder son score dans le leaderboard !
Étape 1 : Regarder dans le localStorage :
Étape 2 : Changer la valeur de la clef score
Étape 3 : Recharger la page et inscrire le score
Pour changer le score de quelqu'un, il est nécessaire de connaitre son ID est de le changer dans le localstorage. Par exemple, avec l'ID 2, on peut changer le score de Sid Ali pour un score plus bas à 222 !
Étape 1 : Changer l'ID et le score
Étape 2 : Recharger la page et Sauvegarder
Blue Team
Votre objectif
En tant que défenseur, votre objectif est de modifier le code pour que les deux vulnérabilités ne soient plus exploitables !
Indice 1: Quelle portion du code rend le site vulnérable actuellement ?
Indice 2 : Quelle vulnérabilité sur le site permet à un attaquant de modifier si facilement son score ?
Indice 3 : Quelle vulnérabilité sur le site permet à un attaquant de modifier le score de quelqu'un d'autres ?
Solution (Cliquez pour révéler)
Tout d'abord, pour corriger la seconde vulnérabilité, il est nécessaire d'implémenter un mécanisme d'authentification au lieu d'utiliser l'ID stocké dans le localstorage.
Pour la première vulnérabilité, c'est l'implémentation elle-même qui est vulnérable. Pour obtenir une version sécurisée, c'est le serveur qui doit contrôler notamment l'partition des cibles, avec un identifiant unique que le frontend devra renvoyer lorsque l'utilisateur cliquera avec succès sur la cible. Le score en localstorage peut juste être à titre informatif, mais cela sera uniquement le backend qui calculera le core final.