Vous êtes sur la page 1sur 21

DVWA : L’application web vulnérable

Damn Vulnerable Web Application (DVWA) est une application Web


PHP / MySQL qui est sacrément vulnérable. Son objectif principal est
d'aider les professionnels de la sécurité à tester leurs compétences et
leurs outils dans un environnement juridiquement correct, à aider les
développeurs Web à mieux comprendre les processus de sécurisation
des applications Web et à aider les étudiants et les enseignants à en
apprendre davantage sur la sécurité des applications Web dans une
classe contrôlée. Le but de DVWA est de pratiquer certaines des
vulnérabilités Web les plus courantes, avec différents niveaux de
difficulté, avec une interface simple et directe. Veuillez noter qu'il
existe des vulnérabilités documentées et non documentées avec ce
logiciel.
On utilise une machine kali linux (10.0.3.3) pour se connecter à dvwa
dans la machine serveur web (10.0.3.2) et exploiter les vulnérabilités.

Brute Force : Low


Dans la machine kali on ouvre dvwa et on essaye de deviner le mot de
passe de l’administrateur ‘admin’ :

On intercepte une demande de connexion non valide avec burpsuite :


On utilise l’outil Hydra en ajoutant le cookie intercepté pour faire le brute
force. On se base sur le dictionnaire ‘ wordlist.txt ’

Résultat :

Brute Force : Medium


On intercepte une demande de connexion non valide avec burpsuite :
On utilise l’outil Hydra en ajoutant le cookie intercepté pour faire le brute
force. On se base sur le dictionnaire ‘ wordlist.txt ’

Résultat :

Le résultat sera le même mais après un certain temps.

Ce retard est dû à une mesure de correction de la vulnérabilité mais qui


ne permet pas de sécuriser l’application contre l’attaque de bruteforce.
Brute Force : High
On intercepte une demande de connexion non valide avec burpsuite :

On utilise l’outil Hydra en ajoutant le cookie intercepté pour faire le brute


force. On se base sur le dictionnaire ‘ wordlist.txt ’

Résultat : 16 mots de passe corrects ce qui est faux.


On clique droit sur l’interface d’authentification puis inspecter l’élément :

On remarque l’existence d’un champ caché nommé user_token

On change le type=’’text’’

L’outil Hydra ne peut pas collecter le csrf token pour poursuivre l’attaque,
on doit donc opter pour un script python.

On installe python3, python3-bs4 (BeautifulSoup : package qui permet


d’analyser les documents HTML et XML et va servir dans l’extraction du
user_token utilisé)
Le script python : hack.py
Exécution du script :
Csrf Attack: Low
Test de l’interface de changement de mot de passe :

On a changé le mot de passe d’admin à 0000, on remarque que dans


l’URI en haut le mot de passe est en clair.

On peut changer le mot de passe d’un utilisateur connecté à l’application


si on peut l’invite à cliquer sur une publicité qui le redirige vers l’URI en
haut mais avec un mot de passe qu’on connait mais lui non.

La publicité :
Code source de la publicité :

Test : on clique sur le bouton ‘ GET IT ’ le résultat est :

Le clic sur le bouton ‘ GET IT ’ va changer le mot de passe en 1234


Csrf Attack : Medium
On invite l’utilisateur à cliquer sur la pub de nouveau :

Le résultat :

C’est impossible de changer le mot de passe.

Mesure de correction : on vérifie d’où vient la requête http, si le


server_name n’est pas contenu dans le http_referer on reçoit une erreur
de changement de mot de passe.
La solution sera d’intercepter la requête venant d’une source inconnue
avec le proxy de burpsuite puis ajouter le http-referer dans la requête
pour qu’elle semble légitime puis on fait forward vers le serveur dvwa.

Interception et ajout du referer :

On résume la requête avec forward & intercept is off :


Csrf Attack : High
Mesures de correction : Utilisation du user_token pour valider la
connexion.

On inspecte l’élément et on copie le user_token qu’on l’ajoute dans la


page web publicité :
On invite l’utilisateur à cliquer sur la pub et son mot de passe sera
changé :
SQL injection : Low
L’interface sert à donner le nom et prénom d’utilisateur a partir de son ID

En ajoutant une clause union dans l’ID on peut afficher les mots de
passe des utilisateurs:
On peut ainsi cracker les mots de passe trouvés :

SQL injection : Medium


Mesures de correction : on utilise une liste déroulante pour choisir l’ID de
l’utilisateur au lieu d’un champ de saisie.
On peut contourner ces mesures en interceptant les données d’une
requête légitime avec burpsuite et les changer :

Résultat :
SQL injection : High
Mesures de correction : Utilisation d’un nouvel onglet pour la saisie de
l’ID.

On peut contourner cette mesure en insérant dans l’onglet les mêmes ID


contenant des requêtes malveillantes :
XSS Stored : Low
On injecte le script malveillant dans le champ de message :

Résultat :
XSS Stored: Medium
Mesure de correction : Le script ne s’exécute plus dans le champ
message et remplace la balise <script> par le vide.

On peut contourner cette mesure en inspectant le champ ‘name’,


augmentant sa taille maximale qui est limitée à 10 en 100 puis on injecte
le script malveillant :
XSS Stored: High
Mesures de correction : Remplacement de tout caractère qui peut former
une balise {<,s,c,r,i,p,t,>} par le vide.

On peut contourner cette mesure en utilisant d’autres balises :

Résultat :