cyber / pentest-red-team

Bug bounty : méthodologie et éthique

Leçon 181 exercice

Explication

Ce que vous allez apprendre

Lire et respecter strictement le scope et les règles d'un programme de bug bounty
Mener une reconnaissance étendue de sous-domaines à grande échelle
Rédiger un rapport de vulnérabilité clair, reproductible et orienté impact métier
Appliquer les principes de la divulgation responsable (disclosure)
Classer une vulnérabilité par sévérité de façon cohérente et argumentée

Dans quel contexte ?

Un chercheur en sécurité souhaite tester légalement ses compétences sur des applications réelles en production, en dehors de tout contrat de pentest classique. Le bug bounty offre exactement ce cadre : une entreprise publie un programme définissant précisément ce qui peut être testé, en échange d'une récompense pour toute vulnérabilité valide signalée dans les règles établies. Ce cadre n'a de valeur que si le chercheur respecte scrupuleusement les limites fixées — les dépasser transforme une activité légale en acte potentiellement répréhensible.

D'abord, la règle absolue avant toute action : le scope

Avant même de lancer le premier outil, il est impératif de lire intégralement le scope du programme : quels domaines et IP sont autorisés, lesquels sont explicitement exclus, quels types de tests sont interdits (le déni de service et l'ingénierie sociale le sont presque systématiquement). Tester en dehors de ce périmètre, même "juste pour vérifier", n'est plus couvert par le safe harbor légal que la plateforme peut offrir au chercheur.

Prérequis

Cette leçon suppose une bonne maîtrise des techniques de reconnaissance et des classes de vulnérabilités web (XSS, IDOR, SSRF) déjà vues dans ce parcours — le bug bounty en est une application dans un cadre contractuel spécifique.

Piège courant

Un chercheur pressé de trouver une vulnérabilité néglige parfois de vérifier que le sous-domaine découvert appartient bien au scope autorisé. Un sous-domaine techniquement lié à l'entreprise mais explicitement exclu du programme reste hors limites, quelle que soit la vulnérabilité trouvée dessus.

Une fois le scope validé, la reconnaissance peut commencer méthodiquement

Des outils comme subfinder pour découvrir des sous-domaines, combinés à httpx pour identifier les hôtes actifs et nuclei pour appliquer des templates de détection communautaires, permettent une reconnaissance à grande échelle — une étape souvent décisive en bug bounty, où la surface d'attaque exacte n'est jamais totalement documentée par l'entreprise elle-même.

Sévérité	Exemple type
Critique	RCE, prise de contrôle de compte admin
Élevé	IDOR sur données sensibles, SSRF vers infra interne
Moyen	XSS stocké sans interaction complexe
Faible	Fuite d'information mineure

Il reste l'étape la plus déterminante pour la crédibilité du chercheur : le rapport

Un rapport efficace a un titre spécifique (jamais "XSS trouvé", mais "XSS stocké dans le champ bio du profil utilisateur"), des étapes de reproduction numérotées et vérifiables par un tiers, et un impact expliqué en termes métier compréhensibles au-delà du cercle technique.

Bonne pratique

Ne jamais divulguer publiquement une vulnérabilité avant sa correction ou un accord explicite de l'entreprise, et respecter les délais de disclosure coordonnée usuels (souvent 90 jours). Cette discipline protège autant les utilisateurs finaux de l'application que la crédibilité et la réputation du chercheur lui-même.

Ce cadre légal et éthique du bug bounty complète la vision méthodologique de ce parcours. La prochaine leçon élargit le terrain vers un environnement de plus en plus central dans les audits actuels : le cloud, où la surface d'attaque se déplace du code vers la configuration.

Commandes & code

Bug bounty : méthodologie et éthique

Le bug bounty permet de tester légalement des systèmes réels, à condition de respecter strictement le programme publié.

# Avant toute action sur un programme de bug bounty
1. Lire intégralement le scope : domaines/IP autorisés, domaines EXCLUS explicitement
2. Lire les règles : types de tests interdits (souvent DoS, ingénierie sociale, spam)
3. Vérifier le safe harbor : la plateforme protège-t-elle légalement le chercheur dans le scope ?
4. Ne jamais tester en dehors du scope, même "juste pour vérifier"

# Reconnaissance étendue pour du bug bounty : découverte de sous-domaines à grande échelle
subfinder -d example.com -silent | httpx -silent -o hosts_actifs.txt
nuclei -l hosts_actifs.txt -t cves/ -severity critical,high
# nuclei exécute des templates de détection communautaires contre des CVE/misconfigurations connues

# Rédaction d'un rapport de bug bounty efficace (augmente la probabilité de récompense et de crédibilité)
- Titre clair et spécifique (pas "XSS trouvé" mais "XSS stocké dans le champ bio du profil utilisateur")
- Étapes de reproduction numérotées, précises, reproductibles par un tiers
- Impact réel expliqué en termes métier (pas seulement technique)
- Preuve de concept minimale et non destructive (jamais d'exfiltration réelle de données de production)
- Suggestion de remédiation

# Éthique du chercheur en sécurité (disclosure responsable)
- Ne jamais divulguer publiquement une vulnérabilité avant correction ou accord explicite de l'entreprise
- Ne jamais accéder à plus de données que nécessaire pour prouver la vulnérabilité
- Signaler immédiatement toute donnée sensible découverte accidentellement, sans l'exploiter davantage
- Respecter les délais de disclosure coordonnée (souvent 90 jours, norme Google Project Zero)

# Classification de sévérité couramment utilisée (CVSS) adaptée au contexte bug bounty
Critique : RCE, prise de contrôle de compte admin, accès base de données complète
Élevé    : IDOR sur données sensibles, bypass d'authentification, SSRF vers infra interne
Moyen    : XSS stocké sans interaction complexe, CSRF sur action sensible
Faible   : XSS reflected nécessitant une interaction utilisateur complexe, fuite d'information mineure

Résumé

Le scope et les règles du programme priment sur toute autre considération, sans exception.
Un rapport clair, reproductible et orienté impact augmente fortement les chances de récompense.
La disclosure responsable protège à la fois le chercheur et les utilisateurs finaux de l'application.
La sévérité doit toujours être argumentée avec un impact métier concret, pas seulement technique.

Exercices pratiques

1 disponible

Mission : traiter une découverte hors scope sur le programme NordShield

Objectif : Appliquer strictement les règles d'un programme de bug bounty et rédiger un rapport de vulnérabilité crédible et actionnable.

Contexte

NordShield lance son premier programme de bug bounty public. Le scope autorise *.nordshield-lab.example mais exclut explicitement legacy.nordshield-lab.example.

Résoudre l’exercice →