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

Todo mundo protege o login. Ninguém olha para o formulário de contato. E mesmo assim ele aceita entrada de qualquer pessoa, sem autenticação, sem fricção, muitas vezes sem nem um limite de envios.

É essa a assimetria que o atacante procura. Uma caixa de texto que conversa com o seu servidor de email, com o seu banco de dados, ou com um webhook interno. Você vê um campo "mensagem". Ele vê uma linha de comando.

Por que esse alvo é tão apetitoso

Um formulário de contato junta três propriedades raras no mesmo lugar. Aceita entrada não confiável. Roda lógica no servidor. E quase nunca é auditado. O programador testou que a mensagem chega no email. Parou aí.

O problema é que "a mensagem chega no email" esconde um caminho inteiro. O texto do usuário é 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 se chama email header injection. Se você pega o campo "assunto" ou "remetente" e cola direto no cabeçalho da mensagem, um atacante escreve uma quebra de linha e adiciona os próprios cabeçalhos. Um Bcc para mil endereços, por exemplo.

De repente o seu servidor está enviando spam. Não em seu nome por acaso, mas literalmente pela sua infraestrutura, com o seu IP e o seu domínio. O resultado é previsível: os grandes provedores marcam o seu domínio como fonte de spam e o seu email de negócio deixa de chegar em qualquer lugar.

O texto que vira código

Depois vêm os cenários piores. Se você guarda a mensagem num banco de dados sem parametrizar a query, abre a porta pra SQL injection. Se mostra a mensagem num painel de admin sem escapar o HTML, o atacante planta um script que roda no navegador da sua equipe quando ela abre o lead. Isso é XSS armazenado, e é um dos vetores mais subestimados que existem.

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

O que fazer, por ordem de prioridade

Você não precisa de um WAF nem de um consultor de segurança para fechar 90% disso. Precisa de disciplina em quatro pontos.

• Valide no servidor, nunca só no navegador. A validação de front-end é conforto para o usuário, não é segurança. O atacante não usa o seu formulário, faz POST direto no endpoint.
• Escape na saída, sempre. Ao gravar no banco use queries parametrizadas. Ao mostrar num painel escape o HTML. Trate cada mensagem como hostil até prova em contrário.
• Rejeite quebras de linha em campos de cabeçalho. Assunto, nome e email não têm motivo para conter \r ou \n. Filtre isso antes de tocar no SMTP.
• Limite a taxa de envios e adicione 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 todo mundo esquece

Um formulário de contato coleta dados pessoais. Nome, email, muitas vezes telefone e o conteúdo da mensagem. Isso te coloca dentro da LGPD, quer você goste ou não. Você precisa de uma base legal para tratar aqueles dados, e o consentimento tem de ser informado.

Na prática isso significa três coisas concretas. Um aviso claro de privacidade ligado ao formulário. Uma base legal definida, tipicamente o legítimo interesse do artigo 7.º 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 roubarem o seu banco 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. É se recusar 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. Trate o seu formulário de contato com o mesmo respeito que você dá ao login e a maioria desses problemas nunca chega a acontecer.