Skip to content

Damned Vulnerable Web App (DVWA)

DVWA est une application Web en PHP/MySQL construite avec de nombreuses vulnérabilités dans le but de comprendre les principaux dangers liés aux applications Web.

Pourquoi vouloir attaquer une application Web ?

  • Defacing
  • Exécution de code chez les clients
  • Déplacement latéral

Installation et configuration

Le plus simple est de l'installer avec Docker par contre avec l'image Docker il faut configurer PHP pour autoriser la directive allow_url_include :

docker run --rm -d --name dvwa -p 80:80 vulnerables/web-dvwa
docker exec dvwa grep allow_url_include /etc/php/7.0/apache2/php.ini
docker exec dvwa sed -i 's/^allow_url_include = Off/allow_url_include = On/' /etc/php/7.0/cli/php.ini
docker restart dvwa

Ensuite, il suffit d'aller sur http://localhost et d'entrer le login/mdp par défaut : admin/password puis de finir l'installation.

Utilisation

Une fois installée, l'application vous affichera un menu de gauche avec différents challenges à faire.

Vous pouvez vous aider des liens fournis dans "More informations" ou essayer par vous même.

Brute force

Explications

Le brute forcing consiste à tenter une multitude de couples login/mots de passe jusqu'à arriver à trouver le bon.

Il existe trois méthodes :

  • L'attaque par dictionnaire se sert de listes de login et de listes de mots de passe
  • La recherche (tente toutes les combinaisons possibles)
  • La recherche basée sur des règles tente des combinaisons plus intelligentes. Les règles peuvent se baser sur la qualité des mots de passe supposée (nécessite un ou plusieurs chiffres, un caractère spécial, contient des mots particuliers, ...)

Réalisation

Avec des outils tels que :

  • Bruter: http://sourceforge.net/projects/worawita/
  • THC Hydra: http://www.thc.org/thc-hydra/
  • John the Ripper: http://www.openwall.com/john/
  • Brutus: http://www.hoobie.net/brutus/
  • Basic Auth Bruteforcer: https://market.android.com/details?id=com.firebird.basicauthbruteforcer
  • Cain & Abel: http://www.oxid.it/cain.html

Protection

  • WAF
  • Fail2ban
  • Authentification forte
  • Multi-facteurs

Injection de commande

Explications

Certains services Web interagissent avec le système d'exploitation pour utiliser des commandes systèmes. Si le service est mal protégé un attaquant pour détourner ce système pour exécuter une commande non prévue.

Réalisation

  • Des tests "à la main" suffisent.

Protection

  • Toute donnée entrée par l'utilisateur (en l'occurrence dans un formulaire) doit être vérifiée et "désarmée".
  • Utiliser des librairies plutôt que des commandes système
  • Isoler l'utilisateur du serveur Web et ne pas l'autoriser à faire plus de commandes que celle(s) prévue(s)
  • WAF

CSRF

Explications

Il s'agit de manipuler la requête d'un client pour lui faire exécuter une action non voulue dans une application sur laquelle ils sont déjà authentifiés.

Réalisation

  • Un mail contenant un lien avec une URL forgée
  • Un mail contenant une image appelant un script

Protection

  • Utiliser un framework; Tous les grands framework fournissent des protections anti CSRF.
  • Ou bien utiliser un outil de protection :
  • https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project
  • https://www.owasp.org/index.php/CSRFProtector_Project
  • WAF

File inclusion (FI ou RFI)

Explications

Le script appelle un fichier du système de fichiers. Un utilisateur malveillant pourrait faire appeler un autre fichier et détourner le comportement du script.

Réalisation

  • Remplacer le nom du fichier qui doit être inclus par un autre fichier
  • Scanners de sécurité

Protection

  • Toute donnée entrée par l'utilisateur (en l'occurrence dans un formulaire) doit être vérifiée et "désarmée".
  • Firewall sur les serveurs pour les empêcher d'aller chercher des fichiers sur des serveurs distants
  • Configuration PHP (php.ini) : Désactiver allow_url_fopen, allow_url_include, register_globals
  • Isoler l'utilisateur du serveur Web (containers, jails, ...)
  • WAF

File upload

Explications

Les formulaires permettant de téléverser des fichiers comme des images doivent être particulièrement protégés car on ne peut pas deviner ce que le client envoie. Un utilisateur malveillant pourrait envoyer un script ou un binaire contenant un malware.

Réalisation

  • Téléverser un script
  • Téléverser un binaire
  • Téléverser un fichier compressé non vérifié par un anti-virus
  • Téléverser une image avec un payload non vérifié par un anti-virus
  • https://github.com/chinarulezzz/pixload
  • https://github.com/kohler/gifsicle

Protection

  • Liste blanche des extensions de fichiers (protection faible mais à faire)
  • Vérifier les noms de fichiers
  • Pas de caractères spéciaux (";", ":", ">", "<", "/" ,"\", ".", "*", "%", "$")
  • Pas de noms trop longs
  • Pas de double extension (.pdf.js, ...)
  • Limiter les tailles de fichier (trop petits et trop grands)
  • Vérifier que le fichier téléversé n'en écrase pas un autre
  • Utiliser un anti-virus
  • Utiliser POST plutôt que PUT ou GET
  • Isoler l'utilisateur du serveur Web (containers, jails, ...)
  • Ne pas donner de droit d'exécution aux fichiers
  • Les formulaires d'upload doivent être uniquement accessibles aux utilisateurs authentifiés
  • Vérification avec Content-Type (protection faible car le client peut changer le header pour remplacer le Content-Type)
  • Utiliser un détecteur de type de fichiers (protection faible)
  • Passer le fichier à un anti-virus

Injection SQL (LDAP, NoSQL, etc)

Explications

Les formulaires qui interrogent une base de données, un annuaire LDAP utilisent des requêtes qui peuvent être détournées de leur but inital.

Les injections en aveugle (Blind SQLi) utilisent les réponses des serveurs de base de données pour en déduire les données en fonction des réponses du serveur. Les blind SQLi sont des suites de questions par true or false au serveur.

Réalisation

  • Entrer une requête SQL à la place de la valeur du champs de formulaire
  • http://sqlmap.org/

Protection

  • Prepared Statements
  • Procédures stockées
  • Liste blanche des entrées possibles
  • Vérification et désarmement des données entrées (échappement des caractères spéciaux)
  • ACLs dans la base de données (moindre privilège)
  • WAF

XSS

Explications

Les failles XSS sont des exécutions de code Javascript injectés dans des pages Web bénignes. L'utilisateur exécute le script malveillant sans même le savoir.

Dans la famille des XSS on retrouve :

  • Les XSS locales (DOM) qui sont injectées dans l'URL.
  • les XSS par réflexion (non permanentes) sont injectées dans un champs de formulaire, exécutées directement chez le client mais pas stockées sur le serveur.
  • les XSS stockées (permanentes) utilisent le même principe mais sont stockées définitivement sur le serveur (en base de données ou en fichier).

Réalisation

  • XSS DOM : Forger une URL contenant un script
  • XSS stockées et par réflexion : Entrer du code malveillant dans un formulaire
  • Owasp ZAP et différents outils de pentest

Protection

  • Vérification et désarmement des données entrées (échappement des caractères spéciaux)
  • WAF