Dans les CTF orientés web, l’énumération est souvent la clé pour trouver la première faille. Parmi les outils essentiels, Dirb s’impose comme un classique : rapide, simple et redoutablement efficace pour débusquer des répertoires ou fichiers cachés.
Comment Dirb détecte les dossiers (brute force + wordlists)
Dirb fonctionne selon un principe simple : il teste en rafale des noms de dossiers et de fichiers en les ajoutant à l’URL cible, puis analyse les codes de réponse HTTP pour déterminer si l’élément existe ou non. Il s’appuie sur deux mécanismes fondamentaux.
DISCLAIMER : Cet article est une démonstration d’utilisation que vous pouvez par exemple utiliser dans le cadre d’un CTF, il ne s’agit en aucun cas d’utiliser ce genre d’outils hors cadre légale. 0xhack.fr ne pourra être tenu responsable si une mauvaise utilisation est faite.
1. La wordlist (liste de noms préétablie)
Dirb n’invente rien : il lit une wordlist contenant des milliers de répertoires et fichiers courants (admin, login, backup, index.php, dev/, dashboard/, etc.). Pour chaque entrée de la wordlist, il construit une URL :http://site.com/<mot-de-la-list>
Les wordlists intégrées (comme common.txt) sont complétées par des versions plus agressives (big.txt, mutations, extensions).
2. La logique bruteforce du protocole HTTP
Pour chaque URL générée, Dirb envoie une requête HTTP GET.
Il observe ensuite le code retour :
- 200 → le fichier ou dossier existe
- 301/302 → souvent un dossier valide (redirection)
- 403 → accès interdit mais existant
- 404 → inexistant
Dirb ne se base pas sur le contenu des pages : il exploite uniquement le comportement du serveur. Si un code HTTP indique qu’un chemin existe, le script l’ajoute au résultat.
Scénarios typiques en pentest
Identifier des pages d’administration cachées
Les applications web disposent souvent de chemins sensibles comme /admin/, /manage/, /dashboard/ ou /panel/ qui ne sont jamais visibles dans l’interface publique. Dirb permet de découvrir ces répertoires en bruteforçant des noms courants et en analysant les codes de réponse HTTP, même lorsque le directory listing est désactivé côté serveur.
Découvrir des fichiers sensibles accessibles
Il est courant de trouver des fichiers .bak, .old, .zip, .tar.gz, .sql ou d’anciens exports laissés sur le serveur. Ces fichiers ne sont jamais référencés sur le site, mais on ne les identifie facilement en testant des milliers de chemins possibles.
Cartographier des environnements internes (dev, test, staging)
De nombreux environnements exposent involontairement des répertoires internes comme /dev/, /test/, /staging/ ou /beta/. Ces dossiers contiennent souvent des fichiers de configuration, des scripts incomplets, des logs ou des pages non protégées. Dirb aide à dresser une cartographie complète de ces zones oubliées.
Révéler des endpoints API non documentés
Certaines APIs REST ou GraphQL comportent des endpoints cachés : /api/v1/hidden, /internal/, /backup/, etc. Ces chemins ne sont pas accessibles via le frontend et échappent à un crawler classique. Dirb peut les identifier par bruteforce en testant des milliers de noms utilisés habituellement par les développeurs.
Compléter l’énumération après un scan initial
Après un scan Nmap, WhatWeb ou une analyse des fichiers statiques, Dirb est utilisé pour valider des hypothèses. Un nom repéré dans un JavaScript, une entrée dans robots.txt ou un header HTTP suspect peut être testé automatiquement pour confirmer la présence de répertoires cachés.
Détecter les répertoires protégés (403, 401, redirections)
Même lorsqu’un répertoire est protégé, Dirb interprète correctement les codes HTTP :
- 403 → le dossier existe mais l’accès est interdit
- 301/302 → redirection, généralement signe que le dossier est valide
- 401 → authentification requise
- 404 modifié → peut révéler une politique de masquage côté serveur
Cette analyse fine permet de cartographier la structure interne d’un site au-delà des limites du navigateur.
Comment installer Dirb sur Linux ?
Dirb est disponible sur le repo GitHub ici. Présent par défaut sur Kali Linux.
Vous pouvez installer Dirb via cette commande :
sudo apt-get install dirb
FAQ – Questions fréquentes sur Dirb
Comment fonctionne Dirb ?
Dirb envoie automatiquement des requêtes HTTP basées sur une wordlist contenant des noms de dossiers et fichiers courants. En analysant les codes de réponse (200, 301, 403, etc.), il détecte les chemins existants, même lorsqu’ils ne sont pas visibles dans l’interface du site.
Dirb ou Gobuster ?
Dirb est fiable et simple, mais Gobuster est en général plus rapide grâce au multithreading natif. Pour les tests intensifs ou les gros sites, Gobuster est souvent préféré. Dirb reste utile pour les environnements limités ou les wordlists très spécifiques.
Dirb détecte-t-il les fichiers hidden ?
Oui. Dirb ne dépend pas du directory listing. Il force l’accès à chaque chemin via une URL brute. Si le serveur renvoie un code indiquant l’existence du fichier, on l’ajoute aux résultats, qu’il soit caché ou non.
Dirb passe-t-il les .htaccess ?
Non. On ne contourne pas un .htaccess correctement configuré. Toutefois, un code 403 retourné lors du scan indique qu’un chemin existe mais est protégé. Cela permet d’identifier les dossiers sensibles même sans pouvoir y accéder.
Comment accélérer Dirb ?
Dirb peut être optimisé en réduisant les wordlists, en ciblant des extensions précises via -X, en évitant les redirections via -r ou en ajustant les délais avec -z. Pour des performances réellement supérieures, il vaut mieux utiliser Gobuster ou ffuf.
Quelle wordlist utiliser ?
Les wordlists par défaut de Dirb (common.txt, big.txt) fonctionnent bien pour les scans généraux. Pour un pentest plus complet, les wordlists de SecLists (directories, files, extensions, CMS) offrent de bien meilleurs résultats. Adapter la wordlist au contexte de l’application est toujours la meilleure approche.
Cheat sheet Dirb
Voici un mémo rapide des options Dirb les plus utiles en pentest web. La syntaxe générale est :
dirb <URL> [WORDLIST] [OPTIONS]| Commande / option | Rôle | Exemple |
|---|---|---|
dirb <URL> | Scan basique avec la wordlist par défaut | dirb http://target.local/ |
dirb <URL> <WORDLIST> | Utiliser une wordlist personnalisée | dirb http://target.local/ /usr/share/dirb/wordlists/common.txt |
-X <ext1,ext2> | Tester des extensions spécifiques | dirb http://target.local/ common.txt -X .php,.bak,.txt |
-x <fichier_ext> | Charger une liste d’extensions depuis un fichier | dirb http://target.local/ common.txt -x extensions.txt |
-a <agent> | Changer le User-Agent | dirb http://target.local/ common.txt -a "Mozilla/5.0" |
-H <header> | Ajouter un header HTTP (auth, host, etc.) | dirb http://target.local/ common.txt -H "Host: vhost.local" |
-c <cookie> | Envoyer un cookie | dirb http://target.local/ common.txt -c "PHPSESSID=abc123" |
-p <proxy:port> | Passer par un proxy (Burp, etc.) | dirb http://target.local/ common.txt -p 127.0.0.1:8080 |
-N <code> | Ignorer un code HTTP (404 custom, etc.) | dirb http://target.local/ common.txt -N 404 |
-i | Recherche insensible à la casse | dirb http://target.local/ common.txt -i |
-r | Désactiver la récursion automatique | dirb http://target.local/ common.txt -r |
-o <fichier> | Sauvegarder les résultats sur disque | dirb http://target.local/ common.txt -o dirb-output.txt |
-z <ms> | Ajouter un délai (ms) entre les requêtes pour limiter le bruit | dirb http://target.local/ common.txt -z 200 |
-S | Mode silencieux (n’affiche pas chaque mot testé) | dirb http://target.local/ common.txt -S |
En pratique : combiner -X pour cibler des extensions sensibles, -H/-c pour mimer un vrai utilisateur, -p pour passer par Burp, et -o pour conserver un rapport exploitable ensuite.
Dirb reste un outil incontournable pour l’énumération web : simple, rapide et redoutablement efficace pour révéler des répertoires cachés et des fichiers sensibles, à condition d’être utilisé dans un cadre légal et maîtrisé. Vous pouvez notamment en avoir besoin lors d’une formation en hacking.
