Bug Bounty — Méthodologie

Le bug bounty est un programme par lequel une organisation invite des chercheurs en sécurité externes à trouver et signaler des vulnérabilités dans ses systèmes, en échange d’une récompense financière. Cette note couvre la méthodologie de chasse, de la reconnaissance au rapport.

Plateformes§

Programmes publics vs privés§

• Public : tout le monde peut participer. Plus de concurrence, vulnérabilités faciles déjà trouvées.
• Privé : sur invitation. Moins de concurrence, surface d’attaque souvent plus large, meilleurs payouts.
• VDP (Vulnerability Disclosure Program) : pas de récompense financière, mais cadre légal pour signaler.

Comprendre le scope§

Avant toute chose, lire intégralement le programme policy :

Tester hors scope ou ignorer les règles = ban de la plateforme et potentiellement des poursuites légales.

Phase 1 — Reconnaissance§

La recon est la phase la plus importante. Plus la surface d’attaque est cartographiée, plus les chances de trouver une vulnérabilité sur un asset oublié sont élevées.

Enumération de sous-domaines§

# Sources passives (DNS historique, Certificate Transparency)
subfinder -d target.com -o subs.txt
amass enum -passive -d target.com -o amass.txt
assetfinder --subs-only target.com >> subs.txt

# Brute-force DNS
puredns bruteforce wordlist.txt target.com -r resolvers.txt -w brute.txt

# Fusionner et dédupliquer
cat subs.txt amass.txt brute.txt | sort -u > all_subs.txt

# Vérifier lesquels sont vivants
httpx -l all_subs.txt -o alive.txt -status-code -title -tech-detect

Sources de reconnaissance passive§

Enumération technologique§

# Identifier les technologies (CMS, framework, serveur)
whatweb https://target.com
wappalyzer # (extension navigateur)

# Scanner les ports des IP en scope
nmap -sV -sC -p- target.com -oA nmap_results

# Découvrir les endpoints et fichiers
ffuf -u https://target.com/FUZZ -w /path/to/wordlist.txt -mc 200,301,302,403
feroxbuster -u https://target.com -w wordlist.txt

# Fichiers intéressants à chercher
/.env, /.git/config, /robots.txt, /sitemap.xml
/.well-known/, /swagger.json, /api/docs
/backup.zip, /debug, /phpinfo.php, /server-status

Cartographie de l’application§

• Spider l’application (Burp Suite, ZAP) — parcourir tous les liens
• Identifier les fonctionnalités : login, inscription, upload, recherche, export, API, websocket
• Identifier les rôles : utilisateur, admin, API key — tester les transitions de privilèges
• Lire le JavaScript : endpoints API, tokens, logique métier côté client

Phase 2 — Vulnérabilités à chercher§

Par fonctionnalité§

OWASP Top 10 comme checklist§

Vulnérabilités à fort impact§

Les vulnérabilités les mieux payées sont celles qui donnent un accès critique :

Phase 3 — Exploitation et validation§

Principes§

• Prouver l’impact sans causer de dommage. Ne jamais exfiltrer de vraies données utilisateur.
• Utiliser ses propres comptes de test.
• Documenter chaque étape avec des screenshots ou des enregistrements.
• S’arrêter dès que l’impact est démontré (pas besoin de pivoter ou d’escalader dans un bug bounty).

Outils principaux§

Exemple : tester un IDOR§

1. Créer deux comptes : [email protected] et [email protected]
2. Se connecter en tant que victim, naviguer vers /api/profile/456
3. Se connecter en tant que attacker, changer la requête vers /api/profile/456
4. Si les données de victim sont retournées → IDOR confirmé
5. Tester aussi avec les méthodes PUT/DELETE pour mesurer l'impact

Phase 4 — Rédiger le rapport§

Un bon rapport est aussi important que la vulnérabilité elle-même. Un rapport mal rédigé sera sous-évalué, renvoyé pour clarification, ou fermé comme “informative”.

Structure d’un rapport§

Titre : [Type] Description concise avec localisation
  Ex: "IDOR on /api/v2/orders/{id} allows reading any user's order history"

Sévérité : Critical / High / Medium / Low (justifier avec CVSS si possible)

Description : 
  - Ce que fait la vulnérabilité
  - Pourquoi c'est un problème (impact concret)

Etapes de reproduction :
  1. Aller sur https://target.com/endpoint
  2. Intercepter la requête avec Burp
  3. Modifier le paramètre X en Y
  4. Observer que...
  (Chaque étape doit être reproductible par un triager qui ne connaît pas l'application)

Preuve :
  - Screenshots annotés
  - Requêtes/réponses HTTP (depuis Burp)
  - Vidéo si le flux est complexe

Impact :
  - Quelles données sont exposées
  - Combien d'utilisateurs sont affectés
  - Quel est le pire scénario réaliste

Recommandation de correction :
  - Vérification d'autorisation côté serveur
  - Utiliser des identifiants non prédictibles (UUID)

Erreurs courantes§

• Titre vague (“XSS found”) au lieu de spécifique (“Stored XSS in comment field via <img onerror> on /blog/post/{id}”)
• Pas d’étapes de reproduction claires
• Surestimer la sévérité (Self-XSS n’est pas un Critical)
• Envoyer un scan automatique brut (nuclei output) sans validation manuelle
• Soumettre un duplicata sans vérifier les rapports existants (disclosed)

Workflow quotidien§

Choisir un programme
       |
       v
Recon (sous-domaines, endpoints, technologies)
       |
       v
Sélectionner une surface d'attaque
(fonctionnalité précise, API endpoint, asset oublié)
       |
       v
Tester manuellement (Burp Suite)
       |
       v
Vulnérabilité trouvée ?
  /          \
 NON         OUI
  |            |
  v            v
Changer      Valider l'impact
de cible     Rédiger le rapport
             Soumettre

Conseils stratégiques§

• Eviter les programmes saturés : les programmes avec 1000+ hackers et des récompenses faibles sont très compétitifs. Préférer les programmes récents ou de niche.
• Spécialisation : devenir expert d’une classe de vulnérabilités (SSRF, IDOR, race conditions) plutôt que de tout tester superficiellement.
• Automatiser la recon, pas l’exploitation : les scanners trouvent les fruits bas, les findings manuels sont mieux payés et moins dupliqués.
• Lire les rapports disclosed : HackerOne et Bugcrowd publient des rapports résolus (Hacktivity). Etudier ce qui a été accepté et bien payé.
• Tester la logique métier : les scanners ne trouvent pas les failles de logique. Comprendre comment l’application fonctionne et chercher les cas limites.
• Etre patient : le triage peut prendre des semaines. Ne pas harceler l’équipe de sécurité.

Légalité§

Le bug bounty est légal uniquement dans le cadre du programme :

• Tester seulement les assets in-scope
• Respecter les règles d’engagement
• Ne pas accéder aux données d’utilisateurs réels
• Ne pas faire de déni de service
• Ne pas divulguer publiquement avant la correction (responsible disclosure)
• Le safe harbor du programme protège le chercheur s’il respecte les règles

En France, l’article 323-1 du Code pénal punit l’accès frauduleux à un système informatique. Le cadre du bug bounty avec safe harbor constitue une autorisation explicite.

Références§

• HackerOne Hacktivity (hackerone.com/hacktivity) — rapports disclosed publiquement
• PortSwigger Web Security Academy (portswigger.net/web-security) — labs gratuits par catégorie
• OWASP Testing Guide (owasp.org/www-project-web-security-testing-guide) — méthodologie de test complète
• Nahamsec — ressources et streams sur le bug bounty
• Bug Bounty Bootcamp (Vickie Li) — livre de référence pour débuter