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 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!
XSS-templatesgit 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:
Cross-Site Scripting (XSS) ist ein clientseitiger Angriff, der einem böswilligen Angreifer ermöglicht, JavaScript im Browser eines Opfers auszuführen. XSS tritt auf, wenn Benutzereingaben ohne Kodierung an den Browser zurückgegeben werden.
Cross-Site Request Forgery (CSRF) wurde in example.com entdeckt. Dieses CSRF ermöglicht es Ihnen, die Adresse des betroffenen Benutzers ohne dessen Wissen zu aktualisieren.
Richtig: Bugcrowd Falsch: BugCrowd, bugcrowd, Bug Crowd, Bug crowd und bug crowd.
Richtig: pentest (oder Pentest, wenn es grammatikalisch erforderlich ist) Falsch: pen test, PenTest, Pen Test
„An" sollte verwendet werden, wenn das nächste Wort mit einem Konsonanten laut beginnt. Andernfalls sollte „A" verwendet werden.
Richtig:
Falsch:
Die verwendete Sprache sollte immer emotionslos und unparteiisch sein.
Beispiele:
{{target}}: Name des im Rahmen (Scope) befindlichen Ziels, das auf der Programmseite aufgeführt ist (zum Beispiel *.bugcrowd.com){{application}}: Eine bestimmte Anwendung innerhalb des Ziels (zum Beispiel Acme Inc. Employee Portal){{type}}: Art der durchgeführten Tests, die neben dem Ziel auf der Programmseite aufgeführt ist (zum Beispiel Websitetests, API-Tests, Mobile-Application-Tests, Hardwaretests usw.){{url}}: Platzhalter für eine URL (zum Beispiel https://bugcrowd.com/vulnerability-rating-taxonomy){{version}}: Die spezifische Versionsnummer der getesteten Software (zum Beispiel 13.3.7){{program}}: Der Programmname (zum Beispiel Bugcrowd){{screenshot}}: Foto- oder Video-Nachweis, der einen ausgeführten Proof of Concept zeigt.{{action}}: Die Aktion, die ein böswilliger Angreifer ausführen könnte, wenn er sie ausnutzt (zum Beispiel Sitzungstoken exfiltrieren, die vollständige Kontrolle über ein Administratorkonto übernehmen, personenbezogene Daten (PII) auslesen usw.){{parameter}}: Eine Variable, die Daten vom Client an den Server überträgt und in der verschiedene Datentypen gespeichert werden können. Die Verarbeitung wird durch den serverseitigen Code bestimmt. (zum Beispiel id=1337){{hardware}}: Ein spezifisches Hardware-Gerät, das verwendet wird, um ein IoT- oder Automotive-Asset auszunutzen{{software}}: Eine spezifische Software, die verwendet wird, um ein Asset auszunutzen (zum Beispiel burp, nessus, nikto usw.){{payload}}: Ein Befehl oder Payload, der auf einem Asset ausgeführt wird{{value}}: Ein spezifischer metrischer Wert (Sekunden, Millisekunden, Frequenzen usw.)Dieses Repository enthält die Gem bugcrowd_templates. Diese Gem wird verwendet, um die templates für Einreichungsbeschreibungen und Methodiknotizen basierend auf VRT-Auswahlen abzurufen. Sie wird von Bugcrowd Engineering verwendet und gewartet.
Fügen Sie diese Zeile zur Gemfile Ihrer Anwendung hinzu:
gem 'bugcrowd_templates'
Für die Entwicklung bieten wir ein Dienstprogramm zum Starten einer Spielwiese (Playground) zum Experimentieren mit der Gem an. Sie können es aufrufen mit:
bin/console
Unten finden Sie ein Beispiel, um BugcrowdTemplates aufzurufen und templates in den Feldern für Einreichungsbeschreibung und Methodiknotizen abzurufen.
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'
)
Unten finden Sie ein Beispiel, um BugcrowdTemplates aufzurufen und template im Feld für Einreichungsbeschreibung abzurufen.
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
Beispiel für das Abrufen der guidance-Vorlage:
BugcrowdTemplates.get(
type: 'submissions',
field: 'description',
category: 'using_components_with_known_vulnerabilities',
subcategory: 'outdated_software_version',
file_name: 'guidance'
)
Unten finden Sie ein Beispiel, um BugcrowdTemplates aufzurufen und templates im Feld für Methodiknotizen abzurufen.
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