Por que o spam venceu meu formulário de contato com limite de taxa

Por que o spam atravessa um formulário de contato com limite de taxa? Porque um limite de taxa conta requisições por endereço, e nada nele pergunta quem as enviou. Em 30 de outubro e 2 de novembro, dois scanners de vulnerabilidades rastrearam meu site, carregaram a página inicial que traz o formulário, como faz qualquer visitante, pegaram um token CSRF válido e enviaram o formulário até seguirem adiante ou serem bloqueados. No primeiro dia passaram 101 envios e no segundo 31, cada um com um 200 da aplicação, que ela devolve tanto para um envio quanto para um envio que falhou, então esses números são o máximo de e-mails que eles poderiam ter gerado.¹² O limitador da minha aplicação, configurado para cinco envios por minuto por endereço, recusou 830 e 31 dos envios deles e deixou passar 101 e 31, 47 e 9 a mais do que um limitador exato com essa configuração teria permitido.³ O limite de taxa na edge nunca disparou com nenhum dos dois scanners: eu o criei cerca de 12 minutos depois do último envio do formulário da primeira enxurrada, e os envios do segundo scanner chegaram por dois data centers da Cloudflare, que mantêm contadores separados. Essa divisão é minha explicação mais forte para o segundo silêncio: ela se encaixa nos totais por minuto, que não podem prová-la.⁴⁵⁶ No site do meu estúdio, um campo honeypot pegou 42 de 52 envios em oito dias e deixou passar os 10 cujos remetentes deixaram o honeypot vazio.⁷⁸ A edge deste site tinha, sim, uma regra capaz de perguntar se há uma pessoa do outro lado, um desafio gerenciado no caminho do formulário, mas ele só dispara com uma string de user agent de uma lista, e os dois scanners enviaram a string de um navegador; um segundo desafio, baseado em uma pontuação de ameaça alta, nunca poderia disparar, porque a Cloudflare agora fixa essa pontuação em zero, então nada fez essa pergunta a cada envio.⁹¹⁰⁴¹¹ Desde a manhã de 3 de novembro, o Turnstile faz essa pergunta a cada envio que poderia chegar à minha caixa de entrada, nos dois formulários.¹²

TL;DR

• Dois scanners, uma caixa de entrada. Um endereço enviou ao meu site 76.429 requisições em 53 intervalos de um minuto em 30 de outubro; outro enviou 10.907 em 22 em 2 de novembro. Os dois rastrearam o site inteiro, os dois enviaram strings de injeção de SQL nos caminhos e no cabeçalho User-Agent, e os dois enviaram o formulário de contato: 1.065 vezes no primeiro dia e 500 no segundo.¹³¹⁴¹²
• Um token CSRF válido só prova que um cliente tinha um token emitido pelo meu site. Todo envio dos dois dias carregava um, porque meus tokens não têm estado e qualquer cliente que baixa a página recebe um. A verificação CSRF recusou quatro envios em duas enxurradas.¹⁵¹⁶
• Meu próprio limitador vazava. Ele lê um contador do Cloudflare KV, compara, depois lê de novo e grava a contagem mais um em uma requisição separada; se a segunda leitura falha, ele grava um, e se uma chamada ao KV falha, ele recorre a uma contagem guardada na memória de um único processo. Qualquer um desses caminhos pode deixar passar mais de cinco, e os logs não dizem qual deles fez isso: 18 envios saíram em um minuto contra um limite de cinco.¹⁷¹
• O limite de taxa na edge conta por endereço e por data center. Em 2 de novembro, os 85 envios do formulário feitos pelo scanner entre 18:56 e 19:05:00 UTC, os minutos de cada lado do bloqueio, vieram por Amsterdã e Londres, 44 e 41, e o minuto mais movimentado se dividiu em 18 a 14 entre os dois. Essa divisão é o motivo mais provável para a regra ter ficado em silêncio, embora os totais por minuto não possam prová-lo. Um teste que fiz na manhã seguinte provou que a regra dispara e que a Cloudflare registra isso.⁵¹⁸
• Os bloqueios foram bloqueios de endereço, e os dois chegaram tarde demais para manter o e-mail de fora. Em 30 de outubro bloqueei o endereço à mão 3,9 minutos depois de perceber, cerca de 50 minutos depois do primeiro envio do formulário. Em 2 de novembro meu monitor o bloqueou 8 minutos depois do primeiro minuto da varredura. Nenhum envio de nenhum dos dois dias veio depois do minuto do bloqueio: em 30 de outubro o último veio mais de 12 minutos antes do bloqueio, e em 2 de novembro 26 vieram nos minutos anteriores e 5 no próprio minuto do bloqueio, que os dados por minuto não conseguem situar antes ou depois do segundo do bloqueio.¹⁰¹⁹¹²
• O honeypot pega os bots que preenchem todos os campos. No site do meu estúdio ele respondeu a 42 de 52 envios como se tivessem dado certo e não gravou nada; pela hora em que chegaram, todo envio vindo de uma saída do Tor estava entre eles. Os 10 que foram gravados, e portanto no máximo 10 e-mails, vieram de remetentes que deixaram o honeypot vazio.⁷²⁰
• O que mudou. Os dois formulários agora têm um widget do Cloudflare Turnstile em modo gerenciado, e o servidor não grava nem envia nada até que a API siteverify da Cloudflare aceite o token do envio, recusando um token ausente, grande demais ou impossível de verificar. O Turnstile executa desafios no navegador do visitante e processa sinais como endereço IP, impressão digital TLS e user agent; a Cloudflare diz que ele não toca no que é digitado nos formulários. Ele não impede uma pessoa que digita spam à mão e não substitui os limites de taxa, que continuam limitando o volume.¹²²¹²²

1. A pergunta: “é você?”

Em 2 de novembro minha caixa de entrada se encheu de mensagens do formulário de contato, e minha primeira pergunta, feita à sessão de agente que opera minha infraestrutura, foi se a minha própria automação estava enviando aquilo. Não estava. Quem enviava era um scanner, pelo formulário de contato deste site, e o formulário do site do meu estúdio, 941apps.com, recebia um gotejamento lento próprio, embora nada dele tenha chegado à caixa de entrada naquele dia.²³⁸ Os três fluxos de e-mail, os alertas do meu monitor e os dois formulários, saem de um mesmo endereço do meu próprio domínio de e-mail, então na caixa de entrada eles pareciam iguais.²³

Os assuntos entregaram o jogo. O handler de contato deste site me envia cada mensagem com o assunto “Contact Form:” seguido do que o remetente digitou nos campos de nome, então o payload de um scanner vira uma linha de assunto.²⁴²³ O formulário do site do estúdio grava cada mensagem em um banco de dados e depois a envia por e-mail para a mesma caixa.²⁵

A pergunta que fiz primeiro era a errada, e a certa levou um dia de consultas para responder: qual dos controles desses formulários poderia ter distinguido um scanner de uma pessoa, e por que cada um deixou passar o resto? Havia cinco tipos de controle. Neste site, um firewall na edge com regras personalizadas, um limite de taxa na edge, um token CSRF e um limitador de taxa na aplicação. No site do estúdio, o mesmo tipo de regras na edge, um limite de taxa na edge e um limitador próprio da aplicação que não recusou nenhum dos envios observados, além de um campo honeypot.⁹²⁵⁷ O resto deste post percorre as duas enxurradas e o gotejamento lento, um de cada vez, e depois as cinco camadas, uma de cada vez, com o texto da regra ou o comportamento do código para cada uma.

De onde vêm os números

Toda contagem abaixo vem das análises de requisições e dos eventos de firewall da Cloudflare para as duas zonas, consultados em 3 de novembro sobre janelas já fechadas, além da tabela de mensagens do site do estúdio e do log do meu próprio monitor.¹⁶ Um script transformou os resultados salvos dessas consultas em um registro de algumas centenas de linhas, cada uma com a regra que a produziu, e o post tira seus números do registro e do seu anexo e de nenhum outro lugar. Onde minhas anotações do dia discordam do registro, o registro vence: escrevi as anotações de 30 de outubro minutos depois da enxurrada, enquanto a Cloudflare ainda ingeria os últimos minutos, e elas contam a menos.¹⁶²⁶ A Cloudflare mantém esses conjuntos de dados por “at least 31 days of data on every plan” (pelo menos 31 dias de dados em todos os planos), então pude contar uma enxurrada depois do fato, mas não para sempre.²⁷

Dois tipos de número pedem um aviso. Os eventos de firewall são uma amostra, então eu os uso para saber qual regra agiu e quando, e os conjuntos de dados de requisições para saber quantas foram.¹⁶ E um envio do formulário que recebeu 200 neste site é um envio, ou uma falha à qual o handler também responde com 200 (ele tem dois caminhos de falha assim), não um e-mail entregue, e eu não verifiquei o log do meu provedor de e-mail. Toda contagem de e-mails deste post é, portanto, um teto.²⁴²⁸

Como era o normal

Antes das enxurradas, o formulário era tranquilo. Nos oito dias cobertos pelas consultas, três endereços além dos dois scanners enviaram o formulário com sucesso, cada um exatamente duas vezes, um endereço por dia em 27, 28 e 29 de outubro.²⁹ Não sei se eram pessoas. Dois envios de um mesmo endereço combinam com um clique duplo, e combinam com um bot que tenta de novo. Essa incerteza é o problema inteiro em miniatura: nada nos logs nem nos controles conseguia dizer.

2. Primeira enxurrada: 30 de outubro, bloqueada à mão

A primeira enxurrada veio de um único endereço em uma rede que o registro regional de internet lista sob BULLIONET FBW NETWORKS SAS, registrada na França.³⁰ Sua primeira requisição caiu no minuto das 17:59 UTC, 10:59 no horário de verão do Pacífico, e a última no minuto das 18:51, 11:51 PDT: 53 intervalos de um minuto e 76.429 requisições a este site. Duas consultas independentes, uma por minuto para o endereço e outra varrendo todas as zonas da minha conta, concordam nesse total, e o endereço não enviou nada antes nem depois.¹³

O formato da varredura

O formulário foi uma parte pequena dela. Antes do bloqueio, o endereço fez em média 1.389,7 requisições por minuto, com pico de 3.219 no minuto das 18:36, e percorreu o site inteiro: pelo menos 2.881 caminhos distintos, um limite inferior porque a consulta de caminhos bateu no seu limite de linhas.¹³³¹ Na varredura inteira, os resultados se dividiram assim:¹³

Os 7,3% da edge são quase todos o bloqueio: 5.234 de suas 5.587 recusas vieram depois do minuto do bloqueio.¹³ Nos cinquenta minutos anteriores, só a regra de caminhos de exploit agiu. Essa regra funcionou desde o primeiro minuto, com o primeiro evento de firewall às 17:59:53 UTC, mas ela casa com trechos de caminho como .php e /wp-, e a maior parte desta varredura pedia páginas reais.¹⁰⁹

O que fazia disso uma varredura e não um rastreamento era o que ela colocava nas requisições. Quase todo o tráfego, pelo menos 69.322 requisições, usava um único user agent comum do Chrome 141 para Windows. Pelo menos mais 2.755 se diziam Googlebot, e a regra de bots verificados da edge não as tratou como Google.³² Pelo menos 3.154 requisições traziam um payload de injeção de SQL no próprio cabeçalho User-Agent, em pelo menos 396 strings distintas, e pelo menos 2.680 requisições traziam um no caminho, em pelo menos 810 caminhos distintos.³²³¹ Os payloads pertencem a famílias documentadas. PG_SLEEP(15), waitfor delay '0:0:15' e XOR(if(now()=sysdate(),sleep(15),0)) são sondas baseadas em tempo: a folha de referência da PortSwigger lista a sintaxe de atraso para Oracle, Microsoft SQL Server, PostgreSQL e MySQL, e as definições de payload do próprio sqlmap contêm as mesmas funções.³³³⁴ A PortSwigger explica por que elas funcionam: “As SQL queries are normally processed synchronously by the application, delaying the execution of a SQL query also delays the HTTP response.” (como a aplicação normalmente processa as consultas SQL de forma síncrona, atrasar a execução de uma consulta também atrasa a resposta HTTP).³⁵ Uma resposta lenta prova pouco; um atraso de cerca de 15 segundos que volta toda vez que o payload o pede, e não aparece nas requisições de controle sem ele, é evidência de uma possível injeção.

O app de pintura deste site tem um endpoint de compartilhamento, e o scanner o encontrou. Ele enviou 320 POSTs para o caminho de compartilhamento, o único endereço a fazer isso nos oito dias cobertos pelas consultas, e o endpoint recusou todos os 320 e não gravou nada. Em volta deles, enviou POSTs para variantes do caminho com o payload embutido, como /paint/share'||DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15)||' e /paint/(select 198766*667891 from DUAL), às quais o site respondeu com 404.³¹ O endereço também tocou uma outra zona da minha conta, enviando 387 GETs para kiradex.app, todos respondidos com 200, e nenhuma outra.¹³ Minha leitura é que ele seguiu links deste site para aquele; não verifiquei os links.

O catálogo de ameaças automatizadas da OWASP tem um nome para essa atividade: OAT-014, Vulnerability Scanning, “Crawl and fuzz application to identify weaknesses and possible vulnerabilities.” (rastrear a aplicação e aplicar fuzzing para identificar fraquezas e possíveis vulnerabilidades).³⁶ O formulário de contato era só mais uma entrada para o fuzzing.

O formulário, minuto a minuto

O endereço enviou o formulário de contato 1.065 vezes, e todos os envios chegaram à aplicação; a edge não barrou nenhum.¹ O primeiro envio e o primeiro e-mail saíram no minuto das 18:00 UTC, 11:00 PDT. Aqui está cada minuto em que um envio do formulário chegou à aplicação, pelo status que a aplicação devolveu:¹

Os totais: 101 enviados, 830 recusados pelo limitador da aplicação, 130 recusados porque faltava um campo obrigatório e 4 recusados pela verificação CSRF, os quatro no minuto das 18:03.¹ Os 429 eram da aplicação. A regra de limite de taxa da edge ainda não existia, não há nenhum evento de firewall de limite de taxa para o endereço, e onde a Cloudflare registrou o status da origem para esses envios, o 429 veio da origem.¹⁰³⁷ Os 422 vieram da validação de formulários do FastAPI, que roda antes do limitador, então nunca gastaram uma vaga do limitador; conferi a ordem com um app FastAPI de dez linhas, no qual um envio sem um campo obrigatório devolveu 422 sem nunca chamar o wrapper.³⁸ A rajada de 129 às 18:37 parece o scanner aplicando fuzzing aos campos do formulário ao omiti-los.

Leia a coluna “Enviados” contra o limitador. O limitador permite cinco envios por endereço por minuto de relógio, e em oito desses minutos saíram mais de cinco, 18 deles às 18:06.¹³ A seção 4 explica como.

A percepção e o bloqueio

Percebi às 11:46 PDT e anotei que alguma coisa batia no formulário de contato do site sem parar.²⁶ A essa altura o primeiro envio do formulário tinha cerca de 46 minutos, e a enxurrada no formulário em si tinha terminado às 11:37 PDT.¹ Adicionei o endereço à mão à lista de bloqueio da conta com a qual a primeira regra personalizada da zona já casa, e o primeiro evento dessa regra veio às 18:49:53 UTC, 11:49:53 PDT.¹⁰ O bloqueio veio 3,9 minutos depois que percebi, cerca de 50 minutos depois do primeiro envio do formulário e 50,9 minutos depois do primeiro minuto da varredura.¹¹³ Todos os 101 envios já tinham saído antes dele; o último envio do formulário a chegar à aplicação veio cerca de 12 minutos antes do bloqueio.¹ Depois do minuto do bloqueio, o endereço enviou mais 5.234 requisições, e a edge recusou todas.¹³

No mesmo segundo, 18:49:53 UTC, criei a única regra de limite de taxa da zona: POSTs de formulário para os caminhos de contato e de compartilhamento do app de pintura, 3 a cada 10 segundos por endereço, com bloqueio por 10 segundos.⁹ Às 18:52:38 UTC eu a testei da minha própria máquina. Nas minhas anotações desse teste, seis envios com um segundo de intervalo, com user agent de navegador e sem um token CSRF válido, “returned 403 403 403 429 429 429 (the app’s CSRF rejection, then the edge’s rate limit)” (devolveram 403 403 403 429 429 429: a recusa CSRF da aplicação e depois o limite de taxa da edge), e envios simples com curl nunca chegaram à regra, porque uma regra personalizada existente serviu um desafio gerenciado a eles.²⁶ Minhas anotações dizem que os envios não tinham token, mas um envio sem esse campo leva um 422 antes de o handler rodar, como mostrou meu teste de 3 de novembro, então os 403 indicam um token presente e inválido.¹⁸ Os eventos de firewall concordam: três eventos de limite de taxa do meu endereço de teste, o primeiro naquele segundo, e 24 desafios gerenciados para meus envios com curl.³⁹ Nada do meu tráfego de teste está em nenhuma contagem acima.

Meu monitor não estava rodando naquele dia. Eu o reativei em 31 de outubro, e o detector de tráfego dele veio depois desta enxurrada.¹⁹ O bloqueio de 30 de outubro foi feito por uma pessoa lendo a caixa de entrada.

30 de outubro: 76.429 requisições de um único endereço, por minuto; até eu bloquear o endereço à mão, a edge quase não recusou nenhuma.¹³¹⁰

3. Segunda enxurrada: 2 de novembro, bloqueada pelo meu monitor

O segundo endereço pertence à NovoServe B.V., um provedor de hospedagem na Holanda.⁴⁰ Ele enviou dois GETs às 07:49 UTC, 23:49 no horário padrão do Pacífico de 1º de novembro, e depois nada por 11,1 horas. A varredura propriamente dita foi do minuto das 18:56 UTC ao das 19:17, das 10:56 às 11:17 PST: 22 intervalos de um minuto e 10.907 requisições, ou 10.909 com os dois GETs iniciais. Quatro consultas independentes concordam no total.¹⁴

Parecia a mesma ferramenta. Usou a mesma string de user agent do Chrome 141 para Windows que o endereço de 30 de outubro em 9.725 requisições, a mesma string de Googlebot em 942, as mesmas famílias de injeção, e tocou as mesmas duas zonas e nenhuma outra, com 368 GETs para kiradex.app.⁴¹⁴²¹⁴ Dois endereços em duas redes de dois países não provam nada sobre quem os operava, então paro em “parecia”.

A linha do tempo, nos dois fusos horários

Os oito minutos do meu monitor

Meu monitor levantou seu primeiro achado 7,9 minutos depois do primeiro minuto da varredura, e o bloqueio entrou em vigor 8,0 minutos depois dele, ou 6,8 minutos depois do primeiro evento de firewall.¹⁹⁴ A essa altura, 26 envios tinham saído nos minutos anteriores ao bloqueio, e os últimos 5 caíram no próprio minuto do bloqueio, que os dados por minuto não conseguem situar antes ou depois do segundo do bloqueio; nenhum veio nos minutos seguintes.² Oito minutos é rápido para um bloqueio e lento para uma caixa de entrada.

A execução que começou às 10:57:00 PST teve a varredura à vista por cerca de um minuto, e na janela dela o endereço fez algo entre 29 e 666 requisições; o número maior conta o minuto inteiro das 18:57, do qual a janela viu só 22 segundos. O detector não registrou nenhum achado.¹⁹ A execução seguinte, às 11:02:46 PST, encontrou a enxurrada e a bloqueou, e essa execução mostra por que a primeira podia deixá-la passar. A janela dela terminava no momento em que consultava a Cloudflare, antes de os eventos mais recentes chegarem: o log dela registra 1.914 requisições do endereço, enquanto minha reprodução da mesma janela de cinco minutos em 3 de novembro, sobre dados completos, conta 2.143; a reprodução está salva com os comandos e a saída completa, e suas contagens são linhas do anexo do registro.¹⁹⁴³ A reprodução também levanta um achado de enxurrada no formulário que a execução real nunca levantou, a partir de 39 envios, 23 deles recusados, com severidade alta, que teria sido uma linha no resumo diário e não um e-mail nem um bloqueio.⁴³ Reproduzi a janela da segunda execução, não a da primeira, então para a execução das 10:57 PST o mesmo atraso é a causa provável, não uma causa medida. No mesmo dia mudei as janelas do monitor para terminarem 90 segundos antes de cada execução e começarem onde a anterior terminou.⁴³ No total, seis achados dispararam sobre o endereço, e meu monitor incorporou todos ao resumo diário em vez de me mandar e-mail, porque o endereço já estava no registro de bloqueios dele.¹⁹ Como meu monitor deveria alertar, e este scanner visto do lado dele, é o assunto de um post à parte; para este, o que importa é que um bloqueio é uma reação, e a reação veio depois de pelo menos 26 dos 31 envios.

O formulário, por status

O endereço enviou o formulário 500 vezes.²

Os totais: 31 enviados, 31 recusados pelo limitador da aplicação e 438 recusados na edge, todos no minuto do bloqueio ou depois. Então 62 envios chegaram à aplicação.² Cada envio que saiu prova que o scanner tinha um token CSRF válido, porque o handler verifica o token antes de enviar. Os 429 não provam nada em nenhum sentido, porque o limitador recusa um envio antes de o handler ler o token.²⁴¹⁶ Onde a Cloudflare registrou o status da origem para esses 429, era o da origem, o do limitador da aplicação, e não há nenhum evento de firewall de limite de taxa para o endereço.³⁷⁴

O resto da varredura

Por resultado, a varredura de 2 de novembro se dividiu assim:¹⁴

Os 72,7% da edge são principalmente o bloqueio: 2.986 requisições vieram antes do minuto do bloqueio e 7.445 depois, e o site não serviu nenhuma destas últimas.¹⁴ A consulta de caminhos deste dia foi completa: 2.173 caminhos distintos, e 778 requisições em 542 deles traziam um payload de injeção de SQL.⁴⁴ A consulta de user agents também foi completa, 73 strings distintas. Além da string comum do Chrome e da alegação de ser Googlebot, o scanner enviou 54 payloads SQL distintos em 149 requisições, três strings para quebrar aspas em 78 e 12 tokens marcadores, cada um enviado uma vez.⁴¹

Vale olhar algumas dessas strings, porque elas mostram o que o scanner perguntava. (select 198766*667891 from DUAL) é uma expressão aritmética dentro de um select sem tabela; FROM dual é a sintaxe do Oracle para isso, como mostra a folha de referência da PortSwigger.³³ if(now()=sysdate(),sleep(15),0) tem a mesma forma IF(condition, SLEEP(n), x) do atraso condicional da mesma folha de referência.³³ @@qkLpP é um prefixo @@, o que a folha de referência usa em SELECT @@version para Microsoft e MySQL, seguido de cinco caracteres, e o scanner enviou uma dúzia parecidas.³³⁴¹ O guia de testes da OWASP nomeia as duas técnicas a que essas strings servem: a injeção baseada em erro, que “forces the database to generate an error” (força o banco de dados a gerar um erro), e os atrasos de tempo que “use database commands (e.g. sleep) to delay answers in conditional queries.” (usam comandos do banco de dados, como sleep, para atrasar respostas em consultas condicionais).⁴⁵ Nenhuma das páginas que consultei documenta essas strings exatas, então eu as descrevo e não as atribuo a uma ferramenta específica.

2 de novembro: 10.907 requisições de um único endereço, por minuto, com as duas execuções do meu monitor e o bloqueio que ele aplicou às 11:04:01 PST.¹⁴¹⁹

4. As cinco camadas, e o que cada uma conseguia distinguir

Cinco tipos de controle ficavam entre esses bots e minha caixa de entrada. A cada um fiz a mesma pergunta: ele conseguia distinguir um bot de uma pessoa? Um desafio gerenciado nas regras da edge pode fazer essa pergunta a um visitante, mas só às requisições cuja string de user agent está na lista dele, e as dos scanners não estavam; um segundo, baseado em uma pontuação de ameaça, nunca poderia disparar, então nada fez essa pergunta a cada envio. Dois dos controles contam, um compara nomes e listas, um prova que um cliente tem um token emitido pelo site e um pega só os bots que preenchem um campo oculto. Aqui está cada um, o que ele verifica, o que barrou e o motivo exato pelo qual deixou passar o resto.

Regras personalizadas da edge

O que verificam. Neste site, a primeira regra personalizada bloqueia qualquer endereço de uma lista no nível da conta, mais sete redes de hospedagem por ASN. Outra bloqueia trechos de caminhos de exploit como .php, /wp- e /.env. Mais duas servem um desafio gerenciado no formulário de contato e no caminho de administração: uma para um user agent vazio ou que contenha curl, wget, python-requests, httpx, scrapy, HeadlessChrome, PhantomJS ou Selenium, e outra para uma pontuação de ameaça alta da Cloudflare. O site do estúdio tem regras do mesmo tipo, com os dois desafios aplicados ao site inteiro e um bloqueio nos caminhos de API que isenta o formulário de contato.⁹ Os desafios por pontuação de ameaça, um em cada site, eram regras mortas: a referência de campos da Cloudflare diz que a pontuação ia antes de 0 a 100, e “Now, the threat score is always 0 (zero).” (agora a pontuação de ameaça é sempre 0). Uma regra que pede uma pontuação alta não casa com nada, e desativei as duas em 3 de novembro, o dia em que li isso; os desafios por user agent continuam.¹¹⁴⁶ O plano Free da Cloudflare permite cinco regras personalizadas, que “work as customized web application firewall (WAF) rules that you can use to perform actions like Block or Managed Challenge on incoming requests.” (funcionam como regras personalizadas de firewall de aplicações web com as quais você pode executar ações como Block ou Managed Challenge sobre as requisições recebidas).⁴⁷

O que barraram. Os caminhos de exploit, desde o primeiro minuto nos dois dias.¹⁰⁴ Em 30 de outubro, nenhum envio do formulário.¹¹⁰ Em 2 de novembro, os 438 envios do formulário posteriores ao bloqueio do meu monitor.² No site do estúdio, nenhum envio do formulário: o firewall não registrou nenhum evento sobre um POST ao formulário nos oito dias.⁷

Por que o resto passou. Nenhuma regra olha para o que uma requisição é. A regra da lista só casa com um endereço depois que algo o coloca na lista, uma pessoa em 30 de outubro e meu monitor em 2 de novembro.⁹¹⁰¹⁹ O desafio por user agent compara uma string, e os dois scanners enviaram uma string de navegador, pelo menos 69.322 vezes no primeiro dia e 9.725 vezes no segundo.³²⁴¹ O desafio por user agent funciona, sim, contra ferramentas que se anunciam: meu próprio teste com curl em 30 de outubro provocou 24 desafios gerenciados.³⁹ O desafio por pontuação de ameaça não podia disparar com ninguém, e o firewall não registrou nenhum desafio no formulário para nenhum dos dois endereços.¹¹¹⁰⁴ Saídas do Tor e redes de hospedagem fora dos sete ASNs citados não estão em nenhuma lista.

Uma regra da edge consegue distinguir um endereço conhecido, uma rede conhecida ou uma ferramenta honesta do resto, e o desafio dela pergunta se há uma pessoa só às requisições que sua expressão seleciona; ela não consegue distinguir uma string de navegador enviada por um scanner de um navegador.

Limite de taxa na edge

O que verifica. O texto da regra é curto:⁹

(http.request.method eq "POST" and http.request.uri.path in {"/api/contact" "/paint/share"})

Ela conta as requisições que casam por data center da Cloudflare e endereço do cliente, permite 3 a cada 10 segundos e bloqueia por 10 segundos. Distribuído de forma uniforme, esse teto equivale nominalmente a 18 por minuto por endereço por data center; a regra em si conta em períodos de 10 segundos.⁹¹⁶ O plano Free fixa o período, o tempo de bloqueio e a chave de contagem, e dá à zona uma única regra desse tipo: um período de contagem de 10 segundos, um tempo de mitigação de 10 segundos e contagem por IP.⁴⁸ O data center também não é opcional. “Every rate limiting rule includes the Cloudflare data center ID (cf.colo.id) as a mandatory characteristic” (toda regra de limite de taxa inclui o ID do data center da Cloudflare como característica obrigatória), diz a documentação da Cloudflare, e “Counters are not shared across data centers, with the exception of data centers associated with the same geographical location.” (os contadores não são compartilhados entre data centers, exceto entre os associados à mesma localização geográfica).⁶

O que barrou. Nenhuma requisição dos scanners em nenhum dos dois dias. Seus únicos eventos na janela do incidente foram os três do meu próprio teste.¹⁰⁴³⁹ O site do estúdio tem uma regra de limite de taxa própria para o site inteiro, contada do mesmo jeito sobre todas as requisições exceto as de clientes que a Cloudflare lista como bots verificados, e ela não recusou nenhum dos envios do gotejamento: o firewall dela não registrou nenhum evento sobre um envio ao formulário nos oito dias. Essa regra conta cada requisição desse tipo que um endereço envia ao site, e meus dados contam só os envios do formulário, então não medem quanta folga restava ao contador.⁹⁷

Por que o resto passou. Em 30 de outubro, a regra não existiu até 18:49:53 UTC, o mesmo segundo do primeiro evento do bloqueio manual e cerca de 12 minutos depois que o último envio do formulário chegou à aplicação.⁹¹ Os 1.065 envios daquele scanner vieram todos por um único data center, Paris, então uma regra em vigor teria mantido um único contador para eles.⁵ Em 2 de novembro a regra existia, e os envios do formulário feitos pelo scanner vieram por dois data centers, Amsterdã com 44 e Londres com 41, entre 18:56 e 19:05:00 UTC. No minuto mais movimentado, 19:02, Londres levou 18 e Amsterdã 14.⁵ Dezoito em um minuto é o equivalente nominal do teto da regra, mas meus dados têm totais por minuto, não horários de chegada, então não podem mostrar se algum período de 10 segundos em um data center teve mais de três. A Cloudflare é clara quanto à precisão: “Rate limiting rules are not designed to allow a precise number of requests to reach your origin server. There may be a delay of up to a few seconds between detecting a request and updating rate counters.” (as regras de limite de taxa não foram projetadas para deixar chegar um número preciso de requisições ao servidor de origem; pode haver um atraso de até alguns segundos entre detectar uma requisição e atualizar os contadores).⁴⁸ No intervalo de sete minutos entre o primeiro envio a chegar à aplicação e o último, o scanner fez em média 8,86 por minuto.² Minhas anotações do dia chamaram isso de “about nine a minute” (cerca de nove por minuto) e pararam aí; a divisão entre data centers foi o que escapou a elas.²³

Eu queria uma prova de que a regra funciona, então na manhã de 3 de novembro eu a testei da minha própria máquina. Às 06:36:49 PST enviei dez POSTs com 0,4 segundo de intervalo sem token CSRF: quatro voltaram com 422, porque faltava um campo obrigatório e o FastAPI os recusou, e depois seis voltaram com 429. Às 06:38:03 PST enviei oito com todos os campos presentes: três voltaram com 403, a recusa CSRF da origem, e depois cinco voltaram com 429 e o corpo “error code: 1015” da Cloudflare. O firewall registrou 11 eventos no formulário naqueles minutos, todos bloqueios da regra de limite de taxa.¹⁸ A regra dispara, e a Cloudflare registra. Minha leitura de 2 de novembro é uma hipótese: dividido entre dois contadores e rodando perto do teto nominal de cada um, o scanner nunca acionou nenhum deles. É a explicação mais forte que se encaixa nos totais por minuto, não uma demonstração; os totais não mostram como os envios se espaçaram dentro de cada minuto, e a Cloudflare admite que requisições excedentes podem passar enquanto seus contadores se atualizam.⁵⁴⁸

Um limite de taxa consegue distinguir rápido de lento, para um endereço em um data center; ele não consegue dizer quem está enviando.

Token CSRF

O que verifica. O formulário deste site carrega um token oculto, inserido na página, com três partes: um carimbo de tempo, um valor aleatório e uma assinatura HMAC sobre os dois primeiros. O servidor o aceita se a assinatura confere e o carimbo de tempo tem menos de uma hora.¹⁵ O formulário do site do estúdio não tem token CSRF.²⁵

O que barrou. Quatro envios em 30 de outubro, todos no minuto das 18:03, e nenhum em 2 de novembro.¹²

Por que o resto passou. O token não tem estado. Ele não está ligado a uma sessão, a um cookie nem a um endereço, então qualquer cliente que baixa a página recebe um válido, e qualquer cliente que recebe um token de outro pode apresentá-lo enquanto ele durar. Os dois scanners de fato baixaram as páginas do site; é isso que os logs de requisições mostram. O que a verificação mostra é mais restrito: todo envio dos dois dias carregava um token válido e não expirado emitido pelo meu site, porque o handler verifica o token antes de enviar.^1513142416 Um token CSRF existe para impedir que outro site faça o navegador de um visitante enviar meu formulário. Ele nunca foi pensado para barrar um cliente que quer enviar o formulário por conta própria, e não barrou.

A mesma verificação tinha um segundo defeito, e ele recaía sobre pessoas, não bots. Quando o token falhava, o handler lançava um 403 em JSON que o formulário HTMX nunca exibia, então uma pessoa com um token expirado teria clicado em Enviar e não teria visto nada.¹² Corrigi isso, embora minha primeira correção também não tenha funcionado; a seção 6 conta como.

Um token CSRF válido prova que o cliente tinha um token não expirado emitido pelo meu site; ele não pode provar quem preencheu o formulário, nem mesmo que esse cliente carregou a página.

Limitador de taxa da aplicação

O que verifica. O handler deste site fica atrás de um decorator que conta os envios do formulário por endereço de cliente por minuto de relógio no Cloudflare KV, com um fallback em memória, e recusa a partir de cinco com um 429.¹⁷ O site do estúdio tem um limitador em memória por processo para clientes anônimos, contado por endereço e por classificação do cliente, a classe que o limitador atribui a partir do user agent e do endereço, sobre todos os caminhos exceto health checks e arquivos estáticos.²⁵

O que barrou. 830 envios em 30 de outubro e 31 em 2 de novembro. Nenhum no site do estúdio.¹²⁷

Por que o resto passou. Por projeto, ele deixa passar cinco por minuto para qualquer um, e como a janela é o minuto de relógio, uma rajada que atravessa a virada do minuto ganha duas cotas.¹⁷ Isso eu sabia. O que eu não sabia até ler as contagens contra o código é que ele vaza, e o código tem pelo menos três jeitos de vazar. O limitador lê o contador do KV por HTTP, compara com o limite e depois grava a contagem mais um em uma requisição separada, então dois envios que leem antes de qualquer um gravar passam os dois. O incremento lê o contador uma segunda vez antes de gravar, e se essa segunda leitura falha, a gravação volta a contagem para um, então o minuto recomeça. E sempre que a leitura do KV não devolve nada ou a gravação falha, a decisão passa para uma lista guardada na memória de um único processo, que os outros processos não compartilham.¹⁷

As contagens mostram o vazamento. Em 30 de outubro, oito minutos tiveram mais de cinco envios, e o minuto das 18:06 teve 18.¹ Um limitador exato de cinco por minuto teria permitido no máximo 54 envios nos minutos em que o scanner enviou, e saíram 101, 47 acima do teto. Em 2 de novembro, os minutos das 19:02 e 19:03 deixaram passar 9 e 10; um limitador exato teria permitido no máximo 22 dos 62 envios que viu, e saíram 31, 9 acima do teto.³ Elas não mostram qual caminho vazou. Minha leitura é que envios leram a mesma contagem antes de qualquer um gravar, ou que chamadas ao KV falharam sob a carga, zerando a contagem ou entregando a decisão às listas por processo, ou alguma mistura disso; os logs que tenho registram o status que a aplicação devolveu, não qual caminho o decidiu, então não conseguem separar os caminhos.¹⁷³ O remédio é o mesmo para todos, e não é uma mudança de uma linha: um armazenamento de contadores com incremento atômico, algo que uma leitura do KV seguida de uma gravação separada não oferece. O vazamento é um bug meu. Ele também deixa o argumento deste post mais afiado do que eu conseguiria de propósito: um controle que diz cinco e deixa passar dezoito nunca ia ser o que decide quem pode me escrever.

No site do estúdio, o limitador da aplicação não recusou nenhum dos envios observados, e o endereço mais ativo enviou 13 em uma hora. Os contadores dele somam as requisições de um endereço a todos os outros caminhos sob a mesma classificação de cliente, e meus dados cobrem só os envios do formulário, então as contagens não medem quanta folga esses contadores tinham.⁷²⁵

Um limitador de taxa consegue distinguir cinco de seis quando as requisições se revezam; ele não consegue distinguir uma pessoa de um script em contagem nenhuma.

Honeypot

O que verifica. O formulário do site do estúdio tem um campo de texto chamado website que uma pessoa nunca vê: ele tem tabindex="-1" e aria-hidden, então nem o teclado nem um leitor de tela chegam a ele. Se ele volta com qualquer coisa escrita, o handler responde com a mesma mensagem de sucesso que uma pessoa veria e não grava nem envia nada.²⁵ Esse ramo está no handler desde que construí o formulário, em 5 de junho.²⁵ O formulário deste site não tem honeypot.²⁴

Ned Batchelder descreveu a técnica em 2007: “These fields are called honeypots and are validated when the form data is posted. If they contain any text, then the submitter must be a bot” (esses campos se chamam honeypots e são validados quando os dados do formulário são enviados; se contiverem qualquer texto, quem enviou deve ser um bot).⁴⁹ A razão que ele dá para funcionar é que os bots que preenchem formulários “cannot distinguish invisible fields from visible ones.” (não conseguem distinguir campos invisíveis de visíveis).⁴⁹

O que barrou. 42 dos 52 envios nos oito dias, 80,8%, incluindo todo envio vindo de uma saída do Tor, pela hora em que chegaram, e, pela hora e pelo padrão da mensagem, todos os 13 de uma rajada de um autodenominado SQL spider.⁷²⁰

Por que o resto passou. Um bot que preenche só os campos visíveis nunca toca em website, e os remetentes cujos envios foram gravados, e portanto podiam chegar à minha caixa, o deixaram vazio.⁸²⁵ Que eles tenham escolhido os campos visíveis de propósito é minha leitura; o handler registra só que o campo oculto voltou vazio. Batchelder previu isso: “In theory, it is possible for a spambot to defeat any of these measures. But in practice, bots are very stupid” (em teoria, um spambot pode derrotar qualquer uma dessas medidas; mas na prática os bots são muito burros).⁴⁹ Alguns são menos burros que outros, e os que vendem geração de leads são os menos burros de todos.

Um honeypot só prova que o cliente preencheu um campo que uma pessoa não consegue ver; um vazio não prova nada.

Até onde cada fluxo chegou: os envios dos dois scanners neste site e oito dias do gotejamento no site do estúdio.¹²⁷⁸

O que as cinco tinham em comum

Leia as cinco frases juntas e a lacuna fica clara. Limites de taxa limitam o volume por endereço. Um token CSRF prova que um cliente tinha um token emitido pelo site. Um honeypot prova que o cliente preencheu um campo oculto. As regras da edge conhecem nomes e listas, e a que poderia perguntar se há uma pessoa do outro lado, o desafio por user agent, só pergunta às requisições cuja string de user agent está na lista dela; o desafio por pontuação de ameaça ao lado dela nunca poderia disparar. Nenhum dos scanners casou, então nada fez essa pergunta a cada envio, e os scanners não fizeram nada que um navegador não possa fazer: baixaram a página, guardaram o token dela e enviaram em um ritmo que os limites deixaram passar em parte. O guia da OWASP contra credential stuffing faz a mesma observação sobre outro formulário, aconselhando defesas que “not rely on a single predictable volume limit” (não dependam de um único limite de volume previsível).⁵⁰

5. O gotejamento lento no site do estúdio

O formulário do site do estúdio nunca teve uma enxurrada. Teve um gotejamento, e o gotejamento é outro bicho. A janela aqui vai da primeira hora com um envio do formulário na consulta de oito dias, 17:00 UTC de 26 de outubro, até o momento em que salvei os dados, 13:59:50 UTC de 3 de novembro; o primeiro e o último dia são parciais.⁷

Envios contra linhas gravadas

O formulário recebeu 52 POSTs nessa janela e respondeu a todos com 200. A tabela de mensagens ganhou 10 linhas na mesma janela. Como o ramo do honeypot é o único caminho do handler que responde 200 e não grava nada, o honeypot pegou os outros 42, ou 80,8%.⁷⁸²⁵ Por dia UTC:⁷⁸

O pico de 30 de outubro é um endereço na Grã-Bretanha que enviou 13 vezes em uma única hora com o user agent Mozilla/5.0 (compatible; SQLSpider/1.5). Pela hora e pelo padrão da mensagem, a tabela não gravou nenhum deles: a única linha gravada naquela hora é uma oferta de geração de leads, o padrão do endereço americano que também enviou naquela hora.⁷⁸²⁰

Quem estava enviando

A Cloudflare marca as requisições da rede Tor com um código de país especial, T1. A referência de cabeçalhos dela diz “T1 - Used for clients using the Tor network” (T1: usado para clientes que usam a rede Tor), e a página de regras de IP Access diz “T1: Tor exit nodes (country name: Tor)” (T1: nós de saída do Tor, com Tor como nome do país).⁵¹⁵² Por esse código, 23 dos 52 envios vieram do Tor, 44,2%, e 23 dos 35 endereços distintos eram saídas do Tor, 65,7%.⁷ Como verificação cruzada, comparei cada endereço que enviou o formulário com a lista em massa de saídas do Tor Project, que o projeto chama de “a nearly real time authoritative source for Tor exits that allow contacting your server on port 80” (uma fonte autorizada, quase em tempo real, das saídas do Tor que permitem contatar seu servidor na porta 80). Todos os 23 endereços que a Cloudflare codificou como T1 estavam na lista que baixei em 3 de novembro, e nenhum dos outros 12 estava.⁵³⁵⁴ As duas fontes concordam. Essa lista é a das saídas de 3 de novembro, porém, então confirma o código para aquele dia e não prova quais endereços eram saídas no dia em que cada envio chegou. O arquivo CollecTor do projeto guarda listas de saídas antigas e resolveria a pertinência no dia do evento; não o consultei.⁵⁵

A maioria dos endereços nessa janela enviou uma única vez: 32 dos 35, 91,4%, e todas as saídas do Tor entre eles.⁷ Os três que enviaram mais de uma vez foram o SQL spider com 13, um endereço na Polônia com dois em uma hora e um endereço nos Estados Unidos com cinco. Os cinco envios deste último caem nas mesmas cinco horas que as cinco ofertas de geração de leads que a tabela gravou na janela, e ele mudou de user agent a cada vez: Chrome 135 no Linux, depois Firefox 128, 137, 138 e 137 de novo.⁷²⁰

Os user agents se dividiram pela mesma linha. Dos envios do Tor, 18 citavam um aparelho Android e 5 um Chrome de desktop, e 21 dos 23 citavam Chrome 81 ou anterior. Os envios fora do Tor citavam navegadores de desktop muito mais novos, 10 Chrome de desktop do 125 ao 135 e 6 Firefox do 128 ao 138, mais os 13 do spider com o próprio nome.⁷

Quem foi gravado

As duas metades se encontraram no honeypot. Nenhuma linha gravada na janela cai em uma hora que só teve envios do Tor, e todas as 10 caem em uma hora com um envio de fora do Tor. 22 dos 23 envios do Tor caíram em horas sem nenhuma linha gravada, e o 23º divide a hora com o endereço americano de geração de leads.²⁰ Fiz a correspondência por hora porque os logs de requisições e a tabela de mensagens não compartilham nenhum ID de requisição, então a correspondência é uma inferência: pela hora em que chegaram, todo envio do Tor na janela caiu no honeypot.²⁰ O que foi gravado, e portanto podia chegar à caixa de entrada, veio de endereços fora do Tor, que enviavam strings de navegador de desktop mais novas e deixavam o honeypot vazio.

Os números batem com o velho padrão do spam em formulários. A taxonomia de Batchelder, de 2007, divide os criadores de spam em “Playback spambots, form-filling spambots, and humans.” (spambots que reproduzem envios, spambots que preenchem formulários e humanos).⁴⁹ O gotejamento do Tor se comporta como os que preenchem formulários, que preenchem todos os campos e caem no honeypot. Os remetentes que passaram se comportam como algo mais próximo de uma pessoa diante de um teclado, ou de um script feito para parecer uma. A OWASP classifica a atividade como OAT-017, Spamming: “Malicious or questionable information addition to public or private content, or messages.” (adição de informação maliciosa ou duvidosa a conteúdo público ou privado, ou a mensagens).⁵⁶ A OWASP também deixa uma coisa de fora: “The mass abuse of broken form-to-email and form-to-SMS functions, to send messages to unintended recipients, is not included in this threat event” (o abuso em massa de funções quebradas de formulário para e-mail e formulário para SMS, para enviar mensagens a destinatários não pretendidos, não está incluído nesta ameaça).⁵⁶ Meus formulários só escrevem para mim, então são o caso incluído, spam endereçado ao dono do site, e não aquele outro.

O gotejamento também derrota o limite de taxa por projeto. O guia da OWASP contra credential stuffing nomeia o efeito de espalhar as requisições por muitos endereços: “This may defeat both IP block-lists and rate limiting, as per IP request volume may remain relatively low” (isso pode derrotar tanto listas de bloqueio de IP quanto limites de taxa, porque o volume por IP pode continuar relativamente baixo).⁵⁰ Um envio por endereço é o volume mais baixo possível.

O que dizem as mensagens gravadas

A tabela de mensagens vai até 6 de junho e tinha 108 linhas quando a li; a mais recente chegou às 07:24 UTC de 3 de novembro.⁸ Separei as linhas por padrão com regras fixas, a primeira correspondência vence:⁵⁷

Alguns deles merecem um olhar mais atento. As nove linhas dos 50 milhões chegaram com um mesmo nome de remetente e nove endereços de remetente diferentes, cada um uma pequena variação da mesma manchete.⁸ A pergunta do preço aparece em 25 idiomas na tabela inteira: africâner, armênio, basco, bielorrusso, bengali, búlgaro, catalão, croata, dinamarquês, inglês, georgiano, grego, húngaro, islandês, indonésio, irlandês, italiano, latim, letão, lituano, luxemburguês, espanhol, vietnamita, galês e zulu. Só em outubro ela veio em nove: armênio, basco, dinamarquês, indonésio, latim, letão, lituano, espanhol e vietnamita.⁵⁷ Duas das identificações de idioma são minhas e apertadas: a frase que li como croata pode ser bósnio, e a que li como indonésio pode ser malaio.⁵⁷ Alguém está passeando um guia de conversação por um formulário de contato, um idioma por vez.

O ritmo é a outra assinatura do gotejamento. Outubro gravou 32 linhas, 1,03 por dia, em 21 dos seus 31 dias, e nunca mais de três em um dia.⁸ Nenhum limite de taxa por endereço dispara com uma por dia.

Quais chegaram à caixa de entrada

O formulário só envia e-mails para a caixa do estúdio desde 21 de setembro, às 17:46:47 UTC. Desde então ele gravou, e portanto enviou, 43 linhas, um limite superior porque a chamada de notificação é de melhor esforço e não verifiquei o horário do deploy; as 65 linhas gravadas antes dessa data nunca foram enviadas por e-mail.²⁵⁸ Toda linha na janela de evidência é spam.⁵⁷

Além do meu próprio teste, uma linha da tabela inteira não é. Em 14 de setembro, um cliente de um dos produtos do estúdio escreveu sobre um erro específico, com voz de gente, e a mensagem ficou na tabela sem ninguém ler.⁵⁷ Quando liguei o formulário ao e-mail uma semana depois, a mensagem do commit dizia o porquê com todas as letras: “a paying customer’s message sat unread in D1 for a week” (a mensagem de um cliente pagante ficou sem leitura no D1 por uma semana).²⁵ Essa mensagem é a razão de o notificador existir, e é a razão pela qual não posso resolver o spam desligando o notificador. Mantenho o remetente anônimo aqui; o ponto é que uma pessoa real está na mesma tabela que o guia de conversação.

6. O que é uma verificação de bots, e o que foi para o ar

O Turnstile, nas palavras da Cloudflare

A Cloudflare chama o Turnstile de sua “smart CAPTCHA alternative” (alternativa inteligente ao CAPTCHA) e diz que ele “can be embedded into any website without sending traffic through Cloudflare and works without showing visitors a CAPTCHA.” (pode ser incorporado a qualquer site sem passar o tráfego pela Cloudflare e funciona sem mostrar um CAPTCHA aos visitantes).²¹ O mecanismo é a parte que responde à minha pergunta. “First, we run a series of small non-interactive JavaScript challenges to gather signals about the visitor or browser environment” (primeiro, executamos uma série de pequenos desafios de JavaScript não interativos para reunir sinais sobre o visitante ou o ambiente do navegador), diz a visão geral, e “These challenges include proof-of-work (computational puzzles), proof-of-space, probing for web APIs, and various other challenges for detecting browser-quirks and human behavior.” (esses desafios incluem prova de trabalho, com quebra-cabeças computacionais, prova de espaço, sondagem de APIs web e vários outros desafios para detectar peculiaridades do navegador e comportamento humano).²¹ Um limite de taxa pergunta quantos. Um token CSRF pergunta se o cliente tem um token emitido pelo site. O Turnstile pergunta que tipo de cliente está do outro lado. Meu desafio por user agent também podia perguntar isso, mas só às requisições cuja string de user agent estava na lista dele, e meu desafio por pontuação de ameaça nunca poderia disparar; a diferença que importa aqui é a de um desafio acionado de forma seletiva contra uma verificação exigida de cada envio.

O widget tem três modos. Uso o gerenciado, que a Cloudflare descreve como um que “Automatically chooses between non-interactive or checkbox challenge based on visitor risk level. No images or text to decipher.” (escolhe automaticamente entre um desafio não interativo ou uma caixa de seleção conforme o nível de risco do visitante; sem imagens nem texto para decifrar).⁵⁸ Em termos simples, o visitante vê uma verificação curta e nada mais, a menos que os sinais peçam mais, e então recebe uma caixa para marcar. O modo invisível esconde até isso, e a Cloudflare o condiciona: um site que o ativa precisa citar o Turnstile Privacy Addendum da Cloudflare na própria política de privacidade.⁵⁸ O Turnstile tem um plano gratuito próprio, de até 20 widgets, com desafios ilimitados, e a Cloudflare diz que ele “can be used independently without requiring other Cloudflare services.” (pode ser usado de forma independente, sem exigir outros serviços da Cloudflare).⁵⁹

A metade do servidor, que é a que conta

O widget sozinho não faz nada por um formulário, e a Cloudflare diz isso nas primeiras linhas do guia do lado do servidor: “You must call the Siteverify API to complete your Turnstile implementation. The client-side widget alone does not protect your forms.” (você precisa chamar a API Siteverify para completar sua implementação do Turnstile; o widget do lado do cliente sozinho não protege seus formulários). E depois, de forma mais direta: “Tokens can be forged. An attacker can submit any string to your form endpoint without completing a challenge.” (tokens podem ser forjados; um atacante pode enviar qualquer string ao endpoint do seu formulário sem completar um desafio).⁶⁰ O servidor envia o token para https://challenges.cloudflare.com/turnstile/v0/siteverify com sua chave secreta, e pode incluir o endereço IP do visitante como remoteip.⁶⁰

Duas propriedades do token moldam o código em volta dele. “Each token is valid for 300 seconds (5 minutes) after generation.” (cada token vale por 300 segundos, 5 minutos, depois de gerado). E “Tokens are single-use. Each token can only be validated once. A replayed token will be rejected with the timeout-or-duplicate error code.” (os tokens são de uso único; cada token só pode ser validado uma vez, e um token reutilizado será recusado com o código de erro timeout-or-duplicate).⁶⁰ Um scanner que tivesse colhido um token não poderia enviar o formulário 1.065 vezes com ele. A Cloudflare também limita o token a 2.048 caracteres e manda o servidor “Validate the action and hostname when specified.” (validar a ação e o hostname quando especificados).⁶⁰ Um alerta da mesma página: ela nomeia timeout-or-duplicate para um token expirado em um lugar e descreve invalid-input-response como “Token is invalid, malformed, or expired” (o token é inválido, malformado ou expirado) na tabela de erros, então um servidor deveria tratar qualquer falha como recusa em vez de basear sua lógica em um único código.⁶⁰

O que ele processa, nas palavras da Cloudflare

A Cloudflare não afirma que o Turnstile não usa dados pessoais, e eu também não vou afirmar. O adendo de privacidade do Turnstile nomeia os sinais: “Cloudflare Turnstile processes a variety of client-side signals (“Signals”) such as client IP address, TLS Fingerprint, User-Agent Header and Sitekey and associated origin.” (o Turnstile processa diversos sinais do lado do cliente, como o endereço IP do cliente, a impressão digital TLS, o cabeçalho User-Agent e a sitekey com a origem associada). Declara o propósito: “The purpose of collecting these Signals is not to identify, profile or target any individuals but solely to detect and block bots.” (o propósito de coletar esses sinais não é identificar, perfilar nem direcionar nenhuma pessoa, mas apenas detectar e bloquear bots). E diz que a Cloudflare também os usa para melhorar o produto: “Cloudflare is a data controller of Signals that we process to improve Turnstile’s bot detection capabilities.” (a Cloudflare é controladora dos sinais que processa para melhorar a detecção de bots do Turnstile).²² O que a Cloudflare diz, sim, deixar em paz é o conteúdo: “Turnstile does not access, store, or transmit user communications, form entries, or other page inputs.” (o Turnstile não acessa, armazena nem transmite comunicações do usuário, o que é digitado nos formulários nem outras entradas da página).²¹ A página de marketing acrescenta que “Turnstile never harvests data for ad retargeting.” (o Turnstile nunca coleta dados para retargeting de anúncios).⁶¹ Minha leitura: o Turnstile vê o mesmo tipo de dado de conexão que minha edge já registra para cada requisição, e nunca vê o que uma pessoa digita no meu formulário.

A CSP de que ele precisa

O Turnstile carrega a partir da origem de desafios da Cloudflare, e uma Content Security Policy precisa permitir isso. A Cloudflare lista duas diretivas: “script-src: https://challenges.cloudflare.com” e “frame-src: https://challenges.cloudflare.com”.⁶² Minhas duas zonas definem a política em uma regra de cabeçalhos de resposta da Cloudflare. Neste site, a lista de frames já existia e ganhou a origem de desafios. O site do estúdio não tinha nenhum frame-src, então o default-src 'self' dele teria bloqueado o iframe do widget; ele ganhou frame-src 'self' mais a origem de desafios, e a política da própria aplicação no código ganhou o mesmo.¹²

Por que não um desafio gerenciado no próprio POST do formulário

O atalho óbvio já estava na minha zona: uma regra personalizada que responde a um POST para o formulário com um desafio gerenciado. Minhas regras atuais fazem isso para curl e seus parentes, e funciona, porque nenhuma pessoa usa curl para me mandar uma mensagem.⁹³⁹ Estender isso a todo POST teria quebrado o formulário para todo mundo. A Cloudflare documenta a limitação diretamente: “Challenge Pages interrupt the request flow by returning a full HTML page for the user’s browser to render and solve. This mechanism fails when the browser expects a non-HTML response, such as an AJAX or XHR (fetch) request.” (as páginas de desafio interrompem o fluxo da requisição devolvendo uma página HTML completa para o navegador renderizar e resolver; esse mecanismo falha quando o navegador espera uma resposta que não é HTML, como uma requisição AJAX ou XHR).⁶³ O formulário de contato deste site é um formulário HTMX, que envia com hx-post e troca a resposta dentro da página, então o POST dele é exatamente esse tipo de requisição; a documentação não cita o HTMX pelo nome, e a ligação é minha leitura.²⁴ Um POST desafiado voltaria como uma página de desafio em HTML, que a Cloudflare marca com um cabeçalho cf-mitigated “set to challenge” (com o valor challenge), e “Regardless of the requested resource-type, the content-type of a challenge will be text/html.” (seja qual for o tipo de recurso pedido, o content-type de um desafio será text/html).⁶⁴ O formulário trocaria uma página de desafio dentro da caixa de resposta, ou nada.

A resposta da própria Cloudflare para esse caso é outro recurso: “To ensure your API calls are protected without breaking single-page applications (SPAs) or API integrations, Cloudflare recommends using Turnstile Pre-clearance.” (para proteger suas chamadas de API sem quebrar aplicações de página única nem integrações de API, a Cloudflare recomenda usar o Turnstile Pre-clearance).⁶³ Com a pré-liberação, um widget resolvido também emite um cookie cf_clearance que “enables visitors to bypass WAF Challenges on all subsequent requests on the zone, including API requests, based on the security clearance level set by the customer.” (permite aos visitantes passar pelos desafios do WAF em todas as requisições seguintes na zona, incluindo requisições de API, conforme o nível de liberação definido pelo cliente). O cookie não substitui o token: a Cloudflare diz que ele “is issued to the visitor in addition to the default Turnstile token” (é emitido ao visitante além do token padrão do Turnstile), e a mesma página continua exigindo a verificação do servidor: “You must call Siteverify to complete your Turnstile configuration.” (você precisa chamar o Siteverify para completar sua configuração do Turnstile).⁶⁵ O que a pré-liberação acrescenta é um desafio na edge ao qual um POST via XHR consegue sobreviver, para um visitante cujo cookie tem uma liberação válida no nível do desafio ou acima. Eu usei o padrão: um widget no formulário e um token verificado pelo meu próprio servidor.

O que foi para o ar em 3 de novembro

Nos dois sites criei um widget em modo gerenciado pela API da Cloudflare, restrito ao domínio do próprio site. O segredo de cada widget foi da resposta da API para o chaveiro do meu Mac e para as variáveis do serviço de hospedagem no mesmo processo, e nunca para uma linha de comando nem para um arquivo.¹²

Este site. Um novo verificador envia o token ao siteverify com o endereço do visitante. Um token ausente, um token com mais de 2.048 caracteres, um token recusado ou uma falha de transporte devolvem false, então o formulário falha fechado sempre que o segredo está configurado; sem segredo, como no desenvolvimento local e na suíte de testes, o formulário funciona como antes.¹² Um token que a Cloudflare aceita também precisa ter sido servido em um dos hostnames deste site, e quando a Cloudflare devolve a ação do widget, ela precisa ser a do próprio formulário, como aconselha o guia do lado do servidor; uma resposta sem hostname é uma recusa. Assim, um token válido gerado em outro site, ou por outro widget, não passa. Essa verificação entrou como uma segunda mudança na mesma manhã, com build a partir das 07:20 PST; às 07:25 PST, depois de limpar o cache, um envio com um token CSRF válido da página no ar e sem token do Turnstile voltou com 403 de novo. Isso prova que o formulário continua falhando fechado depois do deploy; um envio sem token não consegue exercitar a verificação de hostname em si, que se apoia no código e nos testes.⁶⁶⁶⁰ Até uma terceira mudança, os dois widgets e os dois verificadores também admitiam localhost, e como uma sitekey é pública, um token gerado com a minha no localhost de qualquer pessoa teria passado tanto pelo siteverify quanto pela verificação de hostname. A página de testes da Cloudflare desaconselha isso: “Cloudflare recommends that sitekeys used in production do not allow local domains” (a Cloudflare recomenda que sitekeys usadas em produção não permitam domínios locais), e cita localhost entre eles. Às 08:12 PST tirei localhost dos dois widgets, e os dois verificadores agora admitem por padrão só o site e o host www dele, então a verificação aceita os hostnames deste site e nada mais; o desenvolvimento local nomeia seus hostnames em uma configuração. Depois dessa mudança, os dois sites passaram de novo nas mesmas verificações no ar, às 08:15 e às 08:18, horário do Pacífico: o widget na página e um envio sem token recusado com 403. Nenhuma verificação no ar consegue exercitar a regra de hostname em si, porque um token ausente ou lixo falha antes de o hostname ser lido; essa regra se apoia na configuração do widget, no código e nos testes.⁴⁶⁶⁷ A ordem das verificações no handler agora é CSRF, depois Turnstile, depois o envio, atrás do mesmo limitador por endereço de antes. As duas recusas devolvem o próprio fragmento de erro da página com um 403, e o HTMX não troca uma resposta 4xx dentro da página por padrão, então o formulário precisa de um handler que deixe passar um 403. Minha primeira versão desse handler não funcionou. Eu a anexei ao formulário, mas o HTMX dispara o evento no elemento que recebe a resposta, e nesta página esse elemento é o irmão do formulário, então o evento nunca chegava ao handler e uma pessoa recusada continuava sem ver nada. Uma segunda revisão do rascunho deste post pegou isso lendo o HTMX empacotado contra o template. A correção, uma quarta mudança naquela manhã, põe o listener no body da página, restrito à caixa de resposta, e um teste verifica que ele é renderizado. Às 08:21 PST, depois desse deploy, rodei o formulário no Chromium do Playwright com o token do widget trocado por uma string lixo: a caixa de resposta mostrou “error: Verification failed. Reload the page and try again.” (erro: a verificação falhou; recarregue a página e tente de novo), e nada foi enviado, porque o siteverify recusa um token lixo antes de o handler chegar ao envio.⁶⁸ A antiga recusa CSRF, o 403 em JSON que o HTMX nunca mostrava, não existe mais. O formulário reinicia o próprio widget depois de cada requisição HTMX, nomeando o contêiner do widget do jeito que a chamada de reinício da Cloudflare o recebe, então uma nova tentativa leva um token novo, porque cada token é de uso único e vive 300 segundos.¹²⁶⁰⁶⁹ O guia do lado do cliente da Cloudflare dá a razão e a chamada: “To reset the widget if the given widget timed out or expired, you can use the function:” (para reiniciar o widget se ele excedeu o tempo ou expirou, você pode usar a função:) turnstile.reset(widgetId);.⁶⁹ Minha primeira versão chamava o reinício sem argumento, o que o guia não documenta; uma quarta rodada de revisão pegou isso, a chamada agora nomeia o contêiner nos dois sites, e uma verificação no navegador em 3 de novembro enviou um token lixo em cada formulário, viu a recusa e depois encontrou um token novo no campo oculto: em até oito segundos no site do estúdio, em até vinte e cinco neste, onde o widget refez o desafio primeiro.¹² A div do widget e o script só são renderizados quando a chave do site está configurada. Onze testes passam: sem segredo, envia como antes; com segredo, o handler recusa um token ausente antes de qualquer envio e recusa um token recusado, um token aceito envia, e o CSRF continua rodando primeiro; e o verificador aceita o hostname deste site e recusa outro hostname, localhost por padrão, outra ação ou nenhuma.¹²⁶⁶⁴⁶

O site do estúdio. O honeypot continua na frente. Um campo oculto preenchido continua recebendo a mensagem de sucesso e nada é gravado, então os bots mais baratos nunca custam uma chamada à Cloudflare. Depois vem o Turnstile, e um token ausente, recusado ou impossível de verificar recebe um 403 com o fragmento de erro. Depois a validação, a inserção na tabela de mensagens e a notificação.¹² O verificador dele confere o hostname (agora só os dois hostnames do próprio site) e a ação da mesma forma; essa mudança foi para o ar às 07:19 PST, e às 07:22 PST a página no ar tinha o widget e a chave do site, um envio sem token e um envio com token lixo voltaram com 403, e um envio ao honeypot continuou respondendo 200.⁶⁶ Antes do deploy, rodei o handler localmente com as chaves de teste documentadas da Cloudflare. Com o segredo que sempre aprova, um envio sem token voltou com 403 e o token fictício passou pelo Turnstile e chegou à validação; com o segredo que sempre recusa, os dois voltaram com 403; o honeypot respondeu 200.¹²⁶⁷ A página de testes da Cloudflare diz por que um token fictício não pode passar em produção: “Production secret keys: Only accept real tokens, reject dummy tokens.” (chaves secretas de produção só aceitam tokens reais e recusam os fictícios).⁶⁷

A verificação no ar. Mais cedo naquela manhã, depois que o deploy de cada site deu certo e de uma limpeza de cache, às 06:35 PST, cada página inicial tinha uma div do widget, uma tag de script do Turnstile e a chave do site, e a política no ar de cada zona listava a origem de desafios em frame-src. Um envio ao formulário deste site com um token CSRF lixo voltou com 403, mas isso é a verificação CSRF recusando, e não prova nada sobre o Turnstile. A verificação do Turnstile em si eu testei às 06:43 PST: um envio com um token CSRF válido tirado da página no ar e sem token do Turnstile voltou com 403 e a mensagem “error: Verification failed. Reload the page and try again.”, e o mesmo envio com um token do Turnstile lixo também voltou com 403. Então o segredo está no serviço e a verificação roda depois do CSRF. No site do estúdio, um envio sem token e um envio com token lixo voltaram com 403, e um envio ao honeypot voltou com 200 sem gravar nem enviar nada.⁷⁰

A verificação no navegador. Em um Chromium de verdade controlado pelo Playwright, o widget foi renderizado nas duas páginas, o script do Turnstile carregou e o campo oculto cf-turnstile-response tinha um token de 730 caracteres nas duas páginas em até seis segundos.⁷⁰ Isso prova menos do que parece. A página de testes da Cloudflare avisa que “Automated testing suites (like Selenium, Cypress, or Playwright) are detected as bots by Turnstile” (o Turnstile detecta como bots as suítes de testes automatizados, como Selenium, Cypress ou Playwright), e só o siteverify decide se um token passa.⁶⁷ O que a verificação prova é que o widget roda sob as duas políticas e preenche seu campo. O que não fiz é o teste que mais importa para quem lê este post: uma pessoa preenchendo o formulário e recebendo uma resposta. Esse teste envia um e-mail, então cabe a mim fazê-lo, e ainda não o fiz.

7. Para que o limite de taxa ainda serve

O Turnstile substituiu os limites de taxa como portão. Não os substituiu como cerca. Uma verificação de bots responde quem; alguma coisa ainda precisa responder quantos, porque cada envio que chega à verificação com um token não vazio de tamanho válido agora custa uma chamada à API siteverify da Cloudflare, e cada envio que passa ainda custa um envio de e-mail.¹² O próprio guia do lado do servidor da Cloudflare lista o limite de taxa entre suas recomendações para a chamada ao siteverify em si: “Rate limit to protect against validation flooding.” (aplique limite de taxa para se proteger contra enxurradas de validação).⁶⁰ Meus dois limites ficam: a regra da edge de 3 envios a cada 10 segundos por endereço por data center, e o limitador da aplicação de cinco envios por minuto por endereço.⁹¹⁷

A regra da edge merece uma descrição honesta agora que sei como ela conta. A Cloudflare expõe o projeto sem rodeios: “Cloudflare tracks request rates by maintaining separate counters for each unique combination of values in a rule’s characteristics” (a Cloudflare acompanha as taxas de requisição mantendo contadores separados para cada combinação única de valores das características de uma regra), e “Cloudflare does not support global rate limiting counters across the entire network.” (a Cloudflare não oferece contadores globais de limite de taxa na rede inteira).⁶ Um endereço que chega à minha zona por dois data centers recebe duas cotas, e os envios do scanner de 2 de novembro de fato chegaram por dois; essa é minha explicação mais forte para a regra ter ficado em silêncio, coerente com os totais por minuto mas não provada por eles.⁵ Some o alerta de precisão da Cloudflare, de que as regras “are not designed to allow a precise number of requests to reach your origin server” (não foram projetadas para deixar chegar um número preciso de requisições ao servidor de origem), e a melhor descrição da regra é um orçamento nominal, não um teto comprovado: 3 envios do formulário a cada 10 segundos por endereço por data center, o equivalente nominal de 18 por minuto, aplicado de forma aproximada.⁴⁸⁹ No plano Free ela é também a única regra de limite de taxa que tenho, com um período fixo de 10 segundos e contagem só por IP.⁴⁸

Um detalhe do plano Free importa se você ficou tentado, como eu fiquei, a fazer do próprio limite de taxa o desafio. A página de parâmetros da Cloudflare diz que nos planos Free, Pro e Business uma regra de limite de taxa com ação de desafio sempre faz throttling em vez de manter uma duração, e que “When visitors pass a challenge, their corresponding request counter is set to zero.” (quando os visitantes passam por um desafio, o contador de requisições deles é zerado).⁷¹ Um desafio no POST via XHR do formulário também falharia pelo motivo da seção 6.⁶³ Então a regra da edge continua sendo um bloqueio, e o desafio mora no widget.

O limitador da aplicação precisa da correção que o vazamento dele pede: um armazenamento de contadores com incremento atômico, para que dois envios não possam ler a mesma contagem, e um caminho de falha que não divida a contagem entre processos. O código atual, uma leitura do KV seguida de uma gravação separada com um fallback por processo, não oferece nenhuma das duas coisas, então isso é uma troca de armazenamento e não um patch de uma linha.¹⁷³ Com o Turnstile como condição adicional para cada envio que poderia chegar à caixa de entrada, um envio que o vazamento deixe passar ainda precisa carregar um token que a Cloudflare aceite, então o vazamento custa volume e dinheiro, e a decisão sobre quem pode enviar não depende mais da contagem. Um limitador é um orçamento. Um orçamento que erra por 47 em uma enxurrada é um orçamento ruim, mas nunca foi um guarda.

O guia de autenticação da OWASP coloca a mesma estratificação nos próprios termos. Ele trata um CAPTCHA “as a defense-in-depth control to make brute-force attacks more time-consuming and expensive, rather than as a preventative.” (como um controle de defesa em profundidade para tornar ataques de força bruta mais demorados e caros, e não como medida preventiva).⁷² E o guia contra credential stuffing observa que “Most tools used for these types of attacks will make direct POST requests to the server and read the responses, but will not download or execute JavaScript” (a maioria das ferramentas usadas nesses ataques faz requisições POST diretas ao servidor e lê as respostas, mas não baixa nem executa JavaScript).⁵⁰ Meus dois scanners de fato baixaram as páginas do site, o caminho mais provável pelo qual chegaram a ter tokens CSRF válidos. Um cliente que envia o formulário sem rodar o widget não tem token do Turnstile para enviar, e os dois formulários agora recusam um envio sem ele: neste site, um envio com um token CSRF válido e sem token do Turnstile voltou com 403, e o mesmo aconteceu com um envio sem token no site do estúdio.⁷⁰

O checklist

Para um formulário de contato atrás da Cloudflare, na ordem em que eu faria hoje:

1. Coloque uma verificação de bots no formulário e verifique cada token no servidor. Nas palavras da própria Cloudflare: “The client-side widget alone does not protect your forms.” (o widget do lado do cliente sozinho não protege seus formulários).⁶⁰ Confira também o hostname e a ação na resposta, como a mesma página aconselha, para que um token gerado em outro lugar não passe, e deixe os domínios locais fora da sitekey de produção, porque “Cloudflare recommends that sitekeys used in production do not allow local domains”.⁶⁰⁶⁶⁶⁷
2. Falhe fechado. Um token ausente, grande demais, recusado ou impossível de verificar é uma recusa, porque “Tokens can be forged.” (tokens podem ser forjados).⁶⁰¹²
3. Reinicie o widget depois de cada envio. Os tokens são de uso único e valem por 300 segundos, então uma nova tentativa sem reinício é uma nova tentativa com um token gasto.⁶⁰⁶⁹
4. Libere a origem de desafios nas duas diretivas da CSP. A Cloudflare pede script-src e frame-src para https://challenges.cloudflare.com, e uma política só com default-src 'self' bloqueia o iframe.⁶²¹²
5. Não coloque um desafio gerenciado em um formulário que envia via XHR ou fetch. A Cloudflare diz que a página de desafio “fails when the browser expects a non-HTML response” (falha quando o navegador espera uma resposta que não é HTML), e um envio HTMX é esse tipo de requisição.⁶³
6. Devolva um erro que uma pessoa consiga ver. Minha recusa CSRF era um 403 em JSON que o formulário HTMX nunca exibia, então uma pessoa com um token expirado teria clicado em Enviar e não teria visto nada, e minha primeira correção escutava no formulário enquanto o HTMX dispara o evento de troca no alvo da resposta, o irmão do formulário; então teste a recusa em um navegador.¹²⁶⁸
7. Mantenha o honeypot na frente da verificação de bots. Ele pegou 42 de 52 envios no site do meu estúdio ao custo de um campo oculto e um if.⁷²⁵
8. Mantenha o limite de taxa, e dimensione-o como teto de custo, não como portão. A Cloudflare conta por endereço e por data center, e o scanner de 2 de novembro chegou por dois, o motivo mais provável de a regra nunca ter disparado, embora os totais por minuto não possam prová-lo.⁶⁵
9. Apoie o limitador da aplicação em um armazenamento que incremente de forma atômica. O meu lia a contagem e a gravava de volta em uma requisição separada, voltava a contagem para um quando a segunda leitura falhava, recorria à memória de um único processo quando o KV falhava, e deixou passar 47 e 9 envios acima do próprio teto; os logs não dizem qual caminho vazou.¹⁷³
10. Não confie em uma regra de user agent para barrar um scanner. Os dois scanners enviaram uma string comum do Chrome, pelo menos 69.322 vezes em 30 de outubro e 9.725 vezes em 2 de novembro.³²⁴¹
11. Conte os e-mails no provedor de e-mail, não no formulário. Meu handler responde 200 nos caminhos de falha, e o evento email.sent do Resend só significa que “the API request was successful” (a requisição à API deu certo); o campo last_event de um e-mail consultado diz o que aconteceu depois.²⁴²⁸⁷³
12. Consulte as análises dentro de um mês. Os conjuntos de dados adaptativos da Cloudflare guardam “at least 31 days of data on every plan” (pelo menos 31 dias de dados em todos os planos).²⁷
13. Conte de novo depois que a janela fechar. Minhas anotações escritas minutos depois da enxurrada de 30 de outubro contaram a menos os envios do formulário, porque a Cloudflare ainda não tinha terminado de ingerir os últimos minutos.¹⁶
14. Trate um bloqueio de endereço como limpeza. O meu veio cerca de 50 minutos depois do primeiro envio do formulário em 30 de outubro e 8 minutos depois do início da varredura em 2 de novembro, e nenhum envio de nenhum dos dois dias veio depois do minuto do bloqueio: 101 antes dele em 30 de outubro, e 26 antes e 5 dentro dele em 2 de novembro.¹¹⁹²

O que poderia mudar

São condições, não previsões. Cada uma diz o que teria de acontecer e o que eu faria a respeito.

Se um scanner começar a passar pelos desafios gerenciados. As verificações do Turnstile rodam no navegador e procuram automação; uma ferramenta que rode um navegador completo bem o bastante para passar por elas, em volume, transformaria o widget em mais um custo para ela, e não em um muro. O sinal seriam envios do formulário com tokens que o siteverify aceita, vindos de endereços que também enviam strings de injeção no cabeçalho User-Agent. Batchelder escreveu a versão honesta disso para os honeypots em 2007: “If and when they do, we can switch back to CAPTCHAs.” (se e quando fizerem isso, podemos voltar aos CAPTCHAs).⁴⁹ Meu plano B seria o mesmo em espírito, um desafio mais forte, e enquanto isso o honeypot e os limites de taxa continuam de pé.

Se eu adicionar uma verificação na edge com pré-liberação. A Cloudflare recomenda a pré-liberação do Turnstile para requisições que não conseguem renderizar uma página de desafio, e um cookie cf_clearance permite que um visitante “bypass WAF Challenges on all subsequent requests on the zone, including API requests” (passe pelos desafios do WAF em todas as requisições seguintes na zona, incluindo requisições de API).⁶⁵⁶³ Se eu adotar isso, a edge poderia desafiar o próprio POST do formulário sem quebrar o HTMX para um visitante cujo cookie tenha uma liberação válida no nível do desafio ou acima, e a página de CSP da Cloudflare acrescenta um requisito para esse modo: “your connect-src directive must include ‘self’.” (sua diretiva connect-src precisa incluir ‘self’).⁶² O cookie vem “in addition to the default Turnstile token” (além do token padrão do Turnstile), e o siteverify continua obrigatório, então o desafio na edge seria uma segunda verificação na frente da do meu servidor, não uma substituta.⁶⁵ Não fiz isso, e o post descreve o desenho de widget e siteverify que está no ar.

Se eu exportar o log do Resend para as duas janelas. Toda contagem de e-mails deste post é um teto, porque um 200 do formulário é um envio, ou uma falha à qual meu handler também responde com 200.²⁴ O endpoint de consulta do Resend devolve um last_event para cada e-mail, como delivered, e a lista de eventos dele distingue “sent - The email was sent successfully.” (enviado: o e-mail foi enviado com sucesso) de “delivered - Resend successfully delivered the email to the recipient’s mail server.” (entregue: o Resend entregou o e-mail ao servidor de e-mail do destinatário).⁷³⁷⁴ Com essa exportação, 101 e 31 virariam contagens exatas, e só poderiam diminuir.

Se uma pessoa enviar o spam à mão. O Turnstile pergunta se há um navegador e, às vezes, uma pessoa. Não pergunta por quê. Uma pessoa paga para colar uma oferta em formulários de contato consegue passar, assim como os remetentes de geração de leads do site do meu estúdio, se houver uma pessoa por trás deles. Para esse caso, as defesas são as antigas: um limite de taxa para o volume e meu próprio julgamento na caixa de entrada.

Se o gotejamento do Tor precisar de uma resposta dia a dia. A lista de saídas que conferi é a que baixei em 3 de novembro, e o serviço CollecTor do Tor Project guarda listas antigas.⁵³⁵⁵ Se eu consultá-lo para os oito dias, a atribuição ao Tor passaria a se apoiar nas listas dos dias em que os envios chegaram, e não no código da Cloudflare mais a lista de 3 de novembro. A Cloudflare também oferece Onion Routing em todos os planos, que atende usuários do Tor diretamente pela rede Tor; a Cloudflare diz que com ele “Human Tor users and bots can be distinguished by our Onion services, such that interactive challenges are only served to malicious bot traffic.” (nossos serviços Onion conseguem distinguir usuários humanos do Tor de bots, de modo que desafios interativos só são servidos ao tráfego de bots maliciosos).⁷⁵ Não o ativei, e eu ia querer medir o tráfego do Tor no site do estúdio depois do Turnstile antes de fazer isso.

Principais conclusões

Se você mantém um formulário de contato:

• Um token CSRF e um limite de taxa juntos ainda deixam um scanner escrever para você. Meus dois scanners tinham tokens válidos, e meu limitador deixou passar 101 e 31 envios.¹²
• Verifique no servidor o token de uma verificação de bots, falhe fechado e reinicie o widget depois de cada requisição; o widget sozinho “does not protect your forms.” (não protege seus formulários).⁶⁰
• Teste seu limitador sob carga e sob falha, não uma requisição de cada vez. Um contador de ler e depois gravar com fallback por processo deixou passar 18 envios em um minuto configurado para permitir cinco.¹¹⁷
• Mantenha o honeypot. É o filtro mais barato da pilha, e ele pegou 80,8% desses envios no site do meu estúdio, em oito dias, antes de o handler checar um endereço, gravar uma linha ou enviar um e-mail.⁷²⁵

Se você cuida da edge do site:

• Saiba o que seu limite de taxa conta. Na Cloudflare toda regra conta por data center, e um scanner que chega por dois recebe dois contadores.⁶⁵
• Teste suas próprias regras e leia os eventos de firewall depois. Onze eventos de firewall do meu teste me disseram mais sobre a regra do que um dia raciocinando sobre por que ela tinha ficado em silêncio.¹⁸
• Não desafie um POST via XHR ou fetch com uma página de desafio; a Cloudflare documenta que isso falha e recomenda a pré-liberação para esse caso.⁶³
• Espere que regras de user agent peguem só ferramentas honestas. Os scanners daqui enviaram uma string de navegador; meu teste com curl provocou desafios.³²³⁹

Se é você quem lê a caixa de entrada:

• Quando a caixa encher, confira o remetente antes do assunto. Três dos meus fluxos de e-mail compartilham um endereço de remetente, e por isso meu primeiro palpite estava errado.²³
• Trate os 200 de um formulário como um teto de e-mails, não como uma contagem, até o log do provedor de e-mail dizer outra coisa.²⁴²⁸
• Leia as mensagens gravadas antes de desligar o notificador. A mensagem de um cliente real ficou sem leitura por uma semana uma vez, e essa mensagem é o motivo de o formulário do estúdio me mandar e-mail.²⁵

Perguntas frequentes

Por que meu formulário de contato recebe spam mesmo com a Cloudflare?

O mais provável é que nada na frente do formulário pergunte a cada envio se foi uma pessoa que o mandou. As regras personalizadas da Cloudflare comparam endereços, redes, caminhos e strings de user agent, e os limites de taxa dela contam requisições por endereço por data center; um scanner que envia um user agent de navegador, carrega a página primeiro e envia em ritmo moderado passa por todos eles. No meu site, dois scanners fizeram exatamente isso e emplacaram 101 e 31 envios, e o spam do site do meu estúdio chegou quase sempre a um envio por endereço nos oito dias que medi, algo que nenhuma contagem por endereço consegue pegar.⁹⁶¹²⁷

Um limite de taxa barra bots?

Um limite de taxa limita a velocidade de um endereço; ele não distingue um bot de uma pessoa. A própria documentação da Cloudflare diz que as regras dela “are not designed to allow a precise number of requests to reach your origin server” (não foram projetadas para deixar chegar um número preciso de requisições ao servidor de origem) e que os contadores não são compartilhados entre data centers. Minha regra da edge nunca disparou com nenhum dos dois scanners, e o limitador da minha aplicação, configurado para cinco por minuto, deixou passar 18 em um minuto: o contador dele é uma leitura seguida de uma gravação separada, uma segunda leitura que falha o volta para um, e um fallback por processo assume quando o armazenamento falha; qualquer um desses caminhos pode deixar passar envios a mais.^48641173

Um campo honeypot basta?

Basta para os bots que preenchem o campo oculto, e no site do meu estúdio isso foi 80,8% desses envios: o meu pegou 42 de 52 envios em oito dias, incluindo, pela hora em que chegaram, todo envio de uma saída do Tor. Ele não faz nada contra um remetente que deixa o campo oculto vazio, e os 10 que ele deixou passar, gravados e portanto no máximo 10 e-mails, fizeram exatamente isso.⁷²⁰ Ned Batchelder, ao descrever a técnica em 2007, disse isso mesmo: “In theory, it is possible for a spambot to defeat any of these measures.” (em teoria, um spambot pode derrotar qualquer uma dessas medidas).⁴⁹

Turnstile ou CAPTCHA: qual é a diferença?

Um CAPTCHA clássico pede ao visitante que resolva um quebra-cabeça. O Turnstile executa “a series of small non-interactive JavaScript challenges to gather signals about the visitor or browser environment” (uma série de pequenos desafios de JavaScript não interativos para reunir sinais sobre o visitante ou o ambiente do navegador), e no modo gerenciado só mostra uma caixa de seleção quando o risco do visitante pede, com “No images or text to decipher.” (sem imagens nem texto para decifrar).²¹⁵⁸ A Cloudflare diz que seus desafios não usam “CAPTCHA puzzles or visual tests like selecting objects or typing distorted characters.” (quebra-cabeças CAPTCHA nem testes visuais como selecionar objetos ou digitar caracteres distorcidos).⁷⁶ Os dois ainda precisam que o servidor verifique o resultado; no caso do Turnstile, essa é a chamada ao siteverify.⁶⁰

Por que a proteção CSRF não barra o spam?

Uma defesa CSRF bem implementada serve para impedir que outro site faça o navegador de um visitante enviar o seu formulário. Meu token é mais fraco que isso: ele não tem estado e é assinado, vale por uma hora e não está ligado a uma sessão, a um cookie nem a um endereço, então só prova que o cliente tem um token emitido pelo meu site na última hora, não de onde veio a requisição. Nenhum dos dois tipos barra um cliente que carrega sua página e envia o formulário por conta própria, porque carregar a página é justamente como um cliente obtém um token válido, e os dois scanners juntaram tokens válidos; a verificação recusou quatro dos envios deles nas duas enxurradas.¹⁵¹²

Como distinguir um scanner de uma pessoa nos logs?

Olhe tudo o que o endereço fez, não só o formulário. Meus dois scanners rastrearam milhares de caminhos, puseram strings de injeção de SQL nos caminhos e no cabeçalho User-Agent, enviaram um user agent do Chrome na maioria das requisições e uma alegação de ser Googlebot em algumas que a regra de bots verificados da Cloudflare não aceitou, e enviaram o formulário em rajadas de dezenas a centenas por minuto.^31324441 Payloads baseados em tempo como sleep(15) e waitfor delay '0:0:15' pertencem a famílias de sondas documentadas.³³⁷⁷ Uma pessoa envia uma mensagem, a partir de uma página que de fato leu, e não pede ao seu servidor que durma.

O Turnstile coleta dados pessoais?

A Cloudflare não diz que ele não coleta nenhum. O adendo de privacidade do Turnstile nomeia os sinais que ele processa, “such as client IP address, TLS Fingerprint, User-Agent Header and Sitekey and associated origin” (como o endereço IP do cliente, a impressão digital TLS, o cabeçalho User-Agent e a sitekey com a origem associada), diz que o propósito é “solely to detect and block bots” (apenas detectar e bloquear bots) e diz que a Cloudflare é controladora desses sinais para melhorar a detecção de bots. A visão geral diz que o Turnstile “does not access, store, or transmit user communications, form entries, or other page inputs.” (não acessa, armazena nem transmite comunicações do usuário, o que é digitado nos formulários nem outras entradas da página).²²²¹ Então ele vê dados de conexão, não o que uma pessoa digita.

Relacionados neste site. O modo auto do Claude Code não é uma fronteira de segurança faz o mesmo argumento sobre outro controle: um classificador que julga cada ação não é o muro. Agents.txt não é controle de acesso traça a linha entre declarar uma política aos bots e fazê-la valer. Fadiga de alertas: 82 e-mails em um dia do meu monitor de segurança trata do scanner de 2 de novembro do lado do meu monitor: um bloqueio oito segundos depois do primeiro achado, oito minutos depois do início da varredura, e zero e-mails sobre ele. O que eu rodo antes de dormir é outro tipo de rotina de operações, uma checagem noturna de 15.000 páginas quanto a status, tempo de resposta e cache, e O que realmente quebra quando você roda agentes de IA sem supervisão cataloga os modos de falha das sessões de agentes sem supervisão, o tipo de automação que opera minha infraestrutura.

Fontes

Notas do autor sobre os dados: toda contagem dos meus próprios sistemas vem da GraphQL Analytics API da Cloudflare para as duas zonas (os conjuntos de dados de requisições e de eventos de firewall), da tabela de mensagens do site do estúdio, do log do meu monitor e do código dos dois formulários, tudo salvo em 3 de novembro de 2026 e transformado em um registro por script. Os horários estão em UTC, salvo quando marcados como PDT ou PST. Nenhum endereço, identificador de regra ou de lista, chave ou caminho do sistema de arquivos dessa evidência aparece neste post.