Tutoriel DVWA : installation et solutions pour débutants

Qu'est-ce que DVWA ?

DVWA (Damn Vulnerable Web Application) est une application web en PHP et MariaDB rendue volontairement vulnérable, pour que les étudiants, les développeurs et les testeurs d'intrusion puissent s'entraîner légalement sur leur propre matériel. Elle a été écrite par Ryan Dewhurst en 2008 et est aujourd'hui maintenue par Robin Wood (digininja) sur GitHub, gratuite et open source sous licence GPLv3.

La version actuelle est la 2.5, publiée en janvier 2025, qui a ajouté un module dédié aux endpoints OpenAPI vulnérables. Le dépôt officiel contient 19 modules de vulnérabilités : injection SQL, injection SQL en aveugle, injection de commandes, XSS réfléchi, stocké et DOM, CSRF, inclusion de fichiers, upload de fichiers, force brute, identifiants de session faibles, contournement d'autorisation, contrôle d'accès défaillant, contournement de Content Security Policy, logique JavaScript, redirection ouverte, CAPTCHA non sécurisé, cryptographie et le bac à sable API.

Deux choix de conception en font un meilleur support d'apprentissage que la plupart des applications vulnérables. D'abord, chaque page possède un bouton View Source qui affiche le code PHP exact qui traite votre saisie : vous voyez pourquoi votre payload a fonctionné au lieu de le deviner. Ensuite, chaque module existe en quatre niveaux de difficulté, si bien que la même vulnérabilité vous enseigne le contournement de filtre puis le correctif.

Elle figure dans le répertoire OWASP des applications web vulnérables et est packagée dans Kali Linux, ce qui est un signal raisonnable qu'il s'agit du standard de la communauté et non d'un projet GitHub anonyme.

Comment installer DVWA avec Docker

Docker est le bon choix pour une première installation. La voie manuelle implique d'installer Apache, PHP et MariaDB, d'éditer php.ini, de corriger les permissions de dossiers, puis de déboguer ce que votre distribution a fait différemment. La voie conteneur, c'est quatre commandes.

1. Vérifiez que Docker est présent. Lancez docker version et docker compose version. Les deux doivent renvoyer un numéro de version. Docker Desktop inclut déjà Compose ; sous Linux, installez Docker Engine depuis le dépôt officiel plutôt que via votre gestionnaire de paquets, qui livre souvent un Compose plus ancien.
2. Clonez le dépôt. git clone https://github.com/digininja/DVWA.git puis cd DVWA. Utilisez le dépôt officiel. Les miroirs qui traînent sur SourceForge et Docker Hub ont plusieurs années de retard et il leur manque des modules.
3. Démarrez. docker compose up -d. Le premier lancement télécharge l'image préconstruite depuis GitHub Container Registry et prend une minute ou deux.
4. Ouvrez l'application. Rendez-vous sur http://localhost:4280. Le conteneur écoute sur le port 4280, pas le 80, ce qui est de loin la raison la plus fréquente pour laquelle les gens croient que l'installation a échoué.

Sous Kali, sudo apt install dvwa installe la version packagée, documentée sur la page outils de Kali. Elle fonctionne, mais elle est en retard sur la version GitHub, donc il vous manquera peut-être les modules les plus récents. Pour une installation manuelle sous Debian ou Ubuntu, il vous faut apache2, libapache2-mod-php, mariadb-server, mariadb-client, php, php-mysqli et php-gd, avec PHP 7.3 comme minimum absolu.

Première connexion et création de la base

La page de connexion demande des identifiants avant que vous n'en ayez créé. Le login DVWA par défaut est l'utilisateur admin et le mot de passe password. Le README note, avec une ironie visible, qu'ils se cassent très facilement par force brute. Ce n'est pas un accident, c'est le module Brute Force qui se fait un clin d'œil à lui-même.

Une fois connecté, l'application se plaindra que la base de données n'existe pas. Cliquez sur Setup DVWA dans le menu de gauche, descendez tout en bas et cliquez sur Create / Reset Database. Vous êtes déconnecté, vous vous reconnectez, et les cinq utilisateurs d'exemple sont en place. Revenez à ce bouton dès qu'un module se comporte bizarrement : la moitié des questions "DVWA est cassée" sur les forums se règlent en réinitialisant la base.

La page de setup vérifie aussi votre configuration PHP. Deux entrées comptent tout de suite :

• allow_url_include doit être activé pour la partie Remote File Inclusion du module d'inclusion de fichiers. Sur l'image Docker, c'est déjà fait. Sur une installation manuelle, vous éditerez /etc/php/8.x/apache2/php.ini avant de redémarrer Apache.
• Les clés reCAPTCHA ne servent que pour le module Insecure CAPTCHA. Ignorez ce module pour l'instant et ignorez l'avertissement. C'est le seul exercice qui exige un compte externe, et il apprend moins que les autres.

Dans la pratique, le moyen le plus rapide de perdre une heure sur une installation fraîche, c'est le dossier d'upload en écriture. Le module File Upload écrit dans ./hackable/uploads/, et si l'utilisateur du serveur web ne peut pas y écrire, les uploads échouent silencieusement d'une manière qui ressemble à un filtre qui vous bloque. L'image Docker gère ce point. Une installation manuelle, pas toujours.

Les quatre niveaux de sécurité sont le vrai programme

La page Security de DVWA vous laisse régler le niveau sur Low, Medium, High ou Impossible, et c'est là que la plupart des débutants gâchent l'outil. Ils le mettent sur Low, bouclent dix modules en une soirée et en concluent qu'ils savent hacker le web. Low est un tutoriel, pas un laboratoire.

Impossible est le niveau que tout le monde ignore, et c'est celui qui vous rend employable. Le lire après avoir cassé les trois autres est ce qui se rapproche le plus d'un cours gratuit de développement sécurisé. Un rapport qui dit "vous êtes vulnérable à l'injection SQL" vaut quelque chose. Un rapport qui montre la requête paramétrée qui corrige le problème vaut nettement plus.

Solution : injection SQL de Low à Impossible

Le module SQL Injection vous donne un champ qui prend un User ID et renvoie un nom. En Low, le code source tient en une ligne de concaténation de chaînes :

$query = "SELECT first_name, last_name FROM users WHERE user_id = '$id';";

Votre saisie atterrit entre des apostrophes sans aucun échappement, donc le premier travail consiste à sortir de l'apostrophe. Saisissez 1' OR '1'='1 et la condition devient toujours vraie, renvoyant les cinq utilisateurs au lieu d'un seul. C'est votre preuve que le point d'injection existe.

Passons maintenant à quelque chose d'utile. La requête renvoie deux colonnes, donc un UNION doit lui aussi renvoyer deux colonnes :

1' UNION SELECT user, password FROM users#

La sortie liste désormais chaque nom d'utilisateur à côté d'un hash MD5 de son mot de passe. Le # final met en commentaire le reste de la requête d'origine, y compris son apostrophe fermante. Si vous voulez la théorie derrière l'obligation de faire correspondre le nombre de colonnes, notre tutoriel sur l'injection SQL détaille les attaques UNION étape par étape.

Passez en Medium et le champ de saisie devient une liste déroulante. C'est une restriction côté client, autrement dit ce n'est pas une restriction. Interceptez la requête dans un proxy, ou renvoyez-la simplement avec un paramètre id modifié, et vous êtes reparti. Medium passe aussi à mysqli_real_escape_string et supprime les apostrophes autour de la valeur, donc le payload change de forme : plus d'apostrophe à échapper, et 1 OR 1=1 fonctionne directement.

Lisez ensuite le niveau Impossible, qui est le véritable objet de l'exercice :

if( is_numeric( $id ) ) {
    $id = intval( $id );
    $data = $db->prepare( 'SELECT first_name, last_name FROM users WHERE user_id = (:id) LIMIT 1;' );
    $data->bindParam( ':id', $id, PDO::PARAM_INT );
    $data->execute();
}

Quatre défenses empilées : un contrôle de type, une conversion en entier, une requête préparée avec paramètre lié, et une limite de lignes. Il y a aussi un jeton anti-CSRF sur le formulaire. Rien de ce que vous tapez n'atteint l'analyseur SQL sous forme de code, ce qui explique qu'aucun payload ne fonctionne et pourquoi c'est ce modèle qu'il faut copier.

Solution : injection de commandes, XSS et upload de fichiers

Ces trois modules sont ceux qui font la réputation de DVWA, parce que chacun possède un niveau Medium ou High avec un trou de filtre réellement instructif.

Injection de commandes

La page envoie un ping vers l'adresse IP que vous fournissez. En Low, le code est shell_exec( 'ping -c 4 ' . $target ), donc tout ce que vous ajoutez s'exécute sur l'hôte. Essayez 127.0.0.1; whoami et la sortie du ping arrive avec www-data en dessous.

Medium ajoute une liste noire qui supprime && et ; de votre saisie. Cela fait deux séparateurs shell retirés sur au moins cinq. Un pipe passe toujours :

127.0.0.1 | whoami

High étend la liste noire à ||, &, ;, -, $, (, ), l'accent grave, et | suivi d'un espace. Relisez cette dernière entrée. Le filtre retire un pipe suivi d'un espace, et laisse tranquille un pipe seul. Donc 127.0.0.1|whoami passe sans effort.

Ce seul caractère est la leçon la plus précieuse de toute l'application. Les listes noires échouent sur le cas que l'auteur n'a pas imaginé, et trouver ce cas, c'est le métier. La référence OWASP sur l'injection de commandes liste les séparateurs à tester méthodiquement plutôt qu'au hasard.

XSS réfléchi

En Low, le paramètre name est renvoyé directement dans la page, donc <script>alert(1)</script> se déclenche immédiatement. Medium est plus intéressant. Le filtre est le suivant :

$name = str_replace( '<script>', '', $_GET[ 'name' ] );

Une seule chaîne, supprimée une seule fois, sensible à la casse. Trois façons distinctes de passer, et chacune enseigne un réflexe différent. Changez la casse avec <SCRIPT>alert(1)</SCRIPT>. Imbriquez la balise pour que la suppression de la balise interne reconstruise l'externe, avec <scr<script>ipt>alert(1)</script>. Ou évitez complètement le mot avec <img src=x onerror=alert(1)>, le payload qui continue de fonctionner bien après que les deux autres ont cessé.

Upload de fichiers

Low accepte n'importe quel fichier et le dépose dans hackable/uploads/. Envoyez un petit fichier PHP qui exécute une commande passée en paramètre d'URL, ouvrez le chemin que la page vous affiche en retour, et vous avez l'exécution de code.

Medium vérifie deux choses : que la taille est inférieure à 100000 octets et que le type MIME est image/jpeg ou image/png. La taille est réelle. Le type MIME ne l'est pas, parce qu'il provient de l'en-tête Content-Type que votre navigateur envoie et que vous contrôlez entièrement. Interceptez l'upload, remplacez Content-Type: application/x-php par Content-Type: image/jpeg, laissez passer, et le fichier PHP arrive intact. Notre tutoriel Burp Suite couvre le flux intercepter puis modifier si vous n'avez pas encore configuré de proxy.

La règle générale que ce module enseigne : toute valeur envoyée par le client est une suggestion, jamais un fait. Nom de fichier, extension, Content-Type, champs de formulaire cachés, cookies. Tout est contrôlé par l'attaquant.

Les modules que les débutants sautent

Tout le monde fait l'injection SQL et le XSS. Trois modules restent ignorés, et ce sont ceux qui correspondent le plus directement à du travail rémunéré.

• Injection SQL en aveugle. Même vulnérabilité, pas de messages d'erreur et aucune sortie visible. Vous la confirmez avec une condition booléenne ou un délai temporel, puis vous extrayez les données caractère par caractère. Plus lent, moins gratifiant, et bien plus proche de ce à quoi ressemblent les applications réelles une fois le rapport d'erreurs désactivé en production.
• Identifiants de session faibles. Cliquez sur le bouton, regardez le cookie, remarquez qu'il s'incrémente de un. Des identifiants de session prévisibles vous permettent de devenir un autre utilisateur sans toucher à son mot de passe. Dix minutes suffisent et cela change votre regard sur chaque cookie ensuite.
• Inclusion de fichiers. En Medium, le filtre retire ../ et ..\ une seule fois, si bien que ....// se recompose en ../ après le remplacement. Il retire aussi http://, ce que hthttp://tp:// déjoue de la même manière. Dédoubler votre payload pour survivre à un filtre à passe unique est un motif que vous réutiliserez constamment.

Une habitude utile à prendre : après avoir résolu un module en Low, ne passez pas au module suivant. Passez en Medium sur le même. La profondeur sur une seule classe de vulnérabilité bat la largeur sur dix, surtout quand le code source du correctif est à un clic.

Ce que DVWA ne vous apprendra pas

DVWA est excellente sur un point et médiocre sur plusieurs autres. Être honnête sur cet écart vous évite le plateau qui bloque beaucoup d'autodidactes.

Il n'y a aucune phase de reconnaissance. Chaque vulnérabilité est étiquetée, dans un menu, avec un bouton. Un vrai test commence par un nom de domaine et beaucoup d'incertitude, et trouver le paramètre vulnérable représente l'essentiel du travail. DVWA vous offre ce paramètre gratuitement.

La pile technique est datée. C'est du PHP rendu côté serveur, avec des chaînes de requête et des envois de formulaires. Cela enseigne honnêtement les fondamentaux, et les fondamentaux tiennent toujours. Cela ne vous apprend rien sur un front end React qui parle à une API JSON, sur la gestion des JWT, sur GraphQL, ni sur les failles de logique d'autorisation qui dominent les rapports de bug bounty modernes.

Rien ne vous résiste. Pas de limitation de débit, pas de WAF, pas de journalisation, pas de verrouillage de compte. Utile pendant que vous apprenez le payload. Trompeur sur ce que l'on ressent vraiment pendant une mission.

Rien de tout cela n'en fait une mauvaise première cible. Cela en fait une première cible. Servez-vous-en pour apprendre à quoi ressemble chaque classe de vulnérabilité de l'intérieur, puis passez à des environnements où il faut trouver la faille avant de pouvoir l'exploiter. OWASP Juice Shop, une plateforme de labs hébergée ou un programme de bug bounty réel sont autant d'étapes suivantes raisonnables.

Considérations légales et éthiques

• Gardez-la en local. Liez-la à localhost ou à une VM en mode NAT. Une DVWA exposée est une porte dérobée fonctionnelle vers votre propre réseau, et les scanners automatisés en trouvent une en quelques heures.
• Ne réutilisez pas les payloads à la légère. Taper 1' OR '1'='1 dans un formulaire de connexion qui ne vous appartient pas constitue un accès non autorisé au titre de l'article 323-1 du code pénal en France, du Computer Misuse Act au Royaume-Uni, du CFAA aux États-Unis et de législations équivalentes presque partout ailleurs.
• Les programmes de bug bounty sont la voie légale. Ils vous donnent une permission écrite et un périmètre défini. Lisez le périmètre avant de tester, pas après.
• Signalez ce que vous trouvez de manière responsable. Si vous tombez sur une vraie vulnérabilité hors programme, divulguez-la au propriétaire et arrêtez de tester. N'extrayez pas de données pour appuyer votre propos.

Questions fréquentes