Test d'intrusion d'une application web
Contexte
Test d'intrusion en boîte noire d'une application web volontairement vulnérable, WeakApp, pour un commanditaire fictif appelé ACME Corp. Le but était de recenser les vulnérabilités par des tests manuels et automatisés, en prenant l'OWASP Top 10 et le WSTG comme référence, puis de tout rendre dans un rapport directement exploitable.
Une seule cible, http://185.222.145.82 en HTTP, testée sur une plage
horaire donnée depuis une adresse IP déclarée.
Méthodologie
J'ai suivi trois axes, calqués sur le WSTG.
Le premier porte sur l'authentification et les sessions : transport des
identifiants, verrouillage de compte et protection contre le brute-force,
entropie du PHPSESSID, expiration côté serveur, attributs des cookies
(HttpOnly, SameSite, Secure) et contournement d'authentification.
Le deuxième porte sur la sécurité applicative : injections SQL (union, error, boolean), inclusion de fichiers locaux ou distants, XSS, CSRF, SSRF, IDOR et pollution de paramètres.
Le troisième porte sur la configuration et la surface d'attaque : fichiers
oubliés comme admin.php ou phpinfo, fuzzing de répertoires
(/uploads/, /includes/), en-têtes HTTP (CSP, HSTS, X-Frame-Options),
fuites d'informations techniques, méthodes HTTP autorisées et clickjacking.
Côté outils, Burp Suite (proxy, Repeater, Intruder) sous Kali Linux.
Au total, 15 vulnérabilités : 2 critiques, 2 hautes, 6 moyennes et 5 faibles. Le niveau de sécurité global est faible, la couche applicative laisse compromettre entièrement les données de façon directe et reproductible.
Injection SQL, contournement d'authentification
Critique, CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
Le formulaire /login.php ne filtre pas les caractères spéciaux. En
mettant admin comme identifiant et une charge d'injection dans le champ
mot de passe, la clause WHERE de la requête devient toujours vraie. Le
serveur renvoie la ligne de l'utilisateur admin, le script PHP considère
que la connexion a réussi et redirige vers /admin.php.
Impact : accès à l'administration sans identifiants valides, contrôle des fonctions d'admin, lecture, modification ou exfiltration des données.
XSS, vol de session
Haute, CVSS 7.5.
Le champ Content du formulaire « Add New Blog Post », dans le panneau
d'admin atteint via l'injection SQL, n'encode pas ce qu'on y saisit. Une
charge <script> y est enregistrée puis exécutée par le navigateur de
chaque visiteur de blog.php.
Comme les cookies de session n'ont ni HttpOnly ni SameSite, la faille
permet de voler des sessions actives et donc d'usurper un utilisateur ou un
administrateur, de rediriger la victime vers un site malveillant ou de
défigurer la page.
Autres faiblesses
- Surface d'attaque :
admin.phpet les répertoires/uploads/et/includes/trouvés par énumération, plus un IDOR sur les ressources de/uploads/. - Sessions : pas de verrouillage de compte ni de limite sur les tentatives de connexion.
- En-têtes HTTP : CSP, HSTS et
X-Frame-Optionsabsents, ce qui rend le clickjacking possible sur les formulaires ; bannières et erreurs PHP trop bavardes ; bibliothèques JavaScript périmées.
Recommandations
- Passer aux requêtes préparées à paramètres liés pour toute interaction avec la base, et valider les entrées côté serveur.
- Encoder les sorties selon le contexte (HTML, JS, CSS) et poser une CSP
pour bloquer le XSS ; mettre les cookies en
HttpOnly,SameSiteetSecure. - Limiter les tentatives de connexion et restreindre l'accès à l'admin par IP ou VPN.
- Compléter les en-têtes de sécurité, retirer les fichiers oubliés, mettre à jour les composants tiers.
Bilan
Un audit complet, de la reconnaissance jusqu'aux correctifs : méthodologie WSTG, exploitation manuelle sous Burp Suite, notation CVSS v3.1 et un rapport structuré avec synthèse pour la direction, chemins d'exploitation, preuves de concept et recommandations classées par priorité.