Regras de Engajamento em Bug Bounty: Escopo, Safe Harbour e Divulgação

#O que é um programa de bug bounty

Um programa de bug bounty é um convite permanente feito por uma organização para que pesquisadores testem os sistemas públicos dela e reportem falhas de segurança, normalmente com recompensa. O convite tem condições. Essas condições, chamadas em geral de política, dizem quais sistemas você pode testar, como pode testá-los, o que não pode tocar, como deve reportar e o que a organização promete em troca.

A política é o regulamento. Muitos problemas começam quando o pesquisador pulou essa leitura ou a tratou como formalidade. Um laboratório ensina a achar uma falha. A política de um programa ensina onde você tem permissão para olhar e quando parar, na borda da autorização. Este artigo trata dessa segunda habilidade.

Você não vai testar nada aqui. Vai ler uma política de exemplo, anotá-la e escrever uma checklist de pré-teste que pode reutilizar em programas reais. Os únicos comandos que você roda mexem em arquivos do seu próprio computador.

#Por que as regras vêm antes do teste

O risco jurídico é a primeira razão que as pessoas costumam dar, e ele é real. Leis de uso indevido de computadores em muitos países são escritas de forma ampla o bastante para que um acesso sem permissão seja enquadrado como crime, mesmo quando a intenção era boa. Nos Estados Unidos, o exemplo mais conhecido é o Computer Fraud and Abuse Act (CFAA). Em maio de 2022, o Departamento de Justiça dos EUA mudou a forma como seus promotores enquadram pesquisas de segurança feitas de boa-fé sob essa lei. A política revisada orienta os promotores a não processar pesquisas feitas exclusivamente para testar, investigar ou corrigir uma falha, que evitem causar dano e cujas informações sejam usadas principalmente para melhorar a segurança. Ela não altera a lei. Não protege pesquisas voltadas à extorsão, É uma política de acusação, não um direito, e não vincula promotores estaduais nem partes privadas que processem. Leia o anúncio do DOJ para ver a redação exata. Não trate isso como permissão para testar o que quiser.

O segundo motivo é prático. Um testador que entra num sistema de pagamentos, no domínio de uma empresa comprada ou na API de um parceiro tocou em algo que o dono nunca ofereceu. Mesmo quando a falha é real, o dono precisa decidir se o relatório é um presente ou um incidente. Ficar dentro do escopo escrito mantém a conversa sobre o bug.

Então a regra é simples: se a política não lista um ativo como escopo, você não está autorizado a testá-lo. Silêncio não é consentimento. A resposta de um atendente de suporte só vale quando a política diz quem pode conceder exceções, e mesmo assim só por escrito.

#Como ler a política de um programa, passo a passo

Percorra a política sempre na mesma ordem. Cada seção abaixo é uma pergunta que você precisa saber responder antes de a primeira requisição sair da sua máquina.

#1. Ativos dentro e fora do escopo

Escopo é a lista de ativos que o dono permite testar. Um ativo pode ser um domínio, uma faixa de IP, um aplicativo móvel, uma API, um produto ou um tipo de conta. Uma boa política nomeia cada ativo com precisão e diz se um curinga como *.example.test cobre todos os subdomínios.

Leia a lista fora do escopo com o mesmo cuidado. Ela costuma citar serviços de terceiros que a empresa não controla, como páginas de pagamento hospedadas, provedores de e-mail e redes de distribuição de conteúdo. A política pode dar permissão para testar os sistemas do dono. Não pode dar permissão para testar os sistemas de um fornecedor, e cada fornecedor tem as próprias condições.

Dois hábitos ajudam. Primeiro, verifique para onde cada nome dentro do escopo aponta. Se ele resolve para um host de plataforma de terceiros, leia as condições dessa plataforma antes de testar. Segundo, anote a data da verificação, porque listas de escopo mudam.

#2. Técnicas permitidas e proibidas

As políticas descrevem técnicas como permitidas, proibidas ou silenciosas. Trate o silêncio como proibição. Itens proibidos comuns são negação de serviço, engenharia social com a equipe, acesso físico e ataques que copiariam ou alterariam dados de outras pessoas. Alguns programas proíbem scanners automatizados. Outros os permitem com limites.

Escreva a lista com suas próprias palavras antes de começar: "Permitido: teste manual da aplicação web com uma conta de teste. Proibido: negação de serviço, phishing com a equipe, scanners." Se você não consegue escrever isso, não está pronto para testar.

#3. Limites de taxa e carga

Limites de taxa protegem os sistemas do dono e os outros usuários. A política pode informar um teto de requisições, um limite de conexões simultâneas ou uma regra como "no máximo um teste por segundo". Se ela não diz nada, mantenha o tráfego baixo e manual. Uma execução automatizada que parece inofensiva do seu lado pode derrubar um serviço pequeno, e a queda passa a ser o seu incidente.

Coloque o número na checklist. Configure sua ferramenta para respeitá-lo e confira a configuração antes de começar.

#4. Contas de teste

Muitos programas pedem que você registre uma conta de teste, às vezes com um padrão específico de e-mail, e que use apenas contas que você criou. Alguns proíbem criar contas para outras pessoas, usar o login de um cliente real ou testar com dados que você não criou. Testes de controle de acesso costumam exigir duas contas, então a política deve dizer quais contas você pode usar e quais dados pode criar nelas.

#5. Tratamento de dados

Esta seção define o que você pode fazer com o que encontrar. As regras típicas dizem que você deve parar ao chegar a dados pessoais, não deve baixar mais do que o necessário para provar o problema, não deve manter cópias e deve apagar o material quando o relatório for fechado. Algumas políticas exigem ocultar dados nas capturas de tela.

A regra de parar diante de dados pessoais pega muita gente. Se uma referência direta insegura a objeto (IDOR) entrega o registro de outra pessoa, a prova adequada costuma ser o identificador e uma descrição curta, não o despejo da tabela. Registre o que você viu e deixe o resto onde está.

#6. Linguagem de safe harbour

Safe harbour é a promessa do dono de não iniciar ação judicial contra pesquisadores que agirem de boa-fé dentro da política. O projeto disclose.io publica textos de safe harbour e ferramentas para organizações que querem escrever os próprios. O site descreve o objetivo como permitir que as pessoas reportem problemas de segurança sem medo de consequências legais, e informa que o material não é aconselhamento jurídico.

Leia o texto de safe harbour com atenção. Uma boa redação nomeia as condições, como seguir a política, reportar com rapidez e não usar o acesso para outra coisa. Ela também se limita aos sistemas do programa. Uma promessa de uma empresa não cobre terceiros nem condutas não relacionadas. Se a política não tem safe harbour nenhum, pese esse fato antes de testar.

#7. Contato e termos de divulgação

A seção de contato diz para onde enviar o relatório e como o dono vai responder. Procure um contato de segurança, uma caixa de entrada da plataforma ou um arquivo security.txt em /.well-known/. Procure um prazo de confirmação e o que acontece com o achado depois da correção.

Os termos de divulgação dizem quando você pode publicar. Algumas políticas permitem a publicação quando a correção é lançada. Outras fixam uma janela contada a partir do primeiro relatório. A página de divulgação coordenada de vulnerabilidades da CISA diz que, quando um fornecedor não responde ou não se compromete com um prazo razoável, a CISA pode divulgar já aos 45 dias após a primeira tentativa de contato com o fornecedor. Essa é a regra da CISA para o papel dela, não um número universal. Os termos do seu programa são os que valem, e você não publica antes de eles permitirem.

#Divulgação coordenada de vulnerabilidades

Divulgação coordenada de vulnerabilidades (CVD, na sigla em inglês) é o processo em que quem encontrou a falha a reporta a quem pode corrigi-la, o fornecedor e as outras partes afetadas preparam a correção e as orientações, e a informação é publicada quando as pessoas que precisam dela podem agir. A CISA diz que o programa dela facilita a disseminação oportuna e sincronizada de informações sobre vulnerabilidades e das mitigações disponíveis.

A ISO/IEC 29147, intitulada "Vulnerability disclosure" dentro da série Information technology, Security techniques, é o padrão internacional para o lado externo desse processo. Ele trata de como um fornecedor recebe relatórios, se comunica com quem reportou, coordena com outros fornecedores e publica avisos. O companheiro dela, a ISO/IEC 30111, trata de como o fornecedor trata a vulnerabilidade internamente. O catálogo da ISO lista o documento como a segunda edição, de 2018. Confira o status atual no iso.org antes de citar.

Para quem pesquisa, o sentido prático é este: um relatório inicia uma conversa dentro de um processo. Você reporta, espera a confirmação, compartilha o que for necessário para reproduzir o problema e respeita o prazo combinado. Esses passos seguem o modelo do padrão, mesmo quando o programa nunca o cita.

#Por que testar fora do escopo é não autorizado

Autorização é uma permissão concedida pelo dono de um sistema, e ela tem limite. Escopo é esse limite por escrito. Tudo o que está fora dele é sistema de outra pessoa para fins do seu teste, e o acesso sem permissão pode configurar acesso não autorizado segundo muitas leis de uso indevido de computadores.

Três coisas dão errado quando alguém testa fora do escopo. Primeiro, a pessoa pode estar errada sobre quem é o dono do ativo, e o teste cai sobre um terceiro inocente. Segundo, o dono pode ter excluído o ativo por um motivo que você não enxerga, como um sistema legado frágil. Terceiro, mesmo quando você está certo, o relatório fica mais difícil de aceitar, porque o dono agora precisa decidir se recompensa um achado que nunca pediu para procurar.

A resposta honesta a uma dúvida de escopo é perguntar ao programa por escrito antes de testar, ou deixar o ativo de fora. Uma pergunta curta custa muito menos do que uma disputa judicial.

#Na prática: anotar uma política de exemplo e escrever uma checklist de pré-teste

Esta seção não precisa de laboratório. O programa de exemplo abaixo é fictício e usa o domínio reservado example.test. Você vai ler, marcar e conferir uma checklist com um pequeno script no seu computador. Nada aqui envia requisição a um host real.

#A política de exemplo

Salve este texto como sample-policy.md em uma pasta vazia.

Example Widget Co. Vulnerability Disclosure Program (fictional)

1. Scope
   In scope: *.example.test and api.example.test.
   Out of scope: payments.example.test (hosted by a payment provider),
   any third-party SaaS host, staging-old.example.test.

2. Techniques
   Allowed: manual testing with a test account you created.
   Allowed: automated scanners at no more than 2 requests per second.
   Forbidden: denial of service, phishing or contacting staff, physical access.

3. Test accounts
   Create accounts with the suffix [email protected].
   Do not use accounts that belong to customers.

4. Data
   If you reach personal data, stop and report the identifier only.
   Delete copies within 30 days of the report being closed.

5. Safe harbour
   We will not pursue legal action against good-faith research that follows
   this policy.

6. Reporting
   Send reports to [email protected]. We acknowledge within 3 business days.
   We ask for 90 days between first report and public disclosure.

#Exercício de anotação

Copie a política para um arquivo de texto e marque cada linha com um dos quatro rótulos: [SCOPE], [RULE], [ASK] ou [GAP]. Use ASK quando precisar esclarecer com o programa antes de testar. Use GAP quando a política silenciar sobre algo de que você precisa.

Depois responda por escrito a estas perguntas. Cite a linha que responde a cada uma e não responda de memória.

1. O api.example.test segue as mesmas regras do site principal, ou precisa de verificação própria?
2. O limite de taxa vale só para scanners, ou também para o tráfego manual?
3. Qual é a situação de payments.example.test, e o que você faria se um teste chegasse a ele por acidente?
4. O safe harbour cobre um achado que expõe dados de clientes?
5. Qual parte dos termos de divulgação é um compromisso do dono, e qual é um pedido a você?

A pergunta 4 não tem resposta no texto. Marque-a como GAP e escreva a pergunta que enviaria ao programa.

#A checklist de pré-teste

Escreva a checklist antes de cada teste. Ela deve caber em uma tela, com uma linha por item, tirada das seções de escopo, técnicas, contas, dados e contato da política. Salve como checklist.md:

# Pre-test checklist

- [ ] written scope:
- [ ] excluded assets:
- [ ] allowed techniques:
- [ ] test account rules:
- [ ] data handling:
- [ ] contact and disclosure terms:

Preencha cada linha com a resposta e, ao lado, uma citação da política. Um item que você não consegue preencher é uma pergunta em aberto, e você não deve testar até fechá-la.

#Confira a checklist com um script

Salve o script abaixo como precheck.py na mesma pasta. Ele lê um arquivo de texto local e não se conecta a nada.

import re, sys

REQUIRED = [
    "written scope",
    "excluded assets",
    "allowed techniques",
    "test account rules",
    "data handling",
    "contact and disclosure terms",
]

def read_fields(path):
    fields = {}
    with open(path, encoding="utf-8") as f:
        for line in f:
            m = re.match(r"^- \[( |x)\] ([^:]+):\s*(.*)$", line.rstrip("\n"))
            if m:
                fields[m.group(2).strip().lower()] = (m.group(1) == "x", m.group(3).strip())
    return fields

fields = read_fields(sys.argv[1])
missing = 0
for name in REQUIRED:
    if name not in fields:
        print(f"MISSING LINE: {name}")
        missing += 1
        continue
    done, value = fields[name]
    if not done or not value or value.upper() in ("TBD", "?"):
        print(f"OPEN: {name}")
        missing += 1
    else:
        print(f"OK: {name}")
print(f"{len(REQUIRED) - missing} of {len(REQUIRED)} items closed")
sys.exit(1 if missing else 0)

Execute no Git Bash, na pasta que tem os dois arquivos:

python precheck.py checklist.md
echo "exit=$?"

O autor executou isso em uma máquina com Windows 11 e Git Bash, usando uma checklist em que a linha de conta de teste ainda dizia TBD. A saída foi:

OK: written scope
OK: excluded assets
OK: allowed techniques
OPEN: test account rules
OK: data handling
OK: contact and disclosure terms
5 of 6 items closed
exit=1

O verificador aponta o item aberto e encerra com status 1, então um script que o chame pode interromper o teste. Ele confere apenas se o formulário está completo. Não consegue dizer se uma entrada corresponde à política, e por isso cada entrada precisa da linha citada ao lado.

#Erros comuns

• Tratar o nome do programa como escopo. Um programa chamado "Example Widget" pode cobrir um produto, várias empresas ou nenhuma das subsidiárias que você imagina. Leia a lista.
• Testar um ativo adivinhado ou herdado. Um subdomínio que você adivinhou, ou um endereço de um registro público antigo, está fora do escopo até a política listá-lo.
• Rodar um scanner em velocidade máxima porque a política não fala de taxas. O silêncio sobre taxas não autoriza ir rápido.
• Manter dados depois do relatório. Cópias deixadas em um notebook continuam sendo dados do dono, e a política pode exigir que sejam apagadas.
• Publicar cedo porque o fornecedor respondeu "corrigido". Leia os termos de divulgação e espere por eles.
• Escrever um relatório que prova mais do que você tinha permissão para coletar. O identificador e um campo ocultado costumam provar o problema tanto quanto um despejo completo.
• Supor que o safe harbour cobre tudo. Ele cobre o que o texto diz, para os sistemas que nomeia.

#Como seguir em frente

Pratique o hábito de leitura em programas públicos que divulgam as próprias regras. Mantenha uma checklist por programa e releia a política no mesmo dia do teste, porque o escopo muda. Leia por completo o material de safe harbour do disclose.io e a página de divulgação coordenada da CISA. Aprenda a diferença entre uma política de divulgação de vulnerabilidades, que pode não oferecer recompensa, e um programa de bug bounty, que paga pelos achados. Depois leia como escrever seu primeiro relatório de segurança para ver como um achado deve ser apresentado quando você já tem permissão e já encontrou algo.

Anote o que testou, quando e de qual conta. Se uma dúvida surgir meses depois, essas anotações são a sua prova.

Desenvolva a parte técnica em um laboratório isolado, não no sistema de outra pessoa. Os passos estão em como criar uma rede Docker isolada para laboratórios. Informação pública também tem limites, tratados em ética e privacidade em OSINT.

#Fontes

• disclose.io, safe harbour e ferramentas de política: https://disclose.io/
• ISO/IEC 29147, Information technology, Security techniques, Vulnerability disclosure: https://www.iso.org/standard/72311.html
• CISA, Coordinated Vulnerability Disclosure Process: https://www.cisa.gov/coordinated-vulnerability-disclosure-process
• Departamento de Justiça dos EUA, New Policy for Charging Cases Under the Computer Fraud and Abuse Act (maio de 2022): https://www.justice.gov/opa/pr/department-justice-announces-new-policy-charging-cases-under-computer-fraud-and-abuse-act