Écrire des rapports gagnants

La différence entre être payé et être ignoré

Ce que vous allez découvrir

Compétences que vous maîtriserez

🔧 Modèle de rapport

Utilisez cette structure pour chaque rapport. Chaque section a un but :

## Résumé
[Une phrase : Quelle vulnérabilité, où, qu'est-ce qui est affecté]
But : Permettre aux triageurs de comprendre rapidement le problème

## Type de vulnérabilité
[IDOR, XSS, SSRF, SQLi, etc.]
But : Aide à la catégorisation et l'assignation

## Étapes de reproduction
1. [Étape exacte - soyez précis]
2. [Étape exacte - incluez URLs, paramètres]
3. [Étape exacte - quoi cliquer, quoi observer]
But : Quelqu'un non familier avec l'app devrait reproduire en <5 min

## Impact
[Que peut faire un attaquant ? Quelles données sont à risque ? Qui est affecté ?]
But : Justifie l'évaluation de sévérité et le paiement

## Preuve de concept
[Captures d'écran, requêtes/réponses HTTP, vidéo pour bugs complexes]
But : Prouve que la vulnérabilité est réelle, pas théorique

## Correction suggérée (Optionnel)
[Brève recommandation, pas de code]
But : Montre que vous comprenez la cause racine

Principe clé : Écrivez comme si le lecteur n'avait jamais vu l'application et avait 5 minutes pour valider votre rapport.

Écrire des rapports efficaces

Mauvais rapport vs bon rapport

La différence de qualité affecte directement si vous êtes payé :

"J'ai trouvé un IDOR sur votre site. Corrigez svp."

## Résumé
Vulnérabilité IDOR dans /api/invoices/{id} permet à tout
utilisateur authentifié d'accéder aux factures d'autres utilisateurs
contenant des PII (noms, adresses, historique d'achats).

## Type de vulnérabilité
IDOR (Insecure Direct Object Reference)

## Étapes de reproduction
1. Se connecter en tant qu'Utilisateur A sur https://<target>/login
   (J'ai utilisé le compte test : test-user-a@example.com)
2. Naviguer vers "Mes factures" dans le tableau de bord
3. Ouvrir les DevTools du navigateur (F12) > onglet Network
4. Cliquer sur une facture pour la voir
5. Observer la requête : GET /api/invoices/12345
6. Noter l'ID de facture de l'Utilisateur A (12345 dans cet exemple)
7. Modifier la requête en /api/invoices/12346
   (incrémenter l'ID de 1)
8. Observer : La facture appartenant à un AUTRE utilisateur est retournée

## Impact
Tout utilisateur authentifié peut énumérer et accéder à TOUTES les factures
du système en itérant à travers les IDs.

Chaque facture expose :
- Nom légal complet
- Adresse domicile
- Adresse email
- Historique d'achats complet
- Méthode de paiement partielle (4 derniers chiffres)

Avec environ 50 000 utilisateurs sur la plateforme, cela
représente une exposition significative de PII et un risque de conformité RGPD.

## Preuve de concept
[Capture d'écran : Factures de deux utilisateurs différents accédées depuis
une seule session authentifiée]
[Requête/réponse Burp montrant les appels API]

## Correction suggérée
Valider que l'utilisateur authentifié possède la facture demandée
avant de retourner les données. L'API devrait retourner 403
Forbidden pour les factures appartenant à d'autres utilisateurs.

Démontrer l'impact

L'impact détermine le paiement. Un impact vague obtient une faible sévérité ; un impact spécifique obtient des évaluations plus élevées :

# IMPACT FAIBLE (paiement probablement bas)
"Un attaquant pourrait lire des données."

# Pourquoi c'est faible :
# - Quelles données ? Données utilisateur, logs système, infos publiques ?
# - Combien ? Un enregistrement, tous les enregistrements ?
# - Qui est affecté ? Un utilisateur, tous les utilisateurs ?

# IMPACT FORT (justifie une sévérité plus élevée)
"Un attaquant peut accéder pour n'importe quel utilisateur :
 - Nom légal complet
 - Adresse domicile
 - Adresse email
 - Historique d'achats complet
 - Détails de méthode de paiement (4 derniers chiffres de la carte)

 Avec environ 50 000 utilisateurs sur la plateforme, cela
 expose des PII significatives et crée un risque réglementaire :
 - RGPD : Jusqu'à 4% du chiffre d'affaires annuel en amendes
 - CCPA : Jusqu'à 7 500$ par violation intentionnelle
 - PCI-DSS : Potentielle violation de conformité

 L'exploitation nécessite uniquement l'authentification (tout utilisateur
 peut faire cela) et peut être automatisée pour extraire tous les enregistrements
 en minutes."

# TECHNIQUES DE QUANTIFICATION D'IMPACT :
- Compter les utilisateurs affectés : "Tous les 10 000 utilisateurs enregistrés"
- Estimer l'exposition financière : "Accès à X$ de données de transaction"
- Identifier les implications de conformité : RGPD, HIPAA, PCI-DSS
- Décrire le potentiel d'automatisation : "Peut extraire tous les enregistrements via script"
- Référencer l'escalade de privilèges : "Pourrait accéder au panneau admin"

Comprendre le scoring CVSS

CVSS (Common Vulnerability Scoring System) est un moyen standardisé d'évaluer la sévérité des vulnérabilités sur une échelle de 0 à 10. Comprendre CVSS vous aide à évaluer précisément les vulnérabilités et justifier votre évaluation.

Niveaux de sévérité et exemples

# CRITIQUE (CVSS 9.0-10.0) - P1
Exemples :
- Exécution de code à distance (RCE)
- Bypass d'authentification vers admin
- Injection SQL avec accès à la base de données
- Prise de compte affectant tous les utilisateurs

Paiement : Typiquement 1 000$ - 50 000$+

# ÉLEVÉ (CVSS 7.0-8.9) - P2
Exemples :
- IDOR exposant des PII sensibles
- XSS stocké affectant de nombreux utilisateurs
- SSRF avec accès au réseau interne
- Escalade de privilèges

Paiement : Typiquement 500$ - 5 000$

# MOYEN (CVSS 4.0-6.9) - P3
Exemples :
- XSS reflété nécessitant une interaction utilisateur
- CSRF sur des actions sensibles
- Divulgation d'informations limitée
- Open redirect (dépend du contexte)

Paiement : Typiquement 100$ - 1 000$

# FAIBLE (CVSS 0.1-3.9) - P4
Exemples :
- Self-XSS (n'affecte que vous-même)
- Headers de sécurité manquants (impact limité)
- Divulgation d'informations sans données sensibles
- Problèmes de rate limiting avec impact minimal

Paiement : Typiquement 50$ - 200$

# INFORMATIF - P5
Exemples :
- Recommandations de bonnes pratiques
- Pas d'impact sécurité démontré
- Vulnérabilités théoriques

Paiement : Généralement aucun, ou reconnaissance seulement

Bases du calculateur CVSS

Utilisez le calculateur CVSS officiel sur https://www.first.org/cvss/calculator/3.1. Voici ce que signifient les métriques clés :

# VECTEUR D'ATTAQUE (AV) - Comment l'attaquant peut-il atteindre la vulnérabilité ?
Network (N):  Exploitable à distance via Internet
Adjacent (A): Nécessite le même segment réseau (WiFi, LAN)
Local (L):    Nécessite un accès système local
Physical (P): Nécessite un accès physique à l'appareil

# COMPLEXITÉ D'ATTAQUE (AC) - Quelle difficulté pour exploiter ?
Low (L):  Pas de conditions spéciales nécessaires
High (H): Conditions spécifiques ou préparation requises

# PRIVILÈGES REQUIS (PR) - Quel niveau d'accès nécessaire ?
None (N):  N'importe qui peut exploiter (non authentifié)
Low (L):   Nécessite un compte utilisateur normal
High (H):  Nécessite un compte admin/privilégié

# INTERACTION UTILISATEUR (UI) - La victime doit-elle faire quelque chose ?
None (N):     L'attaquant peut exploiter directement
Required (R): La victime doit cliquer un lien, visiter une page, etc.

# MÉTRIQUES D'IMPACT
Confidentiality (C): L'attaquant peut-il lire des données ? None/Low/High
Integrity (I):       L'attaquant peut-il modifier des données ? None/Low/High
Availability (A):    L'attaquant peut-il perturber le service ? None/Low/High

# EXEMPLES DE CALCULS CVSS :
IDOR exposant toutes les données utilisateur :
  AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5 (Moyen)

RCE via upload de fichier :
  AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 (Critique)

XSS reflété :
  AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N = 6.1 (Moyen)

Erreurs courantes de rapport

Questions fréquemment posées

🎯 Vous savez écrire des rapports gagnants !

Structure claire, étapes de reproduction spécifiques, impact quantifié, évaluation CVSS appropriée - vous savez maintenant comment écrire des rapports qui sont payés. Rappelez-vous : la même vulnérabilité paie 10x plus avec un rapport bien écrit.

Prêt à éviter les doublons et fermetures N/A