Logo

Whitepaper de segurança e privacidade (visão geral)Capítulo 11

Capítulo 11: Divulgação de vulnerabilidades e atualizações de segurança

O FileBolt incentiva a divulgação responsável e constrói confiança por meio de mecanismos previsíveis de correção e comunicação. Ao mesmo tempo, os recursos de segurança precisam ser evolutivos: isso inclui as políticas de segurança da Web, os mecanismos de autenticação no servidor e as implementações de criptografia de ponta a ponta e de protocolo (por exemplo, as atualizações de cryptoVersion). Este capítulo descreve os canais públicos de contato, os fluxos de tratamento, os princípios de publicação das correções e de comunicação, e explica as estratégias de evolução versionada e de descontinuação.

11.0 Resumo

  • MUST: Disponibilizar canais públicos para o envio de vulnerabilidades (por exemplo, security.txt e e-mail de suporte).
  • SHOULD: Disponibilizar mecanismos de envio criptografado (por exemplo, chave PGP) para o envio seguro de detalhes.
  • SHOULD: Definir uma cadência clara de resposta e correção (SLA/prazos-alvo) e comunicar pela página de status quando necessário.
  • MUST: Tratar como prioridade máxima as vulnerabilidades que possam afetar os compromissos de conhecimento zero (XSS, injeção na cadeia de suprimentos, vazamento de fragmentos em logs).
  • MUST: Implementar a evolução versionada (cryptoVersion) e definir estratégias de compatibilidade, migração e descontinuação.

11.1 Canais de envio de vulnerabilidades e contato

11.1.1 Pontos de entrada públicos

  • MUST: Informar em /.well-known/security.txt os canais de envio de vulnerabilidades, a validade e os links das políticas.
  • MUST: Disponibilizar um e-mail de contato de segurança acessível (por exemplo, support@filebolt.net ou um endereço dedicado, security@filebolt.net).
  • SHOULD: Incluir instruções breves e diretrizes de envio na página Segurança e privacidade.

11.1.2 Envio criptografado e tratamento de informações sensíveis

  • SHOULD: Disponibilizar uma chave pública PGP (ou equivalente) para que os pesquisadores enviem os detalhes de reprodução com segurança.
  • MUST: Aplicar internamente a visibilidade de privilégio mínimo aos detalhes da vulnerabilidade, divulgando-os apenas às pessoas necessárias para a correção.
  • MUST: Proibir que os pesquisadores incluam nos relatórios texto simples de usuários, CEK, fragmentos de URL ou material derivável de chaves; se algo disso for incluído por engano, a equipe DEVE tratar o caso como um incidente sensível e limitar a disseminação.

11.2 Prazos de resposta e princípios de comunicação

Os prazos dependem do porte da equipe e da complexidade, mas o projeto DEVERIA oferecer uma cadência-alvo previsível e comunicar prontamente quando as metas não forem cumpridas. Metas recomendadas (ajustáveis à realidade e publicadas em /security ou em security.txt):

  • Primeira resposta: por exemplo, confirmar o recebimento e atribuir um ID de acompanhamento em até 48 horas.
  • Avaliação inicial: por exemplo, concluir a classificação de gravidade e a avaliação do escopo do impacto em até 7 dias.
  • Publicação da correção: avança conforme a gravidade; os casos P0/P1 têm prioridade para correção e publicação rápidas.

SHOULD: Manter a comunicação necessária durante o tratamento (por exemplo, reproduzido/não reproduzido, necessidade de mais informações, janela estimada de correção) e evitar divulgar publicamente detalhes exploráveis.

11.3 Processo de divulgação

  1. Recebimento: Registrar as informações do relatório, as etapas de reprodução, o impacto e o contato do pesquisador; atribuir um responsável e o acompanhamento.
  2. Verificação: Reproduzir em ambiente isolado; avaliar o escopo do impacto, a possibilidade de exploração e os componentes afetados (frontend/backend/edge/armazenamento).
  3. Correção: Implementar o patch, adicionar testes e casos de regressão e, se necessário, adicionar regras de proteção (WAF/limitação de taxa/restrição de políticas).
  4. Publicação: Fazer uma publicação canário e monitorar as métricas principais; publicar para todos após confirmar que não há regressão nem novos riscos.
  5. Comunicado: Explicar publicamente o impacto, o conteúdo da correção e as ações exigidas dos usuários (se houver), sem ampliar a superfície de ataque.

Em caso de vulnerabilidades críticas ou de eventos com grande impacto sobre os usuários, SHOULD publicar atualizações do evento ou análises pós-incidente em /status, em linha com o processo de resposta a incidentes do Capítulo 10.

11.4 Vulnerabilidades que afetam os limites de conhecimento zero

O núcleo do compromisso de conhecimento zero é este: o servidor não pode acessar a CEK, e o ambiente de download/descriptografia é isolado ao máximo, sem scripts de terceiros. Por isso, as categorias a seguir DEVEM ser tratadas como prioridade máxima:

  • XSS / injeção: Capacidade de executar scripts arbitrários nas páginas de download/descriptografia, lendo fragmentos ou material de chave na memória.
  • Injeção na cadeia de suprimentos: Envenenamento de dependências, substituição de artefatos de build ou injeção em CDN/edge que levem à adulteração de scripts.
  • Vazamento em logs/monitoramento: Fragmento de URL, CEK, token ou texto simples registrado por acidente e acessível.
  • Política incorreta de carregamento de recursos: Páginas de download/descriptografia que importam scripts de terceiros ou afrouxamento da CSP que amplie a superfície de execução.

O tratamento deve incluir: contenção imediata (retirar do ar o código de risco, endurecer a política, bloquear o vetor), publicação rápida da correção, análise retrospectiva do impacto e uma declaração clara no comunicado sobre “se material de chave ou texto simples pode ter sido exposto”.

11.5 Atualizações de segurança e verificação de regressão

  • MUST: Estabelecer casos de regressão para mudanças relacionadas à segurança (autenticação, controle de acesso, CSP, filtragem de logs, fluxos de criptografia).
  • SHOULD: Executar verificações automatizadas nas páginas críticas (download/descriptografia) para garantir que não haja scripts de terceiros e que as políticas de cabeçalhos correspondam ao esperado.
  • SHOULD: Refazer os testes de itens verificáveis externamente (por exemplo, varreduras de TLS e de cabeçalhos de segurança) após a publicação da correção.
  • SHOULD: Documentar claramente as mudanças de compatibilidade introduzidas pelas correções (por exemplo, links antigos/manifest antigo).

Em linha com o Capítulo 12: as varreduras de terceiros verificam algumas linhas de base da Web, mas não conseguem comprovar diretamente todos os detalhes de implementação do conhecimento zero/E2EE; por isso, a verificação de regressão deve cobrir tanto a implementação do protocolo quanto as linhas de base visíveis.

11.6 Versionamento de protocolo e criptografia (cryptoVersion)

A implementação de criptografia e de protocolo do FileBolt DEVE oferecer suporte a versionamento, para facilitar atualizações de algoritmos, corrigir defeitos de implementação e introduzir isolamento mais forte. Recomenda-se usar campos explícitos (por exemplo, cryptoVersion) vinculados ao manifest/metadados.

  • Versão explícita: Toda transferência/manifest DEVE declarar seu cryptoVersion para determinar algoritmos, parâmetros e regras de codificação.
  • Sem inferência implícita: O cliente DEVE decidir a lógica de análise e descriptografia com base em campos explícitos do manifest, sem adivinhação nem heurísticas de fallback.
  • Falha fechada: DEVE falhar de forma fechada ao encontrar versões desconhecidas ou parâmetros inconsistentes, sem nunca rebaixar para modos inseguros.

11.7 Compatibilidade, migração e descontinuação

11.7.1 Compatibilidade com versões anteriores

  • SHOULD: Oferecer suporte à leitura de versões antigas de transferência durante os períodos de transição, para minimizar o impacto nos links históricos dos usuários.
  • MUST: Declarar publicamente os limites de segurança, as limitações e os planos de descontinuação das versões antigas.

11.7.2 Migração (mantendo o conhecimento zero)

  • SHOULD: Oferecer caminhos de “reenvio/recriptografia” do lado do usuário quando for necessária a migração de uma versão antiga para a nova.
  • MUST: Manter o conhecimento zero durante a migração: a recriptografia ocorre no cliente, e o servidor não pode acessar a CEK nem o texto simples.

11.7.3 Descontinuação e fim de vida (EOL)

  • MUST: Fornecer um cronograma claro de fim de vida para as versões consideradas não mais seguras.
  • SHOULD: Orientar os usuários a reenviar os arquivos, na interface e na documentação, e oferecer janelas de migração suficientes.
  • MUST: Após o fim de vida, os clientes que encontrarem versões descontinuadas devem exibir um aviso claro e não devem tentar a descriptografia.

11.8 IDs de afirmação relacionados (reservado)

Este capítulo trata de “canais de divulgação de vulnerabilidades, fluxos, versionamento e descontinuação”. Os IDs de afirmação correspondentes serão adicionados ao Apêndice: Lista mestre de IDs de afirmação, que é a única fonte autoritativa.