bugcrowd/templatesRepository zur Aufbewahrung von Markdown-Vorlagen für Forscher
Hinweise zur Verzeichnisstruktur:
Das Skript generate-directories.py holt die aktuelle neueste Version der VRT-Struktur von GitHub und erstellt alle fehlenden Verzeichnisse. Es entfernt oder benennt keine Verzeichnisse basierend auf Einträgen, die aus der VRT entfernt wurden.
Das Skript folgt den Standardeintragsnamen und behält Unterstriche / Groß- und Kleinschreibung gemäß dem VRT-Feld id bei.
In diesem Repository ist 'Protected Master' aktiviert; das bedeutet, dass nur Projektadministratoren über Pull Requests in den Master-Branch committen können. Alle Updates müssen über Pull Requests erfolgen, um die Integrität zu gewährleisten.
Das Folgende setzt voraus, dass der SSH-Zugriff korrekt konfiguriert ist.
Zuerst den Master-Branch auschecken:
git clone [email protected]:bugcrowd/templates.git ## n.b. using SSH aliases can make this much simpler
Sobald Sie den Master auf Ihrem System haben, müssen Sie einen Branch für die Arbeit erstellen, die Sie ausführen möchten:
git checkout -b <branch-name>
Beispielhafte Branchnamen könnten XXE-templates XSS-templates sein, etwas, das kennzeichnet, worum es bei dem Arbeitspaket geht. Diese sollten klein gehalten werden, vorzugsweise eine Gruppe von Vorlagen und nicht viel mehr. Committen und pushen Sie oft!
git commit -am "Comments about what you changed go here" speichert Ihre Änderungen im lokalen Git-Repository. Hinterlassen Sie immer eine beschreibende Commit-Nachricht.
Wenn Sie Ihre Vorlagen abgeschlossen haben, können Sie sie in das Repository pushen. Diese bleiben weiterhin in ihrem eigenen Branch, aber beim Pushen wird der Linter ausgeführt und validiert das Markdown anhand einer Reihe von Regeln. Wenn Sie der Beispielvorlage gefolgt sind und nicht viel abgewichen sind, sollten die Vorlagen den Test bestehen.
git push --set-upstream origin <branch-name> erstellt den Branch auf dem Origin-Server (GitHub) und pusht Ihre Änderungen. Dies muss nur einmal für den Branch durchgeführt werden; spätere Pushes für den Branch können mit git push ausgeführt werden.
Sobald der Linter erfolgreich ausgeführt wurde, können Sie einen Pull Request (PR) erstellen.
Wählen Sie den Branch in der GitHub-Oberfläche. Sie sollten über dem Code einen Button 'Pull request' sehen.
Klicken Sie auf diesen Button, füllen Sie dann einige Details darüber aus, was sich geändert hat, damit die Projektadministratoren es überprüfen können, und klicken Sie anschließend auf 'Create pull request'.
An diesem Punkt sind Sie fertig! Wir überprüfen den PR und mergen oder lehnen ihn entsprechend ab.
Sobald der PR akzeptiert wurde, können Sie den Branch löschen.
git branch -d <branch-name>
Unten finden Sie eine Beispielvorlage. Alle Abschnitte sollten aktualisiert werden, um korrekte Informationen zu enthalten.
## 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).
Dies ist eine Beispielvorlage:
# 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}}
Verwenden Sie wo möglich das Passiv. Zum Beispiel:
Richtig:
Im Webanwendung wurde eine SQL-Injection-Schwachstelle entdeckt.
Falsch:
Ich habe eine SQL-Injection-Schwachstelle in der Webanwendung entdeckt.
Falsch:
Bugcrowd hat eine SQL-Injection-Schwachstelle in der Webanwendung entdeckt.
Falsch:
Wir haben eine SQL-Injection in der Webanwendung entdeckt.
Falsch:
Im Verlauf des Engagements wurde eine SQL-Injection mit kritischem Schweregrad in der Webanwendung (<www.example.com>) entdeckt, die von einem Angreifer genutzt werden könnte, um personenbezogene Daten aus der Backend-Datenbank zu exfiltrieren.
Richtig:
In <www.example.com> wurde eine SQL-Injection entdeckt, die einem böswilligen Angreifer erlaubt, personenbezogene Daten zu exfiltrieren.
Falsch:
In <www.example.com> wurde eine SQL-Injection entdeckt, die einem böswilligen Angreifer erlaubt, personenbezogene Daten einschließlich E-Mail-Adressen zu exfiltrieren, was als DSGVO-Verstoß gelten würde und ein erhebliches Geschäftsrisiko darstellt.
Richtig:
In <www.example.com> wurde eine SQL-Injection entdeckt, die einem böswilligen Angreifer erlaubt, personenbezogene Daten zu exfiltrieren. Die abrufbaren Daten umfassen Passwörter, E-Mail-Adressen und vollständige Namen. Dies stellt einen DSGVO-Verstoß und ein erhebliches Geschäftsrisiko dar.
Wenn Sie ein Akronym verwenden, schreiben Sie zuerst immer die vollständige Version aus und setzen das Akronym in Klammern. Nachdem es vollständig ausgeschrieben wurde, können spätere Verwendungen nur das Akronym verwenden.
Zum Beispiel: