Sécurité de l'application

L'objectif de cette partie est de simuler un "pentest", c'est à dire un audit de la sécurité de l'application web. On va pour ce faire reprendre quelques unes des étapes principales, mais plusieurs tests seront sautés par manque de temps ou à cause des outils et / ou du niveau technique nécessaires pour les effectuer. A titre indicatif, le guide proposé par OWASP (un organisme de référence) pour tester les applications web fait 465 pages sans contenir les détails techniques...

Reconnaissance

Tout pentest commence par une phase de récupération d'informations. Cette dernière est en général divisée en deux parties : la chercherche d'informations open source sur internet / le(s) site(s) web de l'entreprise (OSINT) et des scans effectués à l'aide d'outils variés. Pour simplifier, on s'arrêtera ici à une recherche d'informations manuelle sur le site web déployé précédemment.

1. Quel est le framework utilisé ? Quelle est sa version ? Possède-t'elle des veulnérabilités connues ?
2. L'application a-t'elle été déployée correctement ? Si non, quelles informations peuvent être récupérées à cause de la ou des erreurs commises ?
3. Y'a-t'il des commentaires ou des fonctionnalités cachées intéressantes dans le code accessible ?

On saute ici plusieurs étapes comme la découverte de subdomaines, l'exploration de tous les chemins de l'application web, l'analyse du code obtenu ou encore des scans avec des outils tels que Nikto et nmap. Ces étapes sont en effet longues et peu intéressantes ou nécessitent l'installation d'outils spécifiques. Elles n'auraient d'ailleurs ici pas mené à grand chose, mais peuvent parfois révéler des vulnérabilités majeures.

Session

En naviguant sur le site, on peut remarquer qu'il existe un système d'utilisateurs et une interface de connexion. Est-elle bien configurée ? C'est ce dont nous allons nous assurer maintenant.

1. Créer un utilisateur puis regader les requêtes effectuées à l'aide de la console du navigateur (elle est généralement accessible en appuyant sur F12). Pourraient-elles être modifiées pour créer un utilisateur admin, par exemple ?
2. Se connecter avec cet utilisateur. De la même manière, regader les requêtes effectuées pour voir s'il serait possible de les modifier pour bypass le processus d'authentification, usurper l'identité d'un autre utilisateur, gagner des droits...
3. Regarder les cookies crées lors du processus de connexion. Sont-ils bien aléatoires ? Un cookie non aléatoire peut être réutilisé ou prédit facilement pour usurper l'identité d'un utilisateur lors d'une attaque. Il peut aussi être modifié (si c'est du texte brut / encodé en base 64 par exemple) pour faire de même ou gagner des droits selon les informations qu'il contient.
4. Modifier une requête de login depuis la console du navigateur de sorte à ce qu'elle corresponde à un email existant et un mot de passe erroné, puis l'envoyer à répétition. Le compte est-il bloqué ? Quel est le risque posé ?

Vous vous serez probablement rendus compte durant cette section que le travail sur les requêtes uniquement à l'aide d'un navigateur peut rapidement devenir très laborieux. C'est pour cette raison que l'outil principal d'un pentester (lors de tests d'applications web) est un proxy tel que Burp Suite permettant entre autres d'intercepter, de modifier et d'envoyer des requêtes HTTP.

Injection SQL

Une injection SQL est une vulnérabilité venant d'un champ mal configuré utilisant un string fourni par l'utilisateur pour effectuer une requête SQL (par exemple une recherche ou une modification dans la base de donnée). Cette vulnérabilité peut être exploitée en mettant du code SQL dans ledit champ afin, par exemple, de lire la base de données arbitrairement.
Ici, le champ de recherche d'utilisateurs a été mal configuré et y est vulnérable. S'en servir pour :

1. Obtenir les mails et usernames de tous les utilisateurs enregistrés.
2. Obenir le mot de passe de l'administrateur.

Rapport

La dernière étape d'un pentest est la rédaction d'un rapport regroupant ce qui a été fait, les vulnérabilités trouvées ainsi que le risque qu'elles posent et des mesures permettant de les résoudre (ou au moins de réduire le danger).
Réféchir à de solutions pour les vulnérabilités trouvées.