bugcrowd/templatesRepositório para armazenar modelos markdown para pesquisadores
Notas sobre a estrutura de diretórios:
O script generate-directories.py obtém a versão mais recente da estrutura VRT do GitHub e cria quaisquer diretórios ausentes. Ele não remove nem renomeia diretórios com base em itens removidos do VRT.
O script segue os nomes de entrada padrão e mantém sublinhados / caixa conforme fornecido pelo campo id do VRT.
Este repositório tem o 'Protected Master' habilitado; o que significa que apenas administradores do projeto podem fazer commit no branch master, via Pull Requests. Todas as atualizações precisam vir via pull request para garantir a integridade.
O texto a seguir é escrito assumindo que o acesso SSH está configurado corretamente.
Primeiro, faça checkout do branch master:
git clone [email protected]:bugcrowd/templates.git ## n.b. using SSH aliases can make this much simpler
Depois de ter o master no seu sistema, você precisará criar um branch para o trabalho que está prestes a realizar:
git checkout -b <branch-name>
Nomes de branch de exemplo poderiam ser XXE-templates, , algo que indique o que é o conjunto de trabalho. Eles devem ser mantidos pequenos, preferencialmente um grupo de templates e nada muito além disso. Faça commit e push com frequência!
XSS-templatesgit commit -am "Comments about what you changed go here" salva suas alterações no repositório git local. Sempre deixe uma mensagem de commit descritiva.
Quando você tiver concluído seus templates, pode enviá-los (push) para o repositório. Eles continuarão em seu próprio branch, mas quando você fizer o push, o linter será executado e validará o markdown contra um conjunto de regras. Se você seguiu o template de exemplo e não se desviou muito, os templates devem passar.
git push --set-upstream origin <branch-name> Isso criará o branch no servidor origin (github) e enviará suas alterações. Isso só precisa ser feito uma vez para o branch, e os pushes subsequentes para o branch podem ser feitos com git push.
Depois que o linter for executado com sucesso, você poderá criar um Pull Request (PR).
Selecione o branch na interface do GitHub. Você deve ver um botão 'Pull request' acima do código.
Selecione esse botão, preencha alguns detalhes sobre o que mudou para que os administradores do projeto revisem e clique em 'Create pull request'.
Nesse ponto, você terminou! Revisaremos o PR e faremos merge ou rejeitaremos conforme for apropriado.
Assim que o PR for aceito, você pode excluir o branch.
git branch -d <branch-name>
Abaixo está um exemplo de template. Todas as seções devem ser atualizadas para incluir informações corretas.
## 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).
Este é um template de exemplo:
# 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}}
Sempre que possível, use a voz passiva. Por exemplo:
Correto:
Uma vulnerabilidade de injeção de SQL foi descoberta na aplicação web.
Incorreto:
Eu descobri uma vulnerabilidade de injeção de SQL na aplicação web.
Incorreto:
A Bugcrowd descobriu uma vulnerabilidade de injeção de SQL na aplicação web.
Incorreto:
Nós descobrimos uma injeção de SQL na aplicação web.
Incorreto:
Durante o decorrer do engajamento, uma injeção de SQL de severidade crítica foi descoberta na aplicação web (<www.example.com>), que poderia ser usada por um atacante para exfiltrar informações pessoalmente identificáveis do banco de dados backend.
Correto:
Uma injeção de SQL foi descoberta em <www.example.com>, permitindo que um atacante malicioso exfiltre informações pessoalmente identificáveis.
Incorreto:
Uma injeção de SQL foi descoberta em <www.example.com>, permitindo que um atacante malicioso exfiltre informações pessoalmente identificáveis, incluindo endereços de e-mail, o que seria considerado uma violação da GDPR e representa um risco comercial considerável.
Correto:
Uma injeção de SQL foi descoberta em <www.example.com>, permitindo que um atacante malicioso exfiltre informações pessoalmente identificáveis. Os dados recuperáveis incluem senhas, endereços de e-mail e nomes completos. Isso representa uma violação da GDPR e um risco comercial considerável.
Ao usar uma sigla, sempre escreva a versão completa primeiro com a sigla entre parênteses. Depois de escrita por extenso, os usos subsequentes podem usar apenas a sigla.
Por exemplo:
Cross-Site Scripting (XSS) é um ataque do lado do cliente que permite que um atacante malicioso execute JavaScript no navegador da vítima. O XSS ocorre quando a entrada do usuário é refletida de volta ao navegador sem codificação.
Cross-Site Request Forgery (CSRF) foi descoberto em example.com. Esse CSRF permite que você atualize o endereço do usuário vítima sem que ele saiba.
Correto: Bugcrowd Incorreto: BugCrowd, bugcrowd, Bug Crowd, Bug crowd e bug crowd.
Correto: pentest (ou Pentest se gramaticalmente necessário) Incorreto: pen test, PenTest, Pen Test
"An" deve ser usado quando a próxima palavra começa com um som de consoante. Caso contrário, "A" deve ser usado.
Correto:
Incorreto:
A linguagem usada deve ser sempre sem emotividade e imparcial.
Exemplos:
{{target}}: Nome do alvo em escopo listado na página do programa (por exemplo, *.bugcrowd.com){{application}}: Uma aplicação específica dentro do alvo (por exemplo, Acme Inc. Employee Portal){{type}}: Tipo de teste realizado listado ao lado do alvo na página do programa (por exemplo, teste de website, teste de API, teste de aplicação móvel, teste de hardware, etc.){{url}}: Placeholder para uma URL (por exemplo, https://bugcrowd.com/vulnerability-rating-taxonomy){{version}}: O número de versão específico do software testado (por exemplo, 13.3.7){{program}}: O nome do programa (por exemplo, Bugcrowd){{screenshot}}: Evidência em foto ou vídeo exibindo uma prova de conceito executada.{{action}}: A ação que um atacante malicioso poderia executar se a explorar (por exemplo, exfiltrar tokens de sessão, assumir controle total da conta administrativa, despejar PII, etc.){{parameter}}: Uma variável que transmite dados do cliente para o servidor e que pode conter diferentes tipos de dados. O tratamento é determinado pelo código do lado do servidor. (por exemplo, id=1337){{hardware}}: Um hardware específico usado para explorar um ativo de IoT ou automotivo{{software}}: Um software específico usado para explorar um ativo (por exemplo, burp, nessus, nikto, etc.){{payload}}: Um comando ou payload que é executado em um ativo{{value}}: Um valor métrico específico (segundos, milissegundos, frequências, etc.)Este repositório contém a gem bugcrowd_templates. Esta gem é usada para buscar os templates para a descrição de submissões e notas de metodologias com base nas seleções do VRT. Ela é usada e mantida pela Bugcrowd Engineering.
Adicione esta linha ao Gemfile da sua aplicação:
gem 'bugcrowd_templates'
Para conveniência no desenvolvimento, fornecemos um utilitário para criar um playground para brincar com a gem. Você pode invocá-lo com:
bin/console
Abaixo está um exemplo de chamada do BugcrowdTemplates para buscar templates nos campos de descrição de submissão e notas de metodologias.
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'
)
Abaixo está um exemplo de chamada do BugcrowdTemplates para buscar template no campo de descrição de submissão.
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
Exemplo para buscar o template guidance:
BugcrowdTemplates.get(
type: 'submissions',
field: 'description',
category: 'using_components_with_known_vulnerabilities',
subcategory: 'outdated_software_version',
file_name: 'guidance'
)
Abaixo está um exemplo de chamada do BugcrowdTemplates para buscar templates no campo de notas de metodologias.
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