bugcrowd/templatesRepository to house markdown templates for researchers
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.
Cross-Site Request Forgery (CSRF) è stata scoperta in example.com. Questa CSRF consente di aggiornare l'indirizzo dell'utente vittima senza che questi ne sia a conoscenza.
Corretto: Bugcrowd Errato: BugCrowd, bugcrowd, Bug Crowd, Bug crowd e bug crowd.
Corretto: pentest (o Pentest se grammaticalmente richiesto) Errato: pen test, PenTest, Pen Test
Si dovrebbe usare "An" quando la parola successiva inizia con un suono consonantico. In caso contrario, si dovrebbe usare "A".
Corretto:
Errato:
Il linguaggio utilizzato dovrebbe essere sempre privo di emotività e imparziale.
Esempi:
{{target}}: Nome del target in scope elencato nella pagina del programma (ad esempio, *.bugcrowd.com){{application}}: Un'applicazione specifica all'interno del target (ad esempio, Portale Dipendenti di Acme Inc.){{type}}: Tipo di test eseguito elencato accanto al target nella pagina del programma (ad esempio test del sito web, test API, test di applicazioni mobili, test hardware, ecc.){{url}}: Segnaposto per un URL (ad esempio, https://bugcrowd.com/vulnerability-rating-taxonomy){{version}}: Il numero di versione specifico del software testato (ad esempio, 13.3.7){{program}}: Il nome del programma (ad esempio, Bugcrowd){{screenshot}}: Prova fotografica o video che mostra una proof of concept eseguita.{{action}}: L'azione che un attaccante malintenzionato potrebbe compiere se la sfrutta (ad esempio, esfiltrare token di sessione, assumere il pieno controllo dell'account amministratore, scaricare PII, ecc.){{parameter}}: Una variabile che trasmette dati dal client al server e che può contenere diversi tipi di dati al suo interno. La gestione è determinata dal codice lato server. (ad esempio )Questo repository contiene la gemma bugcrowd_templates. Questa gemma viene utilizzata per recuperare i templates per la descrizione della segnalazione e le note delle metodologie in base alle selezioni VRT. È utilizzata e mantenuta da Bugcrowd Engineering.
Aggiungi questa riga al Gemfile della tua applicazione:
gem 'bugcrowd_templates'
Per comodità durante lo sviluppo, forniamo un'utilità per avviare un playground per giocare con la gemma. Puoi invocarla con:
bin/console
Di seguito è riportato un esempio per chiamare BugcrowdTemplates per recuperare i templates nei campi descrizione della segnalazione e note delle metodologie.
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'
)
Di seguito è riportato un esempio per chiamare BugcrowdTemplates per recuperare il template nel campo descrizione della segnalazione.
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
Esempio per il recupero del template guidance
BugcrowdTemplates.get(
type: 'submissions',
field: 'description',
category: 'using_components_with_known_vulnerabilities',
subcategory: 'outdated_software_version',
file_name: 'guidance'
)
Di seguito è riportato un esempio per chiamare BugcrowdTemplates per recuperare i templates nel campo note delle metodologie.
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
id=1337{{hardware}}: Un componente hardware specifico utilizzato per sfruttare un asset IoT o Automotive{{software}}: Un software specifico utilizzato per sfruttare un asset (ad esempio burp, nessus, nikto, ecc.){{payload}}: Un comando o payload che viene eseguito su un asset{{value}}: Un valore metrico specifico (secondi, millisecondi, frequenze, ecc.)