Testes de segurança realizados internamente #
Estes são testes de primeira parte. São realizados pelo operador e não por um avaliador independente, e não substituem o teste de intrusão externo independente que consta em Trust. São publicados porque o seu conteúdo é útil a quem o analisa, mesmo faltando a independência.
Última atualização: 2026-10-18.
Testes realizados #
| Data | Tipo | Âmbito | Resultado |
|---|---|---|---|
| 2026-05-26 | Avaliação de segurança ao nível do código | Análise estática, auditoria de dependências e revisão manual da autenticação, da autorização e do tratamento de ficheiros | O tratamento de carregamentos foi identificado como a área de maior risco. Constatações registadas no gestor de questões e corrigidas: limite do número de anexos do lado do servidor, autorização dos carregamentos diretos e depuração de parâmetros e endereços IP nos registos |
| 2026-05-26 | Teste externo em produção, não destrutivo | Cabeçalhos de resposta, configuração TLS, páginas públicas e sondagens de metadados contra o servidor de produção | Lacunas na cobertura dos cabeçalhos de resposta e ausência de metadados de contacto de segurança; a dependência de CDN de terceiros para recursos estáticos foi avaliada como risco médio. Corrigido a 2026-05-27: metadados de contacto de segurança publicados e proteção contra a deteção de tipo de conteúdo alargada aos recursos estáticos |
| 2026-06-09 | Revisão da autenticação | Tratamento de cookies, ciclo de vida da sessão, fluxos de ligação mágica e de convite | Duas constatações de gravidade informativa. Corrigidas a 2026-06-14: o cookie de autenticação pendente passou para um armazenamento cifrado, pelo que o endereço deixou de ser legível do lado do cliente; a validade declarada do cookie de sessão corresponde agora ao tempo de inatividade de 14 dias do servidor. Uma constatação de gravidade baixa: os endereços dos canais de denúncia eram derivados de identificadores sequenciais, pelo que era possível enumerar o conjunto das organizações clientes. Corrigida a 2026-08-12: cada canal de denúncia tem um endereço privado aleatório, e a página apresentada para um canal de denúncia inativo deixou de indicar o nome da organização |
| 2026-08-27 | Teste de caixa cinzenta autenticado | Acesso entre organizações, elevação de privilégios, atribuição em massa, acesso a denúncias dentro da mesma organização, confidencialidade dos anexos, isolamento SCIM e confiança nas asserções SAML | Não foram encontrados defeitos de autorização. As fronteiras de organização e de perfil mantiveram-se em todos os casos testados |
| 2026-08-27 | Revisão da exposição em produção | Exposição de rede, robustecimento do servidor, tratamento de cabeçalhos de proxy e gestão de segredos | Os cabeçalhos de reencaminhamento fornecidos pelo cliente eram tratados como fiáveis numa origem diretamente exposta à internet, o que teria permitido contornar os limites de frequência por IP. Corrigido no próprio dia. Foi também removido um cabeçalho que revelava o tempo de servidor por pedido. O cabeçalho ultrapassado Feature-Policy foi substituído por Permissions-Policy a 2026-09-05 |
| 2026-09-08 | Revisão autenticada da entrega de ficheiros e da retenção no navegador | Transferência direta de exportações de dados e gravações de voz, acesso com URL de ficheiros conhecidos entre organizações e após a remoção de um membro, botão Retroceder do navegador após terminar a sessão | Três constatações, cada uma exigindo um utilizador já autorizado que dispusesse de um URL de ficheiro assinado, ou um navegador partilhado. Uma exportação de dados expirada ainda podia ser transferida a partir de um URL conservado, sem nova autenticação. Um gestor podia transferir uma gravação de voz original antes de a respetiva anonimização estar concluída. Depois de uma sessão ser revogada, o botão Retroceder do navegador podia voltar a apresentar uma denúncia a partir da sua cache. Corrigidas a 2026-09-10: a entrega de ficheiros aplica agora as mesmas regras de expiração, reautenticação e processamento que a página que contém a ligação para eles, e as páginas sensíveis e os ficheiros privados deixaram de ser guardados pelo navegador. O acesso entre organizações e o acesso por membros removidos foram recusados em todos os casos testados |
| 2026-09-26 | Revisão ao nível do código da gestão de sessões | Identificação das sessões e o seu comportamento após um restauro da base de dados | As sessões eram identificadas pelo seu identificador na base de dados. Um restauro faz recuar os identificadores, pelo que um novo início de sessão podia receber um identificador ainda detido por um cookie remanescente e retomar a sessão desse utilizador. Corrigido no próprio dia: as sessões são identificadas por um token aleatório, e todas as sessões existentes foram terminadas |
| 2026-09-28 | Revisão dos registos do canal de denúncia | Registos do lado da aplicação escritos enquanto um denunciante utiliza o canal de denúncia | Dois componentes ainda registavam endereços IP dos denunciantes: o registo de pedidos do servidor web e o aviso da proteção contra spam. Em ambos, esse registo foi removido no próprio dia. O registo de pedidos próprio do proxy TLS, que regista o endereço IP de cada pedido, mantém-se inalterado e está descrito em Security#ip-addresses |
| 2026-10-16 | Revisão ao nível do código à luz da investigação atual sobre ataques ao Rails | Processamento de carregamentos, descodificação de imagens, tratamento de mensagens assinadas, registos de pedidos, mensagens em tempo real armazenadas, código de autorização gerado | A remoção de metadados escolhia o método a partir do tipo declarado pelo navegador, pelo que uma fotografia carregada como ficheiro genérico mantinha os metadados de localização e do dispositivo. O descodificador SVG da biblioteca de imagens, bloqueado no arranque, voltava a ser ativado para todo o processo assim que era gerada uma imagem de pré-visualização de ligação. As mensagens assinadas e cifradas ainda aceitavam um formato de serialização que transforma a fuga de um segredo da aplicação em execução de código. Os registos de pedidos guardavam os nomes de ficheiro dos anexos e tokens de transferência de curta duração. As notificações em tempo real, que contêm o ID do caso da denúncia, eram armazenadas sem cifragem durante um dia. O modelo para novas políticas de autorização omitia o filtro por organização; nenhuma política existente foi afetada. Tudo corrigido no próprio dia |
| 2026-10-16 | Verificação forense em produção (CVE-2026-66066) | Inspeção só de leitura de todos os ficheiros armazenados antes da correção, à procura de cabeçalhos de imagem manipulados, imagens cujos píxeis se descodificam como ficheiros do servidor e metadados identificadores residuais | Nenhum indício de exploração nos dados conservados, e nenhuma imagem de denúncia que ainda contenha metadados identificadores. Os ficheiros que poderiam ter sido carregados através do caminho de carregamento direto exposto, aberto de 2026-04-13 a 2026-05-12, foram eliminados pela limpeza diária de ficheiros não associados e já não podem ser examinados |
| 2026-10-17 | Revisão da exposição em produção | Registo de pedidos do proxy inverso, limites de tamanho dos pedidos, análise de vulnerabilidades da imagem de contentor | O proxy inverso regista o caminho de cada pedido, e os caminhos de transferência de anexos incluíam o nome do ficheiro. Corpos de pedido até 1 GB eram colocados em buffer em disco antes de a aplicação os validar. A imagem de contentor era analisada mensalmente quanto a vulnerabilidades do sistema operativo, face a um compromisso de 7 dias para correções críticas. Corrigido no próprio dia: nenhum dos dois passos da transferência de um anexo inclui o nome do ficheiro no seu caminho, os corpos de pedido estão limitados a um valor ligeiramente acima da maior denúncia legítima, e a imagem é analisada semanalmente |
| 2026-10-17 | Testes de mutação das regras de autorização | As políticas de acesso a denúncias, documentos de denúncias e canais de denúncia, com cada regra deliberadamente alterada para confirmar que o conjunto de testes deteta a alteração | Todas as alterações a essas políticas foram detetadas. Não foi encontrado nenhum defeito de autorização |
| 2026-10-18 | Revisão do código antes da avaliação independente | Campos de carregamento e acesso a ficheiros, remoção de metadados, bloqueio até à análise antivírus, funções nos casos, administração da plataforma, registo da autenticação, comunicação de erros, palavras-passe dos denunciantes | Dez constatações. Nove corrigidas no mesmo dia: um campo de carregamento aceitava o identificador de um ficheiro já armazenado, pelo que um utilizador podia anexar um ficheiro que não tinha carregado e depois abri-lo (as ligações para ficheiros passam também a expirar ao fim de uma hora); após a remoção dos metadados de um PDF, o autor original continuava recuperável a partir de uma revisão anterior do ficheiro; a exportação de dados incluía ficheiros que não tinham passado na análise antivírus, e um ficheiro cuja análise nunca foi agendada era disponibilizado sem análise; um Observador atribuído a um caso podia agir sobre ele; o painel de administração da plataforma não exigia um segundo fator; os códigos de início de sessão de utilização única e as asserções SAML chegavam ao serviço de monitorização de erros; os inícios de sessão falhados, as consultas de casos falhadas e os limites de pedidos atingidos não deixavam registo; os denunciantes escolhiam a própria palavra-passe de seis dígitos, pelo que uma escolha comum como 123456 era aceite (as novas denúncias recebem uma palavra-passe de 16 dígitos gerada pelo sistema; as denúncias submetidas antes mantêm a sua, ver Constatações abertas conhecidas). Uma verificação só de leitura da produção não encontrou nenhum PDF de denúncia armazenado nem nenhuma conta de Observador, pelo que nenhum desses dois problemas afetou um caso. A restante consta das constatações abertas conhecidas |
Constatações abertas conhecidas #
| Constatação | Posição |
|---|---|
| Não existe firewall de aplicações web nem CDN à frente da origem aplicacional | Decisão deliberada. O alojamento direto da aplicação e dos ficheiros é feito na UE, enquanto a cadeia de email e telemetria pode envolver tratamento a jusante fora do EEE. A proteção contra DDoS ao nível da rede junto do fornecedor de alojamento, aliada à limitação de frequência na aplicação, é o compromisso atual. |
| As fotografias de perfil do pessoal são armazenadas com os metadados originais do ficheiro | Deliberado. A remoção de metadados protege os denunciantes e as suas provas. Uma fotografia de perfil é escolhida e carregada pela pessoa que nela aparece. |
| As denúncias submetidas antes de 18 de outubro de 2026 mantêm a palavra-passe de 6 dígitos escolhida na submissão, pelo denunciante ou, numa denúncia registada pelo pessoal, pelo gestor do caso | Aceite. Estas palavras-passe continuam a funcionar e não são substituídas. O início de sessão permite 10 tentativas de palavra-passe por ID do caso a cada 10 minutos, a partir de qualquer IP. |
O que isto não comprova #
- O operador escolheu o âmbito, executou os testes e comunicou os resultados. Nada disto foi verificado de forma independente.
- Uma passagem sem constatações é prova sobre os casos testados, não sobre os que não foram testados.
- O controlo A.5.35 da autoavaliação ISO/IEC 27001:2022, a revisão independente da segurança da informação, permanece em aberto por esta razão. É o único controlo do Anexo A dessa página registado como em tratamento, e a mesma limitação mantém o capítulo 9.2 (auditoria interna) como parcial — ver o registo de auditoria interna.
Última atualização: