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 :