Superfície pequena, revisão publicada
O Missivus guarda uma credencial capaz de enviar e-mail em nome da sua empresa. É exatamente o tipo de código que deve ser revisto linha a linha e documentado em público — e por isso foi.
O modelo de segurança num parágrafo
A política de acesso de aplicação do Exchange é o que delimita o raio de impacto. Todas as conclusões abaixo estão contidas por ela — mesmo uma credencial totalmente comprometida só pode enviar como uma caixa de correio partilhada e nada mais. É por isso que o guia de instalação trata a política como passo obrigatório, com comando de verificação, e não como endurecimento opcional.
O que a revisão cobriu
A árvore v0.1.1 foi auditada após a primeira implantação em produção — o transporte Graph, o modelo de definições, o método de API do e-mail de teste e o componente Vue, verificados quanto a fuga de segredos através de logs, respostas de API, código HTML e consola do browser; autenticação e CSRF na superfície de API; validação de entrada em todas as definições; e se os corpos de erro do Graph podem chegar a alguém que não seja superutilizador. As afirmações sobre o comportamento do Matomo foram verificadas contra o código-fonte do Matomo, não de memória.
Conclusões, declaradas com honestidade
Corrigido antes do lançamento
- Uma substituição do URL base podia ter apontado o segredo de cliente para o host de um atacante — os URL são agora validados como origens https simples antes de qualquer pedido ser construído.
- Uma falha de rede a meio de um carregamento podia deixar fugir para o log um URL de carregamento pré-autenticado — agora é convertido e censurado como qualquer outra falha.
- As definições aceitavam qualquer texto — cada campo valida agora o seu formato, pelo que um Secret ID colado falha no momento de guardar, e não mais tarde como um erro opaco da Microsoft.
- O método de API do e-mail de teste aceitava qualquer destinatário e respondia a GET — agora é apenas POST, com endereço validado e mantido fora dos logs de acesso do servidor.
Verificado e limpo
- Os segredos nunca chegam ao código HTML, à resposta da API nem à consola do browser — os campos de palavra-passe são mascarados pelo núcleo do Matomo, e o plugin acrescenta duas salvaguardas próprias por cima.
- A chamada de teste está protegida contra CSRF pelo modelo de tokens do Matomo, com uma regra apenas-POST acrescentada como defesa em profundidade.
- Tudo o que é registado ou lançado passa por um redator que apaga segredos conhecidos pelo valor e credenciais pelo formato — tokens, asserções, cabeçalhos bearer, URL de carregamento — e que falha de forma segura.
Compromissos aceites, documentados
- O token de acesso de curta duração é guardado na cache em ficheiro do Matomo — quem o conseguir ler já consegue ler a configuração do Matomo, que pode conter o próprio segredo. Mitigado pela vida útil de 55 minutos e pela política de acesso.
- Um superutilizador pode enviar e-mails de teste sem limite — um vetor de incómodo, não de privilégio; um superutilizador podia, de qualquer forma, reconfigurar o e-mail por completo.
- Um segredo introduzido na interface de definições é guardado sem cifra na base de dados do Matomo — os níveis de ficheiro de configuração e de variáveis de ambiente existem precisamente para que nunca tenha de o ser, e têm precedência.
Comunicar uma vulnerabilidade
Envie os detalhes por e-mail para o endereço abaixo. Dê-nos, por favor, a oportunidade de corrigir um problema antes de ele se tornar público — e nunca inclua um segredo de cliente, um certificado ou um ficheiro PEM numa comunicação.
Contacto de segurança:…