O ataque que ninguém vê chega pelo formulário de contacto do teu site

Toda a gente protege o login. Ninguém olha para o formulário de contacto. E no entanto ele aceita input de qualquer pessoa, sem autenticação, sem fricção, muitas vezes sem sequer um limite de envios.

É essa a assimetria que o atacante procura. Uma caixa de texto que fala com o teu servidor de email, com a tua base de dados, ou com um webhook interno. Tu vês um campo "mensagem". Ele vê uma linha de comando.

Por que é que este alvo é tão apetecível

Um formulário de contacto reúne três propriedades raras no mesmo sítio. Aceita entrada não confiável. Corre lógica no servidor. E quase nunca é auditado. O programador testou que a mensagem chega ao email. Parou aí.

O problema é que "a mensagem chega ao email" esconde um caminho inteiro. O texto do utilizador é montado dentro de um cabeçalho SMTP, concatenado numa query, ou enviado para um serviço terceiro. Cada uma dessas fronteiras é uma oportunidade de injeção.

Injeção de cabeçalhos de email

O caso clássico chama-se email header injection. Se pegas no campo "assunto" ou "remetente" e o colas diretamente no cabeçalho da mensagem, um atacante escreve uma quebra de linha e adiciona os seus próprios cabeçalhos. Um Bcc para mil endereços, por exemplo.

De repente o teu servidor está a enviar spam. Não em teu nome por acaso, mas literalmente pela tua infraestrutura, com o teu IP e o teu domínio. O resultado é previsível: os grandes fornecedores marcam o teu domínio como fonte de spam e o teu email de negócio deixa de chegar a lado nenhum.

O texto que vira código

Depois há os cenários piores. Se guardas a mensagem numa base de dados sem parametrizar a query, abres a porta a SQL injection. Se mostras a mensagem num painel de admin sem escapar o HTML, o atacante planta um script que corre no browser da tua equipa quando ela abre o lead. Isto é XSS armazenado, e é dos vetores mais subestimados que existem.

Repara no padrão. Em nenhum destes casos o atacante "invadiu" nada. Usou o formulário exatamente como está desenhado para ser usado. A vulnerabilidade não é uma falha exótica. É a ausência de uma regra simples: nunca confies no que entra.

O que fazer, por ordem de prioridade

Não precisas de um WAF nem de um consultor de segurança para fechar 90% disto. Precisas de disciplina em quatro pontos.

• Valida no servidor, nunca só no browser. A validação de front-end é conforto para o utilizador, não é segurança. O atacante não usa o teu formulário, faz POST direto ao endpoint.
• Escapa na saída, sempre. Ao gravar em base de dados usa queries parametrizadas. Ao mostrar num painel escapa o HTML. Trata cada mensagem como hostil até prova em contrário.
• Rejeita quebras de linha em campos de cabeçalho. Assunto, nome e email não têm razão para conter \r ou \n. Filtra-os antes de tocar no SMTP.
• Limita a taxa de envios e adiciona um desafio invisível. Rate limiting por IP e um honeypot ou hCaptcha param bots automáticos sem estragar a experiência de quem é humano.

E o lado que quase toda a gente esquece

Um formulário de contacto recolhe dados pessoais. Nome, email, muitas vezes telefone e o conteúdo da mensagem. Isso coloca-te dentro do RGPD, quer gostes quer não. Precisas de uma base legal para tratar aqueles dados, e o consentimento tem de ser informado.

Na prática significa três coisas concretas. Uma nota clara de privacidade ligada ao formulário. Uma base legal definida, tipicamente o interesse legítimo do artigo 6.º ou o consentimento explícito. E uma política de retenção, porque guardar leads para sempre não é uma estratégia, é uma responsabilidade acumulada. Se te roubarem a base de dados de leads, o problema deixa de ser técnico e passa a ser regulatório.

Segurança de formulário não é um firewall caro. É recusar-te a confiar no texto que um estranho escreveu.— Krivar Diário

A moral é chata e por isso funciona. O ataque que ninguém vê chega pela porta que ninguém olha. Trata o teu formulário de contacto com o mesmo respeito que dás ao login e a maioria destes problemas nunca chega a acontecer.