bugcrowd/templatesRepository per ospitare modelli markdown per ricercatori
Note sulla struttura delle directory:
Lo script generate-directories.py recupera l'ultima versione corrente della struttura VRT da GitHub e crea eventuali directory mancanti. Non rimuove né rinomina directory in base agli elementi rimossi dalla VRT.
Lo script segue i nomi standard delle voci e mantiene underscore / maiuscole e minuscole come fornite dal campo id della VRT.
Questo repository ha 'Protected Master' abilitato; ciò significa che solo gli amministratori del progetto possono effettuare commit sul branch master, tramite Pull Request. Tutti gli aggiornamenti devono passare da pull request per garantire l'integrità.
Quanto segue è scritto supponendo che l'accesso SSH sia configurato correttamente.
Per prima cosa, esegui il checkout del branch master:
git clone [email protected]:bugcrowd/templates.git ## n.b. using SSH aliases can make this much simpler
Una volta che hai master sul tuo sistema, dovrai creare un branch per il lavoro che stai per svolgere:
git checkout -b <branch-name>
Esempi di nomi di branch potrebbero essere XXE-templates XSS-templates, qualcosa che indichi quale pacchetto di lavoro è. Dovrebbero essere mantenuti piccoli, preferibilmente un gruppo di template e non molto di più. Fai commit e push spesso!
git commit -am "Comments about what you changed go here" salva le modifiche nel repository git locale. Lascia sempre un messaggio di commit descrittivo.
Quando hai completato i tuoi template, puoi eseguirne il push nel repository. Questi saranno ancora nel loro branch, ma quando fai push, il linter verrà eseguito e validerà il markdown rispetto a un insieme di regole. Se hai seguito il template di esempio e non ti sei discostato molto, i template dovrebbero superare la validazione.
git push --set-upstream origin <branch-name> Questo creerà il branch sul server origin (github) e pubblicherà le tue modifiche. Questa operazione deve essere eseguita solo una volta per il branch; i push successivi per il branch possono essere effettuati con git push.
Una volta che il linter è stato eseguito correttamente, puoi creare una Pull Request (PR)
Seleziona il branch nell'interfaccia di GitHub. Dovresti vedere un pulsante 'Pull request' sopra il codice.
Seleziona quel pulsante, poi compila alcuni dettagli su cosa è cambiato per la revisione degli amministratori del progetto, quindi fai clic su 'Create pull request'.
A quel punto, hai finito! Esamineremo la PR e la uniremo o la rifiuteremo come appropriato.
Una volta accettata la PR, sei libero di eliminare il branch
git branch -d <branch-name>
Di seguito è riportato un esempio di template. Tutte le sezioni dovrebbero essere aggiornate per includere informazioni corrette.
## 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).
Questo è un esempio di template:
# 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}}
Dove possibile, usa la voce passiva. Per esempio:
Corretto:
È stata scoperta una vulnerabilità di SQL injection nell'applicazione web.
Errato:
Ho scoperto una vulnerabilità di SQL injection nell'applicazione web.
Errato:
Bugcrowd ha scoperto una vulnerabilità di SQL injection nell'applicazione web.
Errato:
Abbiamo scoperto una SQL injection nell'applicazione web.
Errato:
Nel corso dell'engagement, è stata scoperta una SQL injection di gravità critica nell'applicazione web (<www.example.com>) che potrebbe essere utilizzata da un attaccante per esfiltrare informazioni personali identificabili dal database backend.
Corretto:
È stata scoperta una SQL injection in <www.example.com> che consente a un attaccante malintenzionato di esfiltrare informazioni personali identificabili.
Errato:
È stata scoperta una SQL injection in <www.example.com> che consente a un attaccante malintenzionato di esfiltrare informazioni personali identificabili, inclusi indirizzi email, il che sarebbe considerato una violazione del GDPR e comporta un notevole rischio per l'azienda.
Corretto:
È stata scoperta una SQL injection in <www.example.com> che consente a un attaccante malintenzionato di esfiltrare informazioni personali identificabili. I dati recuperabili includono password, indirizzi email e nomi completi. Questo costituisce una violazione del GDPR e un notevole rischio per l'azienda.
Quando usi un acronimo, scrivi sempre per esteso la versione completa prima, con l'acronimo tra parentesi. Una volta scritto per esteso, gli usi successivi possono utilizzare solo l'acronimo.
Per esempio:
Cross-Site Scripting (XSS) è un attacco lato client che consente a un attaccante malintenzionato di eseguire JavaScript nel browser di una vittima. L'XSS si verifica quando l'input dell'utente viene riflesso nel browser senza codifica.