bugcrowd/templatesDépôt pour héberger des modèles markdown destinés aux chercheurs
Notes sur la structure du répertoire :
Le script generate-directories.py récupère la dernière version en date de la structure VRT depuis GitHub et crée les répertoires manquants. Il ne supprime ni ne renomme les répertoires en fonction des éléments retirés de la VRT.
Le script suit les noms d'entrée standard et conserve les underscores / la casse tels que fournis par le champ id de la VRT.
Ce dépôt a le « Protected Master » activé, ce qui signifie que seuls les administrateurs du projet peuvent commiter sur la branche master, via des Pull Requests. Toutes les mises à jour doivent passer par une pull request pour garantir l'intégrité.
Ce qui suit est rédigé en supposant qu'un accès SSH est correctement configuré.
Tout d'abord, récupérez la branche master :
git clone [email protected]:bugcrowd/templates.git ## n.b. using SSH aliases can make this much simpler
Une fois que vous avez master sur votre système, vous devrez créer une branche pour le travail que vous vous apprêtez à effectuer :
git checkout -b <branch-name>
Voici des exemples de noms de branche : XXE-templates, XSS-templates, quelque chose qui indique le lot de travail concerné. Ces branches doivent rester de petite taille, de préférence un groupe de modèles et pas beaucoup plus. Committez et pushez souvent !
git commit -am "Comments about what you changed go here" enregistre vos modifications dans le dépôt git local. Laissez toujours un message de commit descriptif.
Lorsque vous avez terminé vos modèles, vous pouvez les pousser vers le dépôt. Ils resteront sur leur propre branche, mais au moment du push, le linter s'exécutera et validera le markdown par rapport à un ensemble de règles. Si vous avez suivi le modèle d'exemple sans trop vous en écarter, les modèles devraient être validés par le linter.
git push --set-upstream origin <branch-name> Cette commande crée la branche sur le serveur d'origine (github) et pousse vos modifications. Cette opération n'est nécessaire qu'une seule fois pour la branche ; les pushs suivants de cette branche peuvent être effectués avec git push.
Une fois que le linter s'est exécuté avec succès, vous pouvez alors créer une Pull Request (PR).
Sélectionnez la branche dans l'interface GitHub. Vous devriez voir un bouton « Pull request » au-dessus du code.
Cliquez sur ce bouton, puis renseignez quelques détails sur ce qui a changé afin que les administrateurs du projet puissent les examiner, puis cliquez sur « Create pull request ».
À ce stade, vous avez terminé ! Nous examinerons la PR, puis nous la fusionnerons ou la rejetterons selon le cas.
Une fois la PR acceptée, vous pouvez supprimer la branche.
git branch -d <branch-name>
Vous trouverez ci-dessous un exemple de modèle. Toutes les sections doivent être mises à jour avec les informations correctes.
## Overview of the Vulnerability
Provide a 1-2 sentence description of the vulnerability.
This format is a good guide:
[VULNTYPE] in [COMPONENT] in [APPLICATION] allows [ATTACKER] to [IMPACT] via [VECTOR]
## Business Impact
Provide an example of the impact to the business. This could be reputational damage, financial loss, a loss in customer trust, etc.
## Steps to Reproduce
Provide a step-by-step walkthrough on how to access the vulnerable injection point, and how to exploit the vulnerability.
Example:
1. Login to in-scope asset at <www.bugcrowd.com/login>
1. Browse to account page
1. Modify ID token to add single quote
1. View error which states 'SQL Syntax Error'
1. Replace ID value with `1' waitfor delay '00:00:10'; `
## Proof of Concept (PoC)
Your submission must include evidence of the vulnerability and not be theoretical in nature.
You may present your evidence as output from a tool, such as SQLMap, unless the program forbids the use of these tools. Evidence may also be in the format of terminal output, screenshots, or video.
Use this section to demonstrate clearly the effect of the vulnerability. However, do not access Personally Identifiable Information (PII).
Voici un exemple de modèle :
# Reflected Cross-Site Scripting (Non-self)
## Overview of the Vulnerability
Reflected Cross-Site Scripting (XSS) is a type of injection attack where malicious JavaScript code is injected into a website. When a user visits the affected web page, the JavaScript code executes and its input is reflected in the user’s browser. Reflected XSS can be found on this domain which allows an attacker to create a crafted URL. When opened by a user, this URL will execute arbitrary Javascript within that user’s browser in the context of this domain.
When an attacker can control code that is executed within a user’s browser, they are able to carry out any actions that the user is able to perform, including accessing any of the user's data and modifying information within the user’s permissions. This can result in modification, deletion, or theft of data, including accessing or deleting files, or stealing session cookies which an attacker could use to hijack a user’s session.
## Business Impact
Reflected XSS could lead to data theft through the attacker’s ability to manipulate data through their access to the application, and their ability to interact with other users, including performing other malicious attacks, which would appear to originate from a legitimate user. These malicious actions could also result in reputational damage for the business through the impact to customers’ trust.
## Steps to Reproduce
1. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP
1. Use a browser to navigate to: {{URL}}
1. Forward the following request to the endpoint:
```HTTP Request
{{request}}
```
1. Observe the JavaScript payload being executed
## Proof of Concept (PoC)
Below is a screenshot demonstrating the injected JavaScript executing at the vulnerable endpoint:
{{screenshot}}
Dans la mesure du possible, utilisez la voix passive. Par exemple :
Correct :
Une vulnérabilité d'injection SQL a été découverte dans l'application web.
Incorrect :
J'ai découvert une vulnérabilité d'injection SQL dans l'application web.
Incorrect :
Bugcrowd a découvert une vulnérabilité d'injection SQL dans l'application web.
Incorrect :
Nous avons découvert une injection SQL dans l'application web.
Incorrect :
Tout au long de l'engagement, une injection SQL de sévérité critique a été découverte dans l'application web (<www.example.com>), qui pouvait être utilisée par un attaquant pour exfiltrer des informations personnellement identifiables depuis la base de données backend.
Correct :
Une injection SQL a été découverte sur <www.example.com>, permettant à un attaquant malveillant d'exfiltrer des informations personnellement identifiables.
Incorrect :
Une injection SQL a été découverte sur <www.example.com>, permettant à un attaquant malveillant d'exfiltrer des informations personnellement identifiables, y compris des adresses e-mail, ce qui constituerait une violation du RGPD et représente un risque commercial considérable.
Correct :
Une injection SQL a été découverte sur <www.example.com>, permettant à un attaquant malveillant d'exfiltrer des informations personnellement identifiables. Les données récupérables comprennent des mots de passe, des adresses e-mail et des noms complets. Cela constitue une violation du RGPD et un risque commercial considérable.
Lorsque vous utilisez un acronyme, épelez toujours d'abord la version complète, avec l'acronyme entre parenthèses. Une fois qu'il a été épelé en entier, les utilisations suivantes peuvent se contenter de l'acronyme.
Par exemple :
Le Cross-Site Scripting (XSS) est une attaque côté client qui permet à un attaquant malveillant d'exécuter du JavaScript dans le navigateur d'une victime. Le XSS se produit lorsque l'entrée de l'utilisateur est renvoyée au navigateur sans encodage.
Cross-Site Request Forgery (CSRF) a été découvert sur example.com. Ce CSRF permet de mettre à jour l'adresse de l'utilisateur victime à son insu.
Correct : Bugcrowd Incorrect : BugCrowd, bugcrowd, Bug Crowd, Bug crowd et bug crowd.
Correct : pentest (ou Pentest si la grammaire l'exige) Incorrect : pen test, PenTest, Pen Test
« An » doit être utilisé lorsque le mot suivant commence par un son de consonne. Sinon, « A » doit être utilisé.
Correct :
Incorrect :
Le langage utilisé doit toujours être neutre et impartial.
Exemples :
{{target}} : Nom de la cible dans le périmètre, tel qu'indiqué sur la page du programme (par exemple, *.bugcrowd.com){{application}} : Une application spécifique au sein de la cible (par exemple, Acme Inc. Employee Portal){{type}} : Type de test effectué, indiqué à côté de la cible sur la page du programme (par exemple, test de site web, test d'API, test d'application mobile, test de matériel, etc.){{url}} : Espace réservé pour une URL (par exemple, https://bugcrowd.com/vulnerability-rating-taxonomy){{version}} : Le numéro de version spécifique du logiciel testé (par exemple, 13.3.7){{program}} : Le nom du programme (par exemple, Bugcrowd){{screenshot}} : Preuve photo ou vidéo illustrant l'exécution d'une preuve de concept.{{action}} : L'action qu'un attaquant malveillant pourrait effectuer s'il l'exploite (par exemple, exfiltrer des jetons de session, prendre le contrôle total d'un compte administrateur, déverser des données PII, etc.){{parameter}} : Une variable qui transmet des données du client au serveur et qui peut stocker différents types de données. Le traitement est déterminé par le code côté serveur. (par exemple id=1337){{hardware}} : Un élément matériel spécifique utilisé pour exploiter un actif IoT ou automobile{{software}} : Un logiciel spécifique utilisé pour exploiter un actif (par exemple burp, nessus, nikto, etc.){{payload}} : Une commande ou un payload exécuté sur un actif{{value}} : Une valeur métrique spécifique (secondes, millisecondes, fréquences, etc.)Ce dépôt contient la gem bugcrowd_templates. Cette gem est utilisée pour récupérer les templates pour la description des soumissions et les notes de méthodologie en fonction des sélections VRT. Elle est utilisée et maintenue par Bugcrowd Engineering.
Ajoutez cette ligne au Gemfile de votre application :
gem 'bugcrowd_templates'
Pour faciliter le développement, nous fournissons un utilitaire permettant de lancer un environnement de test (playground) pour jouer avec la gem. Vous pouvez l'invoquer avec :
bin/console
Voici un exemple d'appel à BugcrowdTemplates pour récupérer les templates dans les champs de description des soumissions et de notes de méthodologie.
BugcrowdTemplates.get(
type: 'any_value', # type can be submissions or methodologies
field: 'any_value', # field name of the type
category: 'any_value', # any category name from VRT option
subcategory: 'any_value', # any subcategory name from VRT option
item: 'any_value', # any item name from VRT option
file_name: 'any_value' # file_name can be 'template' or 'guidance'
)
Voici un exemple d'appel à BugcrowdTemplates pour récupérer le template dans le champ de description des soumissions.
BugcrowdTemplates.get(
type: 'submissions',
field: 'description', # field name of the submissions
category: 'server_security_misconfiguration', # category name from VRT option
subcategory: 'clickjacking', # subcategory name from VRT option
item: 'non_sensitive_action', # item name from VRT option
file_name: 'template' # template
)
=> '# Clickjacking on a non-sensitive action\n\n## Overview\n\n' # template fetched from templates path
Exemple de récupération du modèle guidance
BugcrowdTemplates.get(
type: 'submissions',
field: 'description',
category: 'using_components_with_known_vulnerabilities',
subcategory: 'outdated_software_version',
file_name: 'guidance'
)
Voici un exemple d'appel à BugcrowdTemplates pour récupérer les templates dans le champ des notes de méthodologie.
BugcrowdTemplates.get(
type: 'methodology',
field: 'notes', # field name of the methodologies
category: 'website_testing',
file_name: 'information'
)
=> '# Information gathering and Reconnaisance\n\n##' # template fetched from templates path