Como reportar uma vulnerabilidade
Como escrever um bug report?
O seu relatório pode ser tão completo quanto você desejar, mas deve conter, no mínimo, as seguintes informações:
Título
O título do seu relatório deve descrever o tipo de bug encontrado, onde foi encontrado e o impacto geral dele. Isso agiliza o processo de triagem e facilita o entendimento do contexto do bug. Por isso, evite títulos muito genéricos que não dão nenhuma pista sobre a vulnerabilidade encontrada.
Por exemplo, títulos genéricos como “o sistema travou” não informam absolutamente nada sobre a vulnerabilidade, nem como ela foi encontrada, onde ou como resolvê-la.
Forneça um título claro e conciso sobre a vulnerabilidade e oque ela afeta.
Um bom título para este mesmo problema poderia ser:
Este será o título do seu relatório. Ele deve fornecer uma breve visão geral do tipo de bug encontrado, onde foi encontrado e o impacto geral. Por exemplo, “A inclusão remota de arquivo no formulário de upload de currículo permite a execução remota de código” é mais descritivo e útil do que “Injeção de RFI encontrada”.
Severidade técnica
Dependendo da severidade técnica do bug, diferentes prioridades são definidas para ele. Um bug pode ter as seguintes severidades: Informativa, Baixa, Média, Alta, Crítica. A partir destas criticidades, as empresas saberão quais os bugs mais severos que elas devem resolver primeiro.
Que impacto de segurança um invasor pode atingir? Danos financeiros? Vazamento de dados?
Qual a probabilidade? É necessário um conhecimento muito técnico?
Passos para reproduzir
Todo bug report precisa ter um passo a passo para reprodução do bug. Neste passo é fundamental que você mesmo consiga reproduzir a vulnerabilidade seguindo os passos, então garanta que eles sejam específicos e fáceis de seguir.
Afinal, um bug que não pode ser reproduzido é um bug que não pode ser corrigido.
Prova de conceito (PoC)
A Prova de Conceito ou Proof of Concept (PoC) em inglês, é um modelo prático que tenta provar um conceito teórico através de uma pesquisa, artigo ou implementação. No caso do Bug Bounty, a PoC se refere ao desenvolvimento de uma ferramenta prática para provar a vulnerabilidade de um sistema.
Você pode fazer isso de diversas formas, seja anexando scripts, capturas de tela, gravações de tela ou outras provas que você tenha da vulnerabilidade encontrada. Isso torna o seu bug report ainda mais assertivo!
Dê um contexto
Não se esqueça de dar um contexto sobre o bug. Quanto mais informação seu relatório tiver, melhor para o time de desenvolvedores, para a empresa e para você.
Um bom contexto pode conter:
Como a vulnerabilidade pode impactar;
Se a vulnerabilidade pode ser porta de entrada para mais vertentes de ataques;
Se existe a possibilidade de combinar a vulnerabilidade encontrada com outra, e isso pode tornar o bug muito mais crítico;
Riscos de não tratar a falha;
Se foi possível ter acesso a algum dado sensível.
Bons reports valorizam suas habilidades de hacking
Quando você domina a habilidade de comunicar suas descobertas de bugs de forma clara e estruturada, você agrega valor aos seus relatórios.
Isso é especialmente útil quando você quer mostrar as suas habilidades, podendo inclusive adicionar um link para seus relatórios divulgados no seu currículo. Esta é uma excelente forma de mostrar às pessoas que você não apenas encontra bugs, mas também sabe comunicá-los aos desenvolvedores de forma que os ajude a corrigir as vulnerabilidades rapidamente.
Last updated