hakluke/bug-bounty-standardsUma lista de casos extremos que ocorrem em programas de bug bounty, conversas sobre como eles devem ser tratados. O objetivo é padronizar a forma como situações específicas são tratadas em bug bounties.
Este repositório é uma lista de situações que ocorrem em programas de bug bounty e de como elas devem ser tratadas. Muitas delas são atualmente tratadas caso a caso, o que gera muita incerteza e frustração para hackers, donos de programas e plataformas. O objetivo deste repositório é padronizar a forma como esses casos extremos são tratados em todas as plataformas e programas de bounty. Espera-se que a padronização permita que as expectativas sejam atendidas com mais frequência por todas as partes.
Este documento é um rascunho e ainda não foi implementado por nenhuma plataforma de bug bounty. Nesta etapa, estou solicitando comentários de todas as partes interessadas.
Por favor, contribua abrindo issues no GitHub. Todas as issues razoáveis submetidas permanecerão abertas por um mínimo de 30 dias para comentários.
Sua issue deve expressar uma opinião, por exemplo:
Comentários sobre a issue são bem-vindos de qualquer pessoa, mas devem ser construtivos e sem emoção. Comportamento abusivo não será tolerado.
| ID | Situação | Resolução |
|---|
| 1 | Hacker submete uma vulnerabilidade com prova de exploração. A vulnerabilidade é corrigida antes de a submissão ser triada. | A plataforma deve fornecer prova de que a submissão não foi acessada pelo programa antes da correção. Se a submissão foi acessada pelo programa, o programa deve pagar o bounty correspondente; caso contrário, a submissão é marcada como duplicada. |
| 2 | Hacker submete uma vulnerabilidade e o programa responde dizendo que já sabia dela internamente. | O programa deve fornecer prova de que este era um problema já conhecido, por exemplo, uma captura de tela de um ticket no Jira incluindo a data de criação. Se o programa não conseguir fornecer prova, deve pagar o bounty; caso contrário, a submissão deve ser marcada como duplicada. |
| 3 | Hacker submete uma vulnerabilidade que é marcada como duplicata de outra submissão que não explorou totalmente o impacto do bug. Por exemplo, um hacker submete um XSS completo que permite a tomada de conta (account takeover), e a submissão é duplicada em relação a outra que apenas reportou injeção de HTML. | O primeiro reporter recebe um bounty com base no impacto de sua submissão; o segundo reporter recebe um bounty com base no impacto de sua submissão menos o bounty recebido pelo primeiro reporter. |
| 4 | Hacker submete uma vulnerabilidade e o programa nunca responde. | A plataforma paga o bounty. |
| 5 | Hacker submete uma vulnerabilidade e é incorretamente duplicado em relação a um relatório mais recente. | A plataforma altera o status de ambos os relatórios para que fiquem precisos. Se o pagamento já foi feito incorretamente, a organização que fez a triagem incorretamente paga o bounty. Para programas de bounty gerenciados, isso geralmente seria a plataforma, mas para programas não gerenciados, seria o programa. |
| 6 | Hacker discorda da classificação de severidade atribuída. | O hacker envia sua justificativa no ticket. Se não houver resposta em 14 dias, o hacker envia a justificativa para o canal de suporte da plataforma. Atualizações de severidade são decididas caso a caso, por submissão. |
| 7 | Hacker divulga publicamente um bug que foi previamente submetido à plataforma, sem permissão explícita do dono do programa. | Um pesquisador deve poder divulgar publicamente a vulnerabilidade nas seguintes circunstâncias: a) O bug não foi aceito como válido, ou seja, foi marcado como N/A ou Informativo. b) O bug está em estado resolvido há 30+ dias. c) O pesquisador tem permissão explícita do programa para divulgação pública. Em outros casos, o hacker recebe um banimento de 30 dias da plataforma e recebe um e-mail com toda a justificativa por trás do banimento. Reincidência resulta em banimento permanente. |
| 8 | Hacker submete um bug que está dentro do escopo do programa, mas que na verdade é um bug em um serviço de terceiros. | Todo programa deve especificar se aceita bugs em sistemas de terceiros dentro do seu briefing. Se não houver especificação, presume-se que TODOS os sistemas listados no escopo serão válidos para pagamento, incluindo sistemas de terceiros. |
| 9 | Hacker submete uma vulnerabilidade zero-day sem exploits ou divulgação pública existentes, afetando sistemas dentro do escopo. | Se quaisquer alterações foram feitas como resultado do relatório, ou seja, mudanças de configuração, colocação de sistemas offline ou aplicação de regras de WAF, o relatório deve ser aceito e recompensado. É preciso fazer uma distinção entre exploits zero-day que são públicos e exploits zero-day que sua equipe não teria conhecido se não fosse pelo relatório de bug bounty. |
| 10 | Hacker submete um bug a um programa que tem um briefing de escopo aberto. O bug está em uma aquisição. O dono do programa não controla a infraestrutura de TI nem a equipe da aquisição. | O dono do programa deve fazer um esforço de boa-fé, verificado pela plataforma, para informar a aquisição. Caso a aquisição se beneficie da submissão, o dono do programa deve pagar o bounty. O briefing deve ser atualizado para refletir se a(s) aquisição(ões) está(ão) no escopo. |
