# Ataques de repetição e automação contra formulários de cadastro Guia · UNIFOKAL · 1 de setembro de 2026 · 5 min de leitura · Antifraude Por que funis de onboarding atraem bots, o que o catálogo OWASP de ameaças automatizadas descreve, quais sinais o servidor enxerga e como montar defesa em camadas sem punir o usuário legítimo. Um formulário de cadastro com recompensa do outro lado nunca é visitado só por humanos. Bônus de boas-vindas, período grátis, limite de crédito, acesso a um mercado: qualquer valor criado no fim do funil cria, no mesmo instante, o incentivo para atravessá-lo em escala. E atravessar formulários em escala é um problema resolvido do lado do atacante, com navegadores automatizados, fazendas de dispositivos e listas de dados vazados à venda. A boa notícia é que ataque automatizado deixa rastro estrutural: máquinas são boas em volume e ruins em parecer únicas. Este artigo organiza o problema com o vocabulário do catálogo OWASP de ameaças automatizadas, mapeia os sinais que o servidor enxerga e fecha com a defesa em camadas, incluindo a regra que evita transformar antifraude em máquina de expulsar cliente: sinal fraco não recusa sozinho. ## O catálogo do ataque: OWASP Automated Threats O projeto Automated Threats to Web Applications, da OWASP, a fundação de segurança de aplicações, cataloga os ataques automatizados com códigos, e dois deles moram no cadastro. O OAT-019, Account Creation, é a criação de contas em massa: cada conta nova vale um bônus, um voto, um limite ou um ponto de partida para lavagem. O OAT-008, Credential Stuffing, é o teste em massa de pares de e-mail e senha vazados de outros serviços contra o login, e interessa ao cadastro porque a conta tomada é o insumo da fraude seguinte. Ao lado dos dois vive o ataque de repetição, o replay: capturar uma requisição válida, de preferência com uma mídia que passou uma vez, e reapresentá-la. No contexto de verificação de identidade, o replay tem uma variante especializada: apresentar à câmera, ou injetar no lugar dela, uma imagem que não está sendo capturada ao vivo, o ataque descrito em detalhe no artigo sobre [injeção de câmera](https://unifokal.com/blog/injecao-de-camera). ## O que o servidor enxerga: sinais de máquina Nenhum sinal isolado condena, e é a soma que desenha a máquina: - Ritmo e volume: formulários preenchidos em tempo fisicamente implausível, picos de cadastro fora do padrão horário do produto, sequências com espaçamento regular demais para dedos humanos. - Repetição de conteúdo: a mesma selfie ou o mesmo documento reaparecendo em cadastros de nomes diferentes. A comparação biométrica um-para-muitos contra a base de rostos já vistos captura essa reciclagem, como descrito no artigo sobre [detecção de contas duplicadas](https://unifokal.com/blog/deteccao-de-contas-duplicadas). - Marcas de automação do navegador: ambientes de automação declaram-se de formas sutis, de propriedades expostas pelo próprio navegador automatizado a inconsistências entre o que o cliente afirma ser e o que consegue renderizar, sinais vizinhos da [impressão digital de dispositivo](https://unifokal.com/blog/device-fingerprinting-e-lgpd). - Procedência da mídia: metadados e características da captura incompatíveis com uma câmera ao vivo naquele aparelho. A leitura correta desses sinais é probabilística. Ambiente automatizado declarado é evidência forte; ritmo estranho e colisão de atributos são evidência fraca, que pode ser um usuário legítimo atrás de um proxy corporativo. ## Defesa em camadas, da borda ao miolo A defesa que funciona é um funil de custo crescente para o atacante: - Limite de taxa na borda: a primeira camada é aritmética, um teto de requisições por chave (IP, sessão, conta) com resposta 429 Too Many Requests, o código definido na RFC 6585. Não impede o ataque distribuído, mas mata o ataque preguiçoso e dá números para os alertas. - Idempotência no processamento: repetição faz parte do jogo, tanto do atacante quanto da rede que soluça. O consumidor idempotente, que processa a mesma requisição duas vezes com um efeito só, remove a classe inteira do replay ingênuo, como detalha o artigo sobre [idempotência em APIs](https://unifokal.com/blog/idempotencia-em-apis). - Prova de posse: exigir o código de uso único por SMS ou e-mail amarra o cadastro a algo que o atacante em escala precisa comprar, um chip ou uma caixa postal por conta, encarecendo cada tentativa, nos termos do artigo sobre [verificação por OTP](https://unifokal.com/blog/verificacao-por-otp-email-sms). - Prova de vida: a barreira que separa mídia reciclada de pessoa presente é a análise de vivacidade da selfie, tratada no artigo sobre [prova de vida](https://unifokal.com/blog/prova-de-vida-liveness). É a camada que o replay de mídia não atravessa sem esforço especializado. - Deduplicação biométrica: mesmo o atacante que fabrica dados novos a cada conta precisa de um rosto, e rostos repetidos na base são o sinal que sobrevive a todas as trocas de identidade declarada. Repare no desenho econômico: cada camada multiplica o custo unitário do atacante, e o objetivo não é a impenetrabilidade, é tirar a conta do lucro, a mesma aritmética do artigo sobre [o custo da fraude para fintechs](https://unifokal.com/blog/custo-da-fraude-para-fintechs). ## A regra final: proporcionalidade na decisão A tentação, depois de instrumentar tudo isso, é recusar automaticamente ao primeiro sinal. É a decisão errada, por dois motivos. Estatístico: sinais fracos colidem com gente legítima o tempo todo, e cada recusa injusta é um cliente perdido e uma história ruim contada adiante. E de produto: o atacante testa até achar o limiar, enquanto o usuário legítimo recusado não volta para tentar de novo. O desenho proporcional reserva a recusa automática para evidência forte, como ambiente de automação declarado, e converte sinal fraco em atrito seletivo ou revisão humana. Na UNIFOKAL, por exemplo, o desenho segue essa régua: indício fraco de automação pesa no risco e segura o caso para revisão, e a recusa automática exige evidência forte. Automação se combate com custo e com camadas; a recusa cega só transfere o custo para o cliente errado. ## Fontes citadas - OWASP, projeto Automated Threats to Web Applications, catálogo OAT (OAT-008 Credential Stuffing, OAT-019 Account Creation): [owasp.org](https://owasp.org/www-project-automated-threats-to-web-applications/) - RFC 6585, Additional HTTP Status Codes (429 Too Many Requests), IETF: [rfc-editor.org/rfc/rfc6585](https://www.rfc-editor.org/rfc/rfc6585) - RFC 9110, HTTP Semantics, IETF, semântica de métodos e repetição de requisições: [rfc-editor.org/rfc/rfc9110](https://www.rfc-editor.org/rfc/rfc9110)