Por qué el spam venció a mi formulario de contacto con límite de tasa

¿Por qué el spam atraviesa un formulario de contacto con límite de tasa? Porque un límite de tasa cuenta solicitudes por dirección y nada en él pregunta quién las envió. El 30 de octubre y el 2 de noviembre, dos escáneres de vulnerabilidades rastrearon mi sitio, cargaron la página de inicio que lleva el formulario, como lo hace cualquier visitante, obtuvieron un token CSRF válido y enviaron el formulario hasta que siguieron su camino o fueron bloqueados. El primer día pasaron 101 envíos y el segundo 31, cada uno un 200 de la aplicación, que lo devuelve tanto para un envío como para uno fallido, así que esas cifras son el máximo de correos que pudieron producir.¹² El limitador de mi aplicación, configurado en cinco envíos por minuto por dirección, rechazó 830 y 31 de sus envíos y dejó pasar 101 y 31, 47 y 9 más de los que habría permitido un limitador exacto con esa configuración.³ El límite de tasa del borde nunca se activó con ninguno de los dos escáneres: lo creé unos 12 minutos después del último envío del formulario de la primera avalancha, y los envíos del segundo escáner llegaron por dos centros de datos de Cloudflare, que llevan contadores separados. Esa división es mi explicación más sólida para el segundo silencio: encaja con los totales por minuto, que no pueden probarla.⁴⁵⁶ En el sitio de mi estudio, un campo honeypot atrapó 42 de 52 envíos en ocho días y dejó pasar los 10 cuyos remitentes dejaron el honeypot vacío.⁷⁸ El borde de este sitio sí tenía una regla capaz de preguntar si hay una persona del otro lado, un desafío gestionado en la ruta del formulario, pero solo se activa ante una cadena de agente de usuario incluida en una lista, y ambos escáneres enviaron la cadena de un navegador; un segundo desafío, basado en una puntuación de amenaza alta, nunca podía activarse, porque Cloudflare ahora fija esa puntuación en cero, así que nada se lo preguntó a cada envío.⁹¹⁰⁴¹¹ Desde la mañana del 3 de noviembre, Turnstile se lo pregunta a cada envío que podría llegar a mi bandeja de entrada, en ambos formularios.¹²

TL;DR

• Dos escáneres, una bandeja de entrada. Una dirección envió a mi sitio 76.429 solicitudes repartidas en 53 intervalos de un minuto el 30 de octubre; otra envió 10.907 en 22 el 2 de noviembre. Ambas rastrearon el sitio completo, ambas enviaron cadenas de inyección SQL en las rutas y en la cabecera User-Agent, y ambas enviaron el formulario de contacto: 1.065 veces el primer día y 500 el segundo.¹³¹⁴¹²
• Un token CSRF válido solo prueba que un cliente tenía un token emitido por mi sitio. Todos los envíos de ambos días llevaban uno, porque mis tokens no tienen estado y cualquier cliente que descarga la página obtiene uno. La verificación CSRF rechazó cuatro envíos en dos avalanchas.¹⁵¹⁶
• Mi propio limitador tenía fugas. Lee un contador de Cloudflare KV, lo compara y luego lo vuelve a leer y escribe el conteo más uno en una solicitud aparte; si esa segunda lectura falla, escribe uno, y si falla una llamada a KV, recurre a un conteo guardado en la memoria de un solo proceso. Cualquiera de esas rutas puede dejar pasar más de cinco, y los logs no pueden decir cuál lo hizo: salieron 18 envíos en un minuto contra un límite de cinco.¹⁷¹
• El límite de tasa del borde cuenta por dirección y por centro de datos. El 2 de noviembre, los 85 envíos del formulario del escáner entre las 18:56 y las 19:05:00 UTC, los minutos a ambos lados del bloqueo, llegaron por Ámsterdam y Londres, 44 y 41, y el minuto de más actividad se repartió 18 a 14 entre ambos. Esa división es la razón más probable por la que la regla guardó silencio, aunque los totales por minuto no pueden probarlo. Una prueba que hice a la mañana siguiente demostró que la regla se activa y que Cloudflare lo registra.⁵¹⁸
• Los bloqueos fueron bloqueos de dirección, y ambos llegaron demasiado tarde para mantener fuera el correo. El 30 de octubre bloqueé la dirección a mano 3,9 minutos después de darme cuenta, unos 50 minutos después de su primer envío del formulario. El 2 de noviembre mi monitor la bloqueó 8 minutos después del primer minuto del escaneo. Ningún envío de ninguno de los dos días llegó después del minuto del bloqueo: el 30 de octubre el último llegó más de 12 minutos antes del bloqueo, y el 2 de noviembre, 26 llegaron en los minutos previos y 5 en el propio minuto del bloqueo, que los datos por minuto no pueden situar antes o después del segundo del bloqueo.¹⁰¹⁹¹²
• El honeypot atrapa a los bots que llenan todos los campos. En el sitio de mi estudio respondió a 42 de 52 envíos como si hubieran tenido éxito y no guardó nada; según la hora en que llegaron, todos los envíos desde una salida de Tor estaban entre ellos. Los 10 que se guardaron, y por tanto como máximo 10 correos, vinieron de remitentes que dejaron el honeypot vacío.⁷²⁰
• Qué cambió. Ambos formularios llevan ahora un widget de Cloudflare Turnstile en modo gestionado, y el servidor no guarda ni envía nada hasta que la API siteverify de Cloudflare acepta el token del envío, y rechaza uno ausente, demasiado largo o imposible de verificar. Turnstile ejecuta desafíos en el navegador del visitante y procesa señales como la dirección IP, la huella TLS y el agente de usuario; Cloudflare dice que no toca lo que se escribe en los formularios. No detiene a una persona que escribe spam a mano y no reemplaza los límites de tasa, que siguen acotando el volumen.¹²²¹²²

1. La pregunta: «¿eres tú?»

El 2 de noviembre mi bandeja de entrada se llenó de mensajes del formulario de contacto, y mi primera pregunta, dirigida a la sesión de agente que opera mi infraestructura, fue si mi propia automatización los estaba enviando. No era así. Los enviaba un escáner, a través del formulario de contacto de este sitio, y el formulario del sitio de mi estudio, 941apps.com, recibía su propio goteo lento, aunque nada de él llegó a la bandeja ese día.²³⁸ Los tres flujos de correo, las alertas de mi monitor y los dos formularios, salen de una misma dirección de mi propio dominio de correo, así que en la bandeja se veían iguales.²³

Los asuntos delataron lo que pasaba. El controlador de contacto de este sitio me envía cada mensaje con el asunto «Contact Form:» seguido de lo que el remitente escribió en los campos de nombre, así que la carga de un escáner se convierte en una línea de asunto.²⁴²³ El formulario del sitio del estudio guarda cada mensaje en una base de datos y luego lo envía por correo a la misma bandeja.²⁵

La primera pregunta que hice era la equivocada, y la correcta me llevó un día de consultas: ¿cuál de los controles de estos formularios podría haber distinguido un escáner de una persona, y por qué cada uno dejó pasar el resto? Había cinco tipos de control. En este sitio, un firewall en el borde con reglas personalizadas, un límite de tasa en el borde, un token CSRF y un limitador de tasa en la aplicación. En el sitio del estudio, el mismo tipo de reglas en el borde, un límite de tasa en el borde y un limitador propio de la aplicación que no rechazó ninguno de los envíos observados, y un campo honeypot.⁹²⁵⁷ El resto de este post recorre las dos avalanchas y el goteo lento uno por uno, luego las cinco capas una por una, con el texto de la regla o el comportamiento del código para cada una.

De dónde salen las cifras

Cada conteo que sigue proviene de los análisis de solicitudes y los eventos de firewall de Cloudflare para las dos zonas, consultados el 3 de noviembre sobre ventanas ya cerradas, más la tabla de mensajes del sitio del estudio y el log de mi propio monitor.¹⁶ Un script convirtió los resultados guardados de esas consultas en un registro de unos cuantos cientos de filas, cada una con la regla que la produjo, y el post toma sus cifras del registro y de su anexo y de ningún otro lugar. Donde mis notas del día no coinciden con el registro, gana el registro: escribí las notas del 30 de octubre minutos después de la avalancha, mientras Cloudflare todavía ingería sus últimos minutos, y se quedan cortas.¹⁶²⁶ Cloudflare conserva estos conjuntos de datos «at least 31 days of data on every plan» (al menos 31 días de datos en todos los planes), así que pude contar una avalancha a posteriori, pero no para siempre.²⁷

Dos tipos de cifra requieren una advertencia. Los eventos de firewall son una muestra, así que los uso para saber qué regla actuó y cuándo, y los conjuntos de datos de solicitudes para saber cuántas.¹⁶ Y un envío del formulario que recibió un 200 en este sitio es un envío, o un fallo al que el controlador también responde con 200 (tiene dos rutas de fallo así), no un correo entregado, y no revisé el log de mi proveedor de correo. Cada conteo de correos de este post es, por tanto, un techo.²⁴²⁸

Cómo se veía lo normal

Antes de las avalanchas, el formulario estaba tranquilo. En los ocho días que cubren las consultas, tres direcciones distintas de los dos escáneres enviaron el formulario con éxito, cada una exactamente dos veces, una dirección por día el 27, el 28 y el 29 de octubre.²⁹ No sé si eran personas. Dos envíos desde una misma dirección encajan con un doble clic, y encajan con un bot que reintenta. Esa incertidumbre es todo el problema en miniatura: nada en los logs ni en los controles podía decirlo.

2. Primera avalancha: 30 de octubre, bloqueada a mano

La primera avalancha vino de una sola dirección en una red que el registro regional de internet lista bajo BULLIONET FBW NETWORKS SAS, registrada en Francia.³⁰ Su primera solicitud cayó en el minuto de las 17:59 UTC, las 10:59 en horario de verano del Pacífico, y la última en el minuto de las 18:51, las 11:51 PDT: 53 intervalos de un minuto y 76.429 solicitudes a este sitio. Dos consultas independientes, una por minuto para la dirección y otra que barre todas las zonas de mi cuenta, coinciden en ese total, y la dirección no envió nada antes ni después.¹³

La forma del escaneo

El formulario fue una parte pequeña. Antes del bloqueo, la dirección promedió 1.389,7 solicitudes por minuto, con un pico de 3.219 en el minuto de las 18:36, y recorrió el sitio completo: al menos 2.881 rutas distintas, un límite inferior porque la consulta de rutas llegó a su límite de filas.¹³³¹ En todo el escaneo, los resultados se repartieron así:¹³

El 7,3 % del borde es casi todo el bloqueo: 5.234 de sus 5.587 rechazos llegaron después del minuto del bloqueo.¹³ Durante los cincuenta minutos anteriores, solo actuó la regla de rutas de exploits. Esa regla funcionó desde el primer minuto, con el primer evento de firewall a las 17:59:53 UTC, pero coincide con subcadenas de ruta como .php y /wp-, y la mayor parte de este escaneo pedía páginas reales.¹⁰⁹

Lo que lo convertía en un escaneo y no en un rastreo era lo que ponía en las solicitudes. Casi todo el tráfico, al menos 69.322 solicitudes, usaba un único agente de usuario de Chrome 141 para Windows, sin nada raro. Al menos 2.755 más decían ser Googlebot, y la regla de bots verificados del borde no las trató como Google.³² Al menos 3.154 solicitudes llevaban una carga de inyección SQL en la propia cabecera User-Agent, en al menos 396 cadenas distintas, y al menos 2.680 solicitudes llevaban una en la ruta, en al menos 810 rutas distintas.³²³¹ Las cargas pertenecen a familias documentadas. PG_SLEEP(15), waitfor delay '0:0:15' y XOR(if(now()=sysdate(),sleep(15),0)) son sondas basadas en tiempo: la hoja de referencia de PortSwigger lista la sintaxis de retardo para Oracle, Microsoft SQL Server, PostgreSQL y MySQL, y las definiciones de cargas del propio sqlmap contienen las mismas funciones.³³³⁴ PortSwigger explica por qué funcionan: «As SQL queries are normally processed synchronously by the application, delaying the execution of a SQL query also delays the HTTP response.» (como la aplicación suele procesar las consultas SQL de forma síncrona, retrasar la ejecución de una consulta también retrasa la respuesta HTTP).³⁵ Una respuesta lenta prueba poco; un retardo de unos 15 segundos que vuelve cada vez que la carga lo pide, y no en las solicitudes de control sin ella, es evidencia de una posible inyección.

La aplicación de pintura de este sitio tiene un endpoint para compartir, y el escáner lo encontró. Envió 320 POST a la ruta de compartir, la única dirección que lo hizo en los ocho días que cubren las consultas, y el endpoint rechazó los 320 y no guardó nada. Alrededor de ellos envió POST a variantes de la ruta con la carga incrustada, como /paint/share'||DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15)||' y /paint/(select 198766*667891 from DUAL), a las que el sitio respondió con 404.³¹ La dirección también tocó otra zona de mi cuenta, con 387 GET a kiradex.app, todos respondidos con 200, y ninguna más.¹³ Mi lectura es que siguió enlaces de este sitio a ese; no he revisado los enlaces.

El catálogo de amenazas automatizadas de OWASP tiene un nombre para esta actividad: OAT-014, Vulnerability Scanning, «Crawl and fuzz application to identify weaknesses and possible vulnerabilities.» (rastrear la aplicación y someterla a fuzzing para identificar debilidades y posibles vulnerabilidades).³⁶ El formulario de contacto era una entrada más para el fuzzing.

El formulario, minuto a minuto

La dirección envió el formulario de contacto 1.065 veces, y todos los envíos llegaron a la aplicación; el borde no detuvo ninguno.¹ El primer envío y el primer correo enviado llegaron en el minuto de las 18:00 UTC, las 11:00 PDT. Aquí está cada minuto en que un envío del formulario llegó a la aplicación, según el estado que devolvió la aplicación:¹

Los totales: 101 enviados, 830 rechazados por el limitador de la aplicación, 130 rechazados porque faltaba un campo obligatorio y 4 rechazados por la verificación CSRF, los cuatro en el minuto de las 18:03.¹ Los 429 eran de la aplicación. La regla de límite de tasa del borde todavía no existía, no hay ningún evento de firewall de límite de tasa para la dirección, y donde Cloudflare registró el estado del origen para estos envíos, el 429 vino del origen.¹⁰³⁷ Los 422 vinieron de la validación de formularios de FastAPI, que se ejecuta antes del limitador, así que nunca gastaron un turno del limitador; comprobé el orden con una aplicación FastAPI de diez líneas, en la que un envío sin un campo obligatorio devolvió 422 sin llamar nunca al envoltorio.³⁸ La ráfaga de 129 a las 18:37 parece el escáner haciendo fuzzing de los campos del formulario al omitirlos.

Lee la columna «Enviados» frente al limitador. El limitador permite cinco envíos por dirección por minuto de reloj, y en ocho de esos minutos salieron más de cinco, 18 de ellos a las 18:06.¹³ La sección 4 explica cómo.

El aviso y el bloqueo

Me di cuenta a las 11:46 PDT y anoté que algo golpeaba el formulario de contacto del sitio una y otra vez.²⁶ Para entonces, el primer envío del formulario tenía unos 46 minutos, y la avalancha sobre el formulario había terminado a las 11:37 PDT.¹ Añadí la dirección a mano a la lista de bloqueo a nivel de cuenta con la que ya coincide la primera regla personalizada de la zona, y el primer evento de esa regla llegó a las 18:49:53 UTC, las 11:49:53 PDT.¹⁰ El bloqueo llegó 3,9 minutos después de que me di cuenta, unos 50 minutos después del primer envío del formulario y 50,9 minutos después del primer minuto del escaneo.¹¹³ Los 101 envíos ya habían salido antes; el último envío del formulario que llegó a la aplicación llegó unos 12 minutos antes del bloqueo.¹ Después del minuto del bloqueo, la dirección envió 5.234 solicitudes más, y el borde las rechazó todas.¹³

En el mismo segundo, las 18:49:53 UTC, creé la única regla de límite de tasa de la zona: POST de formulario a las rutas de contacto y de compartir de la aplicación de pintura, 3 cada 10 segundos por dirección, con bloqueo durante 10 segundos.⁹ A las 18:52:38 UTC la probé desde mi propia máquina. En mis notas de esa prueba, seis envíos con un segundo de separación, con un agente de usuario de navegador y sin un token CSRF válido, «returned 403 403 403 429 429 429 (the app’s CSRF rejection, then the edge’s rate limit)» (devolvieron 403 403 403 429 429 429: el rechazo CSRF de la aplicación y luego el límite de tasa del borde), y los envíos simples con curl nunca llegaron a la regla, porque una regla personalizada existente les sirvió un desafío gestionado.²⁶ Mis notas dicen que los envíos no llevaban token, pero un envío sin ese campo provoca un 422 antes de que se ejecute el controlador, como mostró mi prueba del 3 de noviembre, así que los 403 indican un token presente y no válido.¹⁸ Los eventos de firewall coinciden: tres eventos de límite de tasa desde mi dirección de prueba, el primero en ese segundo, y 24 desafíos gestionados para mis envíos con curl.³⁹ Nada de mi tráfico de prueba está en ninguno de los conteos anteriores.

Mi monitor no estaba funcionando ese día. Lo volví a activar el 31 de octubre, y su detector de tráfico llegó después de esta avalancha.¹⁹ El bloqueo del 30 de octubre lo hizo una persona leyendo la bandeja de entrada.

30 de octubre: 76.429 solicitudes de una sola dirección, por minuto; hasta que bloqueé la dirección a mano, el borde casi no rechazó ninguna.¹³¹⁰

3. Segunda avalancha: 2 de noviembre, bloqueada por mi monitor

La segunda dirección pertenece a NovoServe B.V., un proveedor de hosting en los Países Bajos.⁴⁰ Envió dos GET a las 07:49 UTC, las 23:49 en horario estándar del Pacífico del 1 de noviembre, y luego nada durante 11,1 horas. El escaneo propiamente dicho fue del minuto de las 18:56 UTC al de las 19:17, de las 10:56 a las 11:17 PST: 22 intervalos de un minuto y 10.907 solicitudes, o 10.909 con los dos GET tempranos. Cuatro consultas independientes coinciden en el total.¹⁴

Parecía la misma herramienta. Usó la misma cadena de agente de usuario de Chrome 141 para Windows que la dirección del 30 de octubre en 9.725 solicitudes, la misma cadena de Googlebot en 942, las mismas familias de inyección, y tocó las mismas dos zonas y ninguna otra, con 368 GET a kiradex.app.⁴¹⁴²¹⁴ Dos direcciones en dos redes de dos países no prueban nada sobre quién las operaba, así que lo dejo en «parecía».

La cronología, en ambas zonas horarias

Los ocho minutos de mi monitor

Mi monitor levantó su primer hallazgo 7,9 minutos después del primer minuto del escaneo, y el bloqueo entró en vigor 8,0 minutos después de ese minuto, o 6,8 minutos después del primer evento de firewall.¹⁹⁴ Para entonces habían salido 26 envíos en los minutos previos al bloqueo, y los últimos 5 cayeron en el propio minuto del bloqueo, que los datos por minuto no pueden situar antes o después del segundo del bloqueo; ninguno llegó en los minutos siguientes.² Ocho minutos es rápido para un bloqueo y lento para una bandeja de entrada.

La ejecución que arrancó a las 10:57:00 PST tuvo el escaneo a la vista durante alrededor de un minuto, y en su ventana la dirección hizo entre 29 y 666 solicitudes; la cifra superior cuenta el minuto completo de las 18:57, del que la ventana solo vio 22 segundos. El detector no registró ningún hallazgo.¹⁹ La siguiente ejecución, a las 11:02:46 PST, encontró la avalancha y la bloqueó, y esa ejecución muestra por qué la primera pudo pasarla por alto. Su ventana terminaba en el momento en que consultaba a Cloudflare, antes de que llegaran los eventos más recientes: su log registra 1.914 solicitudes de la dirección, mientras que mi repetición de la misma ventana de cinco minutos el 3 de noviembre, sobre datos completos, cuenta 2.143; la repetición está guardada con sus comandos y su salida completa, y sus conteos son filas del anexo del registro.¹⁹⁴³ La repetición también levanta un hallazgo de avalancha sobre el formulario que la ejecución real nunca levantó, a partir de 39 envíos, 23 de ellos rechazados, con severidad alta, que habría sido una línea en el resumen diario y no un correo ni un bloqueo.⁴³ Repetí la ventana de la segunda ejecución, no la de la primera, así que para la ejecución de las 10:57 PST el mismo retraso es la causa probable, no una medida. Ese mismo día cambié las ventanas del monitor para que terminen 90 segundos antes de cada ejecución y empiecen donde terminó la anterior.⁴³ En total se dispararon seis hallazgos sobre la dirección, y mi monitor los incorporó todos a su resumen diario en lugar de enviarme un correo, porque la dirección ya estaba en su registro de bloqueos.¹⁹ Cómo debería alertar mi monitor, y este escáner visto desde su lado, es el tema de un post aparte; para este, lo que importa es que un bloqueo es una reacción, y la reacción llegó después de al menos 26 de los 31 envíos.

El formulario, por estado

La dirección envió el formulario 500 veces.²

Los totales: 31 enviados, 31 rechazados por el limitador de la aplicación y 438 rechazados en el borde, todos en el minuto del bloqueo o después. Así que 62 envíos llegaron a la aplicación.² Cada envío exitoso prueba que el escáner tenía un token CSRF válido, porque el controlador verifica el token antes de enviar. Los 429 no prueban nada en ningún sentido, porque el limitador rechaza un envío antes de que el controlador lea su token.²⁴¹⁶ Donde Cloudflare registró el estado del origen para esos 429, era el del origen, el del limitador de la aplicación, y no hay ningún evento de firewall de límite de tasa para la dirección.³⁷⁴

El resto del escaneo

Por resultado, el escaneo del 2 de noviembre se repartió así:¹⁴

El 72,7 % del borde es sobre todo el bloqueo: 2.986 solicitudes llegaron antes del minuto del bloqueo y 7.445 después, y el sitio no sirvió ninguna de estas últimas.¹⁴ La consulta de rutas de este día fue completa: 2.173 rutas distintas, y 778 solicitudes en 542 de ellas llevaban una carga de inyección SQL.⁴⁴ La consulta de agentes de usuario también fue completa, 73 cadenas distintas. Además de la cadena simple de Chrome y de la que decía ser Googlebot, el escáner envió 54 cargas SQL distintas en 149 solicitudes, tres cadenas para romper comillas en 78 y 12 tokens marcadores, cada uno enviado una vez.⁴¹

Vale la pena mirar algunas de esas cadenas, porque muestran lo que el escáner preguntaba. (select 198766*667891 from DUAL) es una expresión aritmética dentro de un select sin tabla; FROM dual es la sintaxis de Oracle para eso, como muestra la hoja de referencia de PortSwigger.³³ if(now()=sysdate(),sleep(15),0) tiene la misma forma IF(condition, SLEEP(n), x) que el retardo condicional de la misma hoja de referencia.³³ @@qkLpP es un prefijo @@, el que usa la hoja de referencia en SELECT @@version para Microsoft y MySQL, seguido de cinco caracteres, y el escáner envió una docena parecidas.³³⁴¹ La guía de pruebas de OWASP nombra las dos técnicas a las que sirven estas cadenas: la inyección basada en errores, que «forces the database to generate an error» (obliga a la base de datos a generar un error), y los retardos de tiempo que «use database commands (e.g. sleep) to delay answers in conditional queries.» (usan comandos de la base de datos, como sleep, para retrasar las respuestas en consultas condicionales).⁴⁵ Ninguna de las páginas que consulté documenta estas cadenas exactas, así que las describo y no las atribuyo a una herramienta concreta.

2 de noviembre: 10.907 solicitudes de una sola dirección, por minuto, con las dos ejecuciones de mi monitor y el bloqueo que colocó a las 11:04:01 PST.¹⁴¹⁹

4. Las cinco capas, y lo que cada una podía distinguir

Cinco tipos de control se interponían entre estos bots y mi bandeja de entrada. A cada uno le hice la misma pregunta: ¿podía distinguir un bot de una persona? Un desafío gestionado en las reglas del borde puede hacerle esa pregunta a un visitante, pero solo a las solicitudes cuya cadena de agente de usuario está en su lista, y las de los escáneres no lo estaban; un segundo, basado en una puntuación de amenaza, nunca podía activarse, así que nada se lo preguntó a cada envío. Dos de los controles cuentan, uno compara nombres y listas, uno prueba que un cliente tiene un token emitido por el sitio y uno atrapa solo a los bots que llenan un campo oculto. Aquí está cada uno, qué verifica, qué detuvo y la razón exacta por la que dejó pasar el resto.

Reglas personalizadas del borde

Qué verifican. En este sitio, la primera regla personalizada bloquea cualquier dirección que esté en una lista a nivel de cuenta, además de siete redes de hosting por ASN. Otra bloquea subcadenas de rutas de exploits como .php, /wp- y /.env. Otras dos sirven un desafío gestionado en el formulario de contacto y en la ruta de administración: una para un agente de usuario vacío o que contenga curl, wget, python-requests, httpx, scrapy, HeadlessChrome, PhantomJS o Selenium, y otra para una puntuación de amenaza alta de Cloudflare. El sitio del estudio tiene reglas del mismo tipo, con ambos desafíos aplicados a todo el sitio y un bloqueo en las rutas de la API que exime al formulario de contacto.⁹ Los desafíos por puntuación de amenaza, uno en cada sitio, eran reglas muertas: la referencia de campos de Cloudflare dice que la puntuación iba antes de 0 a 100, y «Now, the threat score is always 0 (zero).» (ahora la puntuación de amenaza es siempre 0). Una regla que pide una puntuación alta no coincide con nada, y desactivé ambas el 3 de noviembre, el día en que lo leí; los desafíos por agente de usuario siguen.¹¹⁴⁶ El plan Free de Cloudflare permite cinco reglas 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.» (funcionan como reglas de firewall de aplicaciones web personalizadas con las que puedes realizar acciones como Block o Managed Challenge sobre las solicitudes entrantes).⁴⁷

Qué detuvieron. Las rutas de exploits, desde el primer minuto en ambos días.¹⁰⁴ El 30 de octubre, ningún envío del formulario.¹¹⁰ El 2 de noviembre, los 438 envíos del formulario posteriores al bloqueo de mi monitor.² En el sitio del estudio, ningún envío del formulario: el firewall no registró ningún evento sobre un POST al formulario en los ocho días.⁷

Por qué pasó el resto. Ninguna regla mira qué es una solicitud. La regla de la lista solo coincide con una dirección después de que algo la pone en la lista, una persona el 30 de octubre y mi monitor el 2 de noviembre.⁹¹⁰¹⁹ El desafío por agente de usuario compara una cadena, y ambos escáneres enviaron una cadena de navegador, al menos 69.322 veces el primer día y 9.725 veces el segundo.³²⁴¹ El desafío por agente de usuario sí funciona contra las herramientas que se anuncian: mi propia prueba con curl del 30 de octubre provocó 24 desafíos gestionados.³⁹ El desafío por puntuación de amenaza no podía activarse con nadie, y el firewall no registró ningún desafío en el formulario para ninguna de las dos direcciones.¹¹¹⁰⁴ Las salidas de Tor y las redes de hosting fuera de los siete ASN nombrados no están en ninguna lista.

Una regla del borde puede distinguir una dirección conocida, una red conocida o una herramienta honesta del resto, y su desafío pregunta si hay una persona solo a las solicitudes que selecciona su expresión; no puede distinguir una cadena de navegador enviada por un escáner de un navegador.

Límite de tasa del borde

Qué verifica. El texto de la regla es corto:⁹

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

Cuenta las solicitudes que coinciden por centro de datos de Cloudflare y dirección del cliente, permite 3 cada 10 segundos y bloquea durante 10 segundos. Repartido de forma uniforme, ese techo equivale nominalmente a 18 por minuto por dirección y por centro de datos; la propia regla cuenta en periodos de 10 segundos.⁹¹⁶ El plan Free fija el periodo, el tiempo de espera y la clave de conteo, y da a la zona una sola regla de este tipo: un periodo de conteo de 10 segundos, un tiempo de mitigación de 10 segundos y conteo por IP.⁴⁸ El centro de datos tampoco es opcional. «Every rate limiting rule includes the Cloudflare data center ID (cf.colo.id) as a mandatory characteristic» (toda regla de límite de tasa incluye el ID del centro de datos de Cloudflare como característica obligatoria), dice la documentación de Cloudflare, y «Counters are not shared across data centers, with the exception of data centers associated with the same geographical location.» (los contadores no se comparten entre centros de datos, salvo los asociados a la misma ubicación geográfica).⁶

Qué detuvo. Ninguna solicitud de los escáneres en ninguno de los dos días. Sus únicos eventos en la ventana del incidente fueron los tres de mi propia prueba.¹⁰⁴³⁹ El sitio del estudio tiene su propia regla de límite de tasa para todo el sitio, que cuenta del mismo modo todas las solicitudes salvo las de clientes que Cloudflare lista como bots verificados, y no rechazó ninguno de los envíos del goteo: su firewall no registró ningún evento sobre un envío al formulario en los ocho días. Esa regla cuenta todas las solicitudes de ese tipo que una dirección envía al sitio, y mis datos solo cuentan los envíos del formulario, así que no miden cuánto margen le quedaba al contador.⁹⁷

Por qué pasó el resto. El 30 de octubre, la regla no existió hasta las 18:49:53 UTC, el mismo segundo del primer evento del bloqueo manual y unos 12 minutos después de que el último envío del formulario llegara a la aplicación.⁹¹ Los 1.065 envíos de ese escáner llegaron todos por un solo centro de datos, París, así que una regla vigente habría llevado un solo contador para ellos.⁵ El 2 de noviembre la regla existía y los envíos del formulario del escáner llegaron por dos centros de datos, Ámsterdam con 44 y Londres con 41, entre las 18:56 y las 19:05:00 UTC. En el minuto de más actividad, las 19:02, Londres llevó 18 y Ámsterdam 14.⁵ Dieciocho en un minuto es el equivalente nominal del techo de la regla, pero mis datos contienen totales por minuto, no tiempos de llegada, así que no pueden mostrar si algún periodo de 10 segundos en un centro de datos tuvo más de tres. Cloudflare es claro sobre la precisión: «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.» (las reglas de límite de tasa no están diseñadas para dejar llegar un número preciso de solicitudes al servidor de origen; puede haber un retraso de hasta unos segundos entre detectar una solicitud y actualizar los contadores).⁴⁸ En el lapso de siete minutos entre su primer envío que llegó a la aplicación y el último, el escáner promedió 8,86 por minuto.² Mis notas del día lo llamaron «about nine a minute» (unos nueve por minuto) y se detuvieron ahí; la división entre centros de datos es lo que se les escapó.²³

Quería una prueba de que la regla funciona, así que la mañana del 3 de noviembre la sondeé desde mi propia máquina. A las 06:36:49 PST envié diez POST con 0,4 segundos de separación sin token CSRF: cuatro volvieron con 422, porque faltaba un campo obligatorio y FastAPI los rechazó, y luego seis volvieron con 429. A las 06:38:03 PST envié ocho con todos los campos presentes: tres volvieron con 403, el rechazo CSRF del origen, y luego cinco volvieron con 429 con el cuerpo «error code: 1015» de Cloudflare. El firewall registró 11 eventos en el formulario en esos minutos, todos ellos bloqueos de la regla de límite de tasa.¹⁸ La regla se activa, y Cloudflare lo registra. Mi lectura del 2 de noviembre es una hipótesis: repartido entre dos contadores y cerca del techo nominal en cada uno, el escáner nunca hizo saltar ninguno. Es la explicación más sólida que encaja con los totales por minuto, no una demostración; los totales no pueden mostrar cómo se espaciaron los envíos dentro de cada minuto, y Cloudflare admite que pueden pasar solicitudes de más mientras se actualizan sus contadores.⁵⁴⁸

Un límite de tasa puede distinguir lo rápido de lo lento, para una dirección en un centro de datos; no puede distinguir quién envía.

Token CSRF

Qué verifica. El formulario de este sitio lleva un token oculto, insertado en la página, con tres partes: una marca de tiempo, un valor aleatorio y una firma HMAC sobre los dos primeros. El servidor lo acepta si la firma coincide y la marca de tiempo tiene menos de una hora.¹⁵ El formulario del sitio del estudio no tiene token CSRF.²⁵

Qué detuvo. Cuatro envíos el 30 de octubre, todos en el minuto de las 18:03, y ninguno el 2 de noviembre.¹²

Por qué pasó el resto. El token no tiene estado. No está ligado a una sesión, a una cookie ni a una dirección, así que cualquier cliente que descarga la página obtiene uno válido, y cualquier cliente al que otro le pase un token puede presentarlo mientras dure. Ambos escáneres sí descargaron las páginas del sitio; eso es lo que muestran los logs de solicitudes. Lo que muestra la verificación es más acotado: cada envío de ambos días llevaba un token válido y no vencido emitido por mi sitio, porque el controlador verifica el token antes de enviar.^1513142416 Un token CSRF existe para impedir que otro sitio haga que el navegador de un visitante envíe mi formulario. Nunca se pensó para detener a un cliente que quiere enviar el formulario por sí mismo, y no lo hizo.

La misma verificación tenía un segundo defecto, y recaía en las personas y no en los bots. Cuando el token fallaba, el controlador lanzaba un 403 en JSON que el formulario HTMX nunca mostraba, así que una persona con un token vencido habría hecho clic en Enviar y no habría visto nada.¹² Lo arreglé, aunque mi primer arreglo tampoco funcionó; la sección 6 cuenta cómo.

Un token CSRF válido prueba que el cliente tenía un token no vencido emitido por mi sitio; no puede probar quién llenó el formulario, ni siquiera que este cliente cargó la página.

Limitador de tasa de la aplicación

Qué verifica. El controlador de este sitio está detrás de un decorador que cuenta los envíos del formulario por dirección de cliente y por minuto de reloj en Cloudflare KV, con un respaldo en memoria, y rechaza a partir de cinco con un 429.¹⁷ El sitio del estudio tiene un limitador en memoria por proceso para clientes anónimos, que cuenta por dirección y por clasificación del cliente, la clase que el limitador asigna a partir del agente de usuario y la dirección, sobre todas las rutas salvo las comprobaciones de salud y los archivos estáticos.²⁵

Qué detuvo. 830 envíos el 30 de octubre y 31 el 2 de noviembre. Ninguno en el sitio del estudio.¹²⁷

Por qué pasó el resto. Por diseño deja pasar cinco por minuto a cualquiera, y como la ventana es el minuto de reloj, una ráfaga que cruza el cambio de minuto recibe dos cupos.¹⁷ Eso ya lo sabía. Lo que no sabía hasta que leí los conteos frente al código es que tiene fugas, y el código tiene al menos tres formas de tenerlas. El limitador lee el contador de KV por HTTP, lo compara con el límite y luego escribe el conteo más uno en una solicitud aparte, así que dos envíos que leen antes de que cualquiera escriba pasan los dos. El incremento lee el contador una segunda vez antes de escribir, y si esa segunda lectura falla, la escritura devuelve el conteo a uno, así que el minuto vuelve a empezar. Y siempre que la lectura de KV no devuelve nada o la escritura falla, la decisión recurre a una lista guardada en la memoria de un solo proceso, que los demás procesos no comparten.¹⁷

Los conteos muestran la fuga. El 30 de octubre, ocho minutos tuvieron más de cinco envíos, y el minuto de las 18:06 tuvo 18.¹ Un limitador exacto a cinco por minuto habría permitido como máximo 54 envíos en los minutos en que el escáner envió, y salieron 101, 47 por encima del techo. El 2 de noviembre, los minutos de las 19:02 y las 19:03 dejaron pasar 9 y 10; un limitador exacto habría permitido como máximo 22 de los 62 envíos que vio, y salieron 31, 9 por encima del techo.³ No muestran qué ruta tuvo la fuga. Mi lectura es que hubo envíos que leyeron el mismo conteo antes de que cualquiera escribiera, o que las llamadas a KV fallaron bajo la carga, reiniciando el conteo o entregando la decisión a las listas por proceso, o alguna combinación de esto; los logs que tengo registran el estado que devolvió la aplicación, no qué ruta lo decidió, así que no pueden distinguir las rutas.¹⁷³ El remedio es el mismo para todas, y no es un cambio de una línea: un almacén de contadores con un incremento atómico, algo que una lectura de KV seguida de una escritura aparte no ofrece. La fuga es un bug mío. También hace que el argumento de este post sea más afilado de lo que habría podido hacerlo a propósito: un control que dice cinco y deja pasar dieciocho nunca iba a ser lo que decide quién puede escribirme.

En el sitio del estudio, el limitador de la aplicación no rechazó ninguno de los envíos observados, y la dirección más activa envió 13 en una hora. Sus contadores suman las solicitudes de una dirección a cualquier otra ruta bajo la misma clasificación de cliente, y mis datos solo cubren los envíos del formulario, así que los conteos no miden cuánto margen tenían esos contadores.⁷²⁵

Un limitador de tasa puede distinguir cinco de seis cuando las solicitudes se turnan; no puede distinguir una persona de un script con ningún conteo.

Honeypot

Qué verifica. El formulario del sitio del estudio tiene un campo de texto llamado website que una persona nunca ve: lleva tabindex="-1" y aria-hidden, así que ni el teclado ni un lector de pantalla llegan a él. Si vuelve con algo escrito, el controlador responde con el mismo mensaje de éxito que vería una persona, y no guarda ni envía nada.²⁵ Esa rama está en el controlador desde que construí el formulario el 5 de junio.²⁵ El formulario de este sitio no tiene honeypot.²⁴

Ned Batchelder describió la técnica en 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» (estos campos se llaman honeypots y se validan cuando se envían los datos del formulario; si contienen algún texto, quien envía debe ser un bot).⁴⁹ Su razón de que funcione es que los bots que llenan formularios «cannot distinguish invisible fields from visible ones.» (no pueden distinguir los campos invisibles de los visibles).⁴⁹

Qué detuvo. 42 de los 52 envíos de los ocho días, el 80,8 %, incluido cada envío desde una salida de Tor según la hora en que llegaron y, por la hora y el patrón del mensaje, los 13 de una ráfaga de un autodenominado SQL spider.⁷²⁰

Por qué pasó el resto. Un bot que solo llena los campos visibles nunca toca website, y los remitentes cuyos envíos se guardaron, y por tanto podían llegar a mi bandeja, lo dejaron vacío.⁸²⁵ Que eligieran los campos visibles a propósito es mi lectura; el controlador solo registra que el oculto volvió vacío. Batchelder lo vio venir: «In theory, it is possible for a spambot to defeat any of these measures. But in practice, bots are very stupid» (en teoría, un spambot puede vencer cualquiera de estas medidas; pero en la práctica, los bots son muy tontos).⁴⁹ Algunos son menos tontos que otros, y los que venden generación de leads son los menos tontos.

Un honeypot solo prueba que el cliente llenó un campo que una persona no puede ver; uno vacío no prueba nada.

Hasta dónde llegó cada flujo: los envíos de los dos escáneres en este sitio y ocho días del goteo en el sitio del estudio.¹²⁷⁸

Lo que tenían en común las cinco

Lee juntas las cinco frases y el hueco salta a la vista. Los límites de tasa acotan el volumen por dirección. Un token CSRF prueba que un cliente tenía un token emitido por el sitio. Un honeypot prueba que el cliente llenó un campo oculto. Las reglas del borde conocen nombres y listas, y la que podría preguntar si hay una persona del otro lado, el desafío por agente de usuario, solo pregunta a las solicitudes cuya cadena de agente de usuario está en su lista; el desafío por puntuación de amenaza que tiene al lado nunca podía activarse. Ninguno de los dos escáneres coincidió, así que nada se lo preguntó a cada envío, y los escáneres no hicieron nada que un navegador no pueda hacer: descargaron la página, guardaron su token y enviaron a un ritmo que los límites dejaron pasar en parte. La guía de OWASP contra el relleno de credenciales hace la misma observación sobre otro formulario, y aconseja defensas que «not rely on a single predictable volume limit» (no dependan de un único límite de volumen predecible).⁵⁰

5. El goteo lento en el sitio del estudio

El formulario del sitio del estudio nunca tuvo una avalancha. Tuvo un goteo, y el goteo es otra cosa. La ventana aquí va desde la primera hora con un envío del formulario en la consulta de ocho días, las 17:00 UTC del 26 de octubre, hasta el momento en que guardé los datos, las 13:59:50 UTC del 3 de noviembre; el primer y el último día son parciales.⁷

Envíos frente a filas guardadas

El formulario recibió 52 POST en esa ventana y respondió a todos con 200. La tabla de mensajes ganó 10 filas en la misma ventana. Como la rama del honeypot es la única ruta del controlador que responde 200 y no guarda nada, el honeypot atrapó los otros 42, el 80,8 %.⁷⁸²⁵ Por día UTC:⁷⁸

El pico del 30 de octubre es una dirección en Gran Bretaña que envió 13 veces en una sola hora con el agente de usuario Mozilla/5.0 (compatible; SQLSpider/1.5). Por la hora y el patrón del mensaje, la tabla no guardó ninguno: la única fila guardada en esa hora es un discurso de venta de generación de leads, el patrón de la dirección estadounidense que también envió en esa hora.⁷⁸²⁰

Quién enviaba

Cloudflare etiqueta las solicitudes de la red Tor con un código de país especial, T1. Su referencia de cabeceras dice «T1 - Used for clients using the Tor network» (T1: se usa para clientes que usan la red Tor), y su página de reglas de IP Access dice «T1: Tor exit nodes (country name: Tor)» (T1: nodos de salida de Tor, con Tor como nombre de país).⁵¹⁵² Según ese código, 23 de los 52 envíos vinieron de Tor, el 44,2 %, y 23 de las 35 direcciones distintas eran salidas de Tor, el 65,7 %.⁷ Como verificación cruzada, comparé cada dirección que envió el formulario con la lista masiva de salidas del Tor Project, que el proyecto llama «a nearly real time authoritative source for Tor exits that allow contacting your server on port 80» (una fuente autorizada, casi en tiempo real, de las salidas de Tor que permiten contactar con tu servidor en el puerto 80). Las 23 direcciones que Cloudflare codificó como T1 estaban en la lista que descargué el 3 de noviembre, y ninguna de las otras 12.⁵³⁵⁴ Las dos fuentes coinciden. Esa lista es la de las salidas del 3 de noviembre, eso sí, así que confirma el código para ese día y no prueba qué direcciones eran salidas el día en que llegó cada envío. El archivo CollecTor del proyecto conserva listas de salidas pasadas y resolvería la pertenencia en el día del evento; no lo consulté.⁵⁵

La mayoría de las direcciones de esta ventana enviaron una sola vez: 32 de las 35, el 91,4 %, y todas las salidas de Tor entre ellas.⁷ Las tres que enviaron más de una vez fueron el SQL spider con 13, una dirección en Polonia con dos en una hora y una dirección en Estados Unidos con cinco. Los cinco envíos de esta última caen en las mismas cinco horas que los cinco discursos de generación de leads que la tabla guardó en la ventana, y cambió de agente de usuario cada vez: Chrome 135 en Linux, luego Firefox 128, 137, 138 y 137 otra vez.⁷²⁰

Los agentes de usuario se dividieron por la misma línea. De los envíos de Tor, 18 nombraban un dispositivo Android y 5 un Chrome de escritorio, y 21 de los 23 nombraban Chrome 81 o anterior. Los envíos que no venían de Tor nombraban navegadores de escritorio mucho más nuevos, 10 Chrome de escritorio del 125 al 135 y 6 Firefox del 128 al 138, más los 13 del spider con su propio nombre.⁷

Quién quedó guardado

Las dos mitades se encontraron en el honeypot. Ninguna fila guardada en la ventana cae en una hora que solo tuvo envíos de Tor, y las 10 caen en una hora con un envío ajeno a Tor. 22 de los 23 envíos de Tor cayeron en horas sin ninguna fila guardada, y el 23.º comparte su hora con la dirección estadounidense de generación de leads.²⁰ Hice la correspondencia por hora porque los logs de solicitudes y la tabla de mensajes no comparten ningún ID de solicitud, así que la correspondencia es una inferencia: según la hora en que llegaron, cada envío de Tor en la ventana fue una caída en el honeypot.²⁰ Lo que se guardó, y por tanto podía llegar a la bandeja, vino de direcciones fuera de Tor, que enviaban cadenas de navegador de escritorio más nuevas y dejaban el honeypot vacío.

Las cifras encajan con el viejo patrón del spam en formularios. La taxonomía de Batchelder de 2007 divide a los creadores de spam en «Playback spambots, form-filling spambots, and humans.» (spambots que reproducen envíos, spambots que llenan formularios y humanos).⁴⁹ El goteo de Tor se comporta como los que llenan formularios, que llenan todos los campos y caen en el honeypot. Los remitentes que pasaron se comportan como algo más cercano a una persona frente a un teclado, o a un script hecho para parecerlo. OWASP clasifica esta actividad como OAT-017, Spamming: «Malicious or questionable information addition to public or private content, or messages.» (adición de información maliciosa o dudosa a contenido público o privado, o a mensajes).⁵⁶ OWASP también deja fuera una cosa: «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» (el abuso masivo de funciones rotas de formulario a correo o a SMS para enviar mensajes a destinatarios no previstos no está incluido en esta amenaza).⁵⁶ Mis formularios solo me escriben a mí, así que son el caso incluido, spam dirigido al dueño del sitio, y no ese otro.

El goteo también vence al límite de tasa por diseño. La guía de OWASP contra el relleno de credenciales nombra el efecto de repartir las solicitudes entre muchas direcciones: «This may defeat both IP block-lists and rate limiting, as per IP request volume may remain relatively low» (esto puede vencer tanto las listas de bloqueo de IP como el límite de tasa, porque el volumen por IP puede seguir siendo relativamente bajo).⁵⁰ Un envío por dirección es el volumen más bajo posible.

Qué dicen los mensajes guardados

La tabla de mensajes se remonta al 6 de junio y tenía 108 filas cuando la leí; la más reciente llegó a las 07:24 UTC del 3 de noviembre.⁸ Las clasifiqué por patrón con reglas fijas, la primera coincidencia gana:⁵⁷

Algunos merecen una mirada más de cerca. Las nueve filas de los 50 millones llegaron con un mismo nombre de remitente y nueve direcciones de remitente distintas, cada una una pequeña variación del mismo titular.⁸ La pregunta del precio aparece en 25 idiomas en toda la tabla: afrikáans, armenio, euskera, bielorruso, bengalí, búlgaro, catalán, croata, danés, inglés, georgiano, griego, húngaro, islandés, indonesio, irlandés, italiano, latín, letón, lituano, luxemburgués, español, vietnamita, galés y zulú. Solo en octubre llegó en nueve: armenio, euskera, danés, indonesio, latín, letón, lituano, español y vietnamita.⁵⁷ Dos de las identificaciones de idioma son mías y ajustadas: la frase que leí como croata podría ser bosnio, y la que leí como indonesio podría ser malayo.⁵⁷ Alguien está paseando un libro de frases por un formulario de contacto, un idioma a la vez.

El ritmo es la otra firma del goteo. Octubre guardó 32 filas, 1,03 por día, en 21 de sus 31 días, y nunca más de tres en un día.⁸ Ningún límite de tasa por dirección salta con uno al día.

Cuáles llegaron a la bandeja

El formulario envía correos a la bandeja del estudio solo desde el 21 de septiembre a las 17:46:47 UTC. Desde entonces ha guardado, y por tanto enviado, 43 filas, un límite superior porque la llamada de notificación es de mejor esfuerzo y no he verificado la hora del despliegue; las 65 filas guardadas antes de esa fecha nunca se enviaron por correo.²⁵⁸ Cada fila de la ventana de evidencia es spam.⁵⁷

Aparte de mi propia prueba, una fila de toda la tabla no lo es. El 14 de septiembre, un cliente de uno de los productos del estudio escribió sobre un error concreto, con voz de persona, y el mensaje se quedó en la tabla sin que nadie lo leyera.⁵⁷ Cuando conecté el formulario al correo una semana después, el mensaje del commit explicaba por qué con palabras simples: «a paying customer’s message sat unread in D1 for a week» (el mensaje de un cliente que paga se quedó sin leer en D1 durante una semana).²⁵ Ese mensaje es la razón de que exista el notificador, y es la razón por la que no puedo arreglar el spam apagando el notificador. Mantengo anónimo a su remitente; lo importante es que una persona real está en la misma tabla que el libro de frases.

6. Qué es una verificación de bots, y qué se desplegó

Turnstile, en palabras de Cloudflare

Cloudflare llama a Turnstile su «smart CAPTCHA alternative» (alternativa inteligente al CAPTCHA), y dice que «can be embedded into any website without sending traffic through Cloudflare and works without showing visitors a CAPTCHA.» (puede integrarse en cualquier sitio web sin pasar el tráfico por Cloudflare y funciona sin mostrar un CAPTCHA a los visitantes).²¹ El mecanismo es la parte que responde a mi pregunta. «First, we run a series of small non-interactive JavaScript challenges to gather signals about the visitor or browser environment» (primero ejecutamos una serie de pequeños desafíos de JavaScript no interactivos para reunir señales sobre el visitante o el entorno del navegador), dice la descripción general, y «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.» (estos desafíos incluyen prueba de trabajo, con acertijos computacionales, prueba de espacio, sondeo de APIs web y otros desafíos para detectar peculiaridades del navegador y comportamiento humano).²¹ Un límite de tasa pregunta cuántos. Un token CSRF pregunta si el cliente tiene un token emitido por el sitio. Turnstile pregunta qué tipo de cliente hay del otro lado. Mi desafío por agente de usuario también podía preguntarlo, pero solo a las solicitudes cuya cadena de agente de usuario estaba en su lista, y mi desafío por puntuación de amenaza nunca podía activarse; la diferencia que importa aquí es la de un desafío que se activa de forma selectiva frente a una verificación exigida a cada envío.

El widget tiene tres modos. Uso el gestionado, que Cloudflare describe como uno que «Automatically chooses between non-interactive or checkbox challenge based on visitor risk level. No images or text to decipher.» (elige automáticamente entre un desafío no interactivo o una casilla según el nivel de riesgo del visitante; sin imágenes ni texto que descifrar).⁵⁸ En términos simples, un visitante ve una verificación breve y nada más, salvo que las señales pidan más, y entonces recibe una casilla que marcar. El modo invisible oculta incluso eso, y Cloudflare lo condiciona: un sitio que lo activa debe mencionar el Turnstile Privacy Addendum de Cloudflare en su propia política de privacidad.⁵⁸ Turnstile tiene un plan gratuito propio, de hasta 20 widgets, con desafíos ilimitados, y Cloudflare dice que «can be used independently without requiring other Cloudflare services.» (puede usarse de forma independiente sin requerir otros servicios de Cloudflare).⁵⁹

La mitad del servidor, que es la que cuenta

El widget por sí solo no hace nada por un formulario, y Cloudflare lo dice en las primeras líneas de su guía del lado del servidor: «You must call the Siteverify API to complete your Turnstile implementation. The client-side widget alone does not protect your forms.» (debes llamar a la API Siteverify para completar tu implementación de Turnstile; el widget del lado del cliente por sí solo no protege tus formularios). Y luego, más tajante: «Tokens can be forged. An attacker can submit any string to your form endpoint without completing a challenge.» (los tokens pueden falsificarse; un atacante puede enviar cualquier cadena al endpoint de tu formulario sin completar un desafío).⁶⁰ El servidor envía el token a https://challenges.cloudflare.com/turnstile/v0/siteverify con su clave secreta, y puede incluir la dirección IP del visitante como remoteip.⁶⁰

Dos propiedades del token dan forma al código que lo rodea. «Each token is valid for 300 seconds (5 minutes) after generation.» (cada token es válido durante 300 segundos, 5 minutos, desde su generación). Y «Tokens are single-use. Each token can only be validated once. A replayed token will be rejected with the timeout-or-duplicate error code.» (los tokens son de un solo uso; cada token solo puede validarse una vez, y uno reutilizado se rechaza con el código de error timeout-or-duplicate).⁶⁰ Un escáner que hubiera obtenido un token no podría enviar el formulario 1.065 veces con él. Cloudflare también limita el token a 2.048 caracteres y le pide al servidor «Validate the action and hostname when specified.» (validar la acción y el nombre de host cuando se especifiquen).⁶⁰ Una advertencia de la misma página: nombra timeout-or-duplicate para un token vencido en un lugar y describe invalid-input-response como «Token is invalid, malformed, or expired» (el token no es válido, está mal formado o vencido) en su tabla de errores, así que un servidor debería tratar cualquier fallo como un rechazo en lugar de basar su lógica en un solo código.⁶⁰

Qué procesa, en palabras de Cloudflare

Cloudflare no afirma que Turnstile no use datos personales, y yo tampoco lo afirmaré. Su anexo de privacidad de Turnstile nombra las señales: «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.» (Turnstile procesa diversas señales del lado del cliente, como la dirección IP, la huella TLS, la cabecera User-Agent y la sitekey con su origen asociado). Declara el propósito: «The purpose of collecting these Signals is not to identify, profile or target any individuals but solely to detect and block bots.» (el propósito de recopilar estas señales no es identificar, perfilar ni dirigirse a ninguna persona, sino solo detectar y bloquear bots). Y dice que Cloudflare también las usa para mejorar el producto: «Cloudflare is a data controller of Signals that we process to improve Turnstile’s bot detection capabilities.» (Cloudflare es responsable del tratamiento de las señales que procesa para mejorar la detección de bots de Turnstile).²² Lo que Cloudflare sí dice que deja en paz es el contenido: «Turnstile does not access, store, or transmit user communications, form entries, or other page inputs.» (Turnstile no accede a las comunicaciones del usuario, lo que se escribe en los formularios ni otras entradas de la página, ni las guarda ni las transmite).²¹ La página comercial añade que «Turnstile never harvests data for ad retargeting.» (Turnstile nunca recolecta datos para retargeting publicitario).⁶¹ Mi lectura: Turnstile ve el mismo tipo de datos de conexión que mi borde ya registra para cada solicitud, y nunca ve lo que una persona escribe en mi formulario.

La CSP que necesita

Turnstile se carga desde el origen de desafíos de Cloudflare, y una Content Security Policy tiene que permitirlo. Cloudflare lista dos directivas: «script-src: https://challenges.cloudflare.com» y «frame-src: https://challenges.cloudflare.com».⁶² Mis dos zonas fijan su política en una regla de cabeceras de respuesta de Cloudflare. En este sitio la lista de frames ya existía y ganó el origen de desafíos. El sitio del estudio no tenía ningún frame-src, así que su default-src 'self' habría bloqueado el iframe del widget; ganó frame-src 'self' más el origen de desafíos, y la política propia de la aplicación en el código ganó lo mismo.¹²

Por qué no un desafío gestionado sobre el propio POST del formulario

El atajo obvio ya estaba en mi zona: una regla personalizada que responde a un POST al formulario con un desafío gestionado. Mis reglas actuales lo hacen para curl y sus parientes, y funciona, porque ninguna persona usa curl para enviarme un mensaje.⁹³⁹ Extenderlo a todos los POST habría roto el formulario para todo el mundo. Cloudflare documenta la limitación directamente: «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.» (las páginas de desafío interrumpen el flujo de la solicitud devolviendo una página HTML completa para que el navegador la muestre y la resuelva; este mecanismo falla cuando el navegador espera una respuesta que no es HTML, como una solicitud AJAX o XHR).⁶³ El formulario de contacto de este sitio es un formulario HTMX, que envía con hx-post e inserta la respuesta en la página, así que su POST es justo ese tipo de solicitud; la documentación no menciona HTMX por su nombre, y la conexión es mi lectura.²⁴ Un POST desafiado volvería como una página de desafío HTML, que Cloudflare marca con una cabecera cf-mitigated «set to challenge» (con el valor challenge), y «Regardless of the requested resource-type, the content-type of a challenge will be text/html.» (sea cual sea el tipo de recurso solicitado, el content-type de un desafío será text/html).⁶⁴ El formulario insertaría una página de desafío en su recuadro de respuesta, o nada.

La respuesta de la propia Cloudflare para ese caso es otra función: «To ensure your API calls are protected without breaking single-page applications (SPAs) or API integrations, Cloudflare recommends using Turnstile Pre-clearance.» (para proteger tus llamadas a la API sin romper aplicaciones de una sola página ni integraciones de API, Cloudflare recomienda usar Turnstile Pre-clearance).⁶³ Con la preautorización, un widget resuelto también emite una 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 a los visitantes saltarse los desafíos del WAF en todas las solicitudes posteriores a la zona, incluidas las de la API, según el nivel de autorización fijado por el cliente). La cookie no sustituye al token: Cloudflare dice que «is issued to the visitor in addition to the default Turnstile token» (se emite al visitante además del token predeterminado de Turnstile), y la misma página sigue exigiendo la verificación del servidor: «You must call Siteverify to complete your Turnstile configuration.» (debes llamar a Siteverify para completar tu configuración de Turnstile).⁶⁵ Lo que añade la preautorización es un desafío en el borde al que un POST por XHR puede sobrevivir, para un visitante cuya cookie tiene una autorización válida del nivel del desafío o superior. Yo usé lo predeterminado: un widget en el formulario y un token verificado por mi propio servidor.

Qué se desplegó el 3 de noviembre

En ambos sitios creé un widget en modo gestionado mediante la API de Cloudflare, limitado al dominio propio del sitio. El secreto de cada widget pasó de la respuesta de la API al llavero de mi Mac y a las variables del servicio de hosting en el mismo proceso, y nunca a una línea de comandos ni a un archivo.¹²

Este sitio. Un nuevo verificador envía el token a siteverify con la dirección del visitante. Un token ausente, un token de más de 2.048 caracteres, un token rechazado o un fallo de transporte devuelven false, así que el formulario falla cerrado siempre que el secreto esté configurado; sin secreto, como en el desarrollo local y en la batería de pruebas, el formulario funciona como antes.¹² Un token que Cloudflare acepta también tiene que haberse servido en uno de los nombres de host de este sitio, y cuando Cloudflare devuelve la acción del widget, tiene que ser la del propio formulario, como aconseja la guía del lado del servidor; una respuesta sin nombre de host es un rechazo. Así, un token válido generado en otro sitio, o por otro widget, no pasa. Esa verificación entró como un segundo cambio esa misma mañana, compilado desde las 07:20 PST; a las 07:25 PST, tras purgar la caché, un envío con un token CSRF válido de la página en vivo y sin token de Turnstile volvió con 403 de nuevo. Eso prueba que el formulario sigue fallando cerrado después del despliegue; un envío sin token no puede ejercitar la verificación del nombre de host en sí, que descansa en el código y en las pruebas.⁶⁶⁶⁰ Hasta un tercer cambio, ambos widgets y ambos verificadores también admitían localhost, y como una sitekey es pública, un token generado con la mía en el localhost de cualquiera habría pasado tanto siteverify como la verificación del nombre de host. La página de pruebas de Cloudflare desaconseja eso: «Cloudflare recommends that sitekeys used in production do not allow local domains» (Cloudflare recomienda que las sitekeys usadas en producción no permitan dominios locales), y nombra localhost entre ellos. A las 08:12 PST quité localhost de ambos widgets, y ambos verificadores admiten ahora por defecto solo el sitio y su host www, así que la verificación admite los nombres de host propios de este sitio y nada más; el desarrollo local nombra sus nombres de host en una configuración. Tras ese cambio, ambos sitios volvieron a pasar las mismas verificaciones en vivo, a las 08:15 y a las 08:18, hora del Pacífico: el widget en la página y un envío sin token rechazado con un 403. Ninguna verificación en vivo puede ejercitar la regla del nombre de host en sí, porque un token ausente o basura falla antes de que se lea el nombre de host; esa regla descansa en la configuración del widget, el código y las pruebas.⁴⁶⁶⁷ El orden de verificaciones del controlador es ahora CSRF, luego Turnstile y luego el envío, detrás del mismo limitador por dirección que antes. Ambos rechazos devuelven el propio fragmento de error de la página con un 403, y HTMX no inserta por defecto una respuesta 4xx en la página, así que el formulario necesita un manejador que deje pasar un 403. Mi primera versión de ese manejador no funcionó. La adjunté al formulario, pero HTMX dispara el evento en el elemento que recibe la respuesta, y en esta página ese elemento es el hermano del formulario, así que el evento nunca llegaba al manejador y una persona rechazada seguía sin ver nada. Una segunda revisión del borrador de este post lo detectó leyendo el HTMX empaquetado frente a la plantilla. El arreglo, un cuarto cambio esa mañana, pone el listener en el body de la página, limitado al recuadro de respuesta, y una prueba verifica que se renderiza. A las 08:21 PST, tras ese despliegue, ejecuté el formulario en el Chromium de Playwright con el token del widget reemplazado por una cadena basura: el recuadro de respuesta mostró «error: Verification failed. Reload the page and try again.» (error: falló la verificación; recarga la página e inténtalo de nuevo), y no se envió nada, porque siteverify rechaza un token basura antes de que el controlador llegue al envío.⁶⁸ El viejo rechazo CSRF, el 403 en JSON que HTMX nunca mostraba, ya no existe. El formulario reinicia su propio widget después de cada solicitud HTMX, nombrando el contenedor del widget tal como lo recibe la llamada de reinicio de Cloudflare, así que un reintento lleva un token nuevo, porque cada token es de un solo uso y vive 300 segundos.¹²⁶⁰⁶⁹ La guía del lado del cliente de Cloudflare da la razón y la llamada: «To reset the widget if the given widget timed out or expired, you can use the function:» (para reiniciar el widget si se agotó su tiempo o venció, puedes usar la función:) turnstile.reset(widgetId);.⁶⁹ Mi primera versión llamaba al reinicio sin argumento, algo que la guía no documenta; una cuarta ronda de revisión lo detectó, la llamada nombra ahora el contenedor en ambos sitios, y una verificación en el navegador el 3 de noviembre envió un token basura en cada formulario, vio el rechazo y luego encontró un token nuevo en el campo oculto: en menos de ocho segundos en el sitio del estudio, en menos de veinticinco en este, donde el widget volvió a ejecutar primero su desafío.¹² El div del widget y el script solo se renderizan cuando la clave del sitio está configurada. Pasan once pruebas: sin secreto, envía como antes; con secreto, el controlador rechaza un token ausente antes de cualquier envío y rechaza un token rechazado, un token aceptado envía, y CSRF sigue ejecutándose primero; y el verificador acepta el nombre de host de este sitio y rechaza otro nombre de host, localhost por defecto, otra acción o ninguna.¹²⁶⁶⁴⁶

El sitio del estudio. El honeypot sigue delante. Un campo oculto lleno sigue respondiendo con el mensaje de éxito y no guarda nada, así que los bots más baratos nunca cuestan una llamada a Cloudflare. Luego viene Turnstile, y un token ausente, rechazado o imposible de verificar recibe un 403 con el fragmento de error. Luego la validación, la inserción en la tabla de mensajes y la notificación.¹² Su verificador revisa el nombre de host (ahora solo los dos nombres de host propios del sitio) y la acción del mismo modo; ese cambio se desplegó a las 07:19 PST, y a las 07:22 PST la página en vivo llevaba el widget y la clave del sitio, un envío sin token y un envío con token basura volvieron con 403, y un envío al honeypot siguió respondiendo 200.⁶⁶ Antes de desplegar, ejecuté el controlador en local contra las claves de prueba documentadas por Cloudflare. Con el secreto que siempre aprueba, un envío sin token volvió con 403 y el token ficticio pasó Turnstile y llegó a la validación; con el secreto que siempre rechaza, ambos volvieron con 403; el honeypot respondió 200.¹²⁶⁷ La página de pruebas de Cloudflare explica por qué un token ficticio no puede pasar en producción: «Production secret keys: Only accept real tokens, reject dummy tokens.» (claves secretas de producción: solo aceptan tokens reales y rechazan los ficticios).⁶⁷

La verificación en vivo. Más temprano esa mañana, después de que el despliegue de cada sitio terminara con éxito y de una purga de caché, a las 06:35 PST, cada página de inicio llevaba un div del widget, una etiqueta de script de Turnstile y la clave del sitio, y la política en vivo de cada zona listaba el origen de desafíos en frame-src. Un envío al formulario de este sitio con un token CSRF basura volvió con 403, pero eso es la verificación CSRF rechazándolo, y no prueba nada sobre Turnstile. La verificación de Turnstile en sí la probé a las 06:43 PST: un envío con un token CSRF válido tomado de la página en vivo y sin token de Turnstile volvió con 403 y el mensaje «error: Verification failed. Reload the page and try again.», y el mismo envío con un token de Turnstile basura también volvió con 403. Así que el secreto está en el servicio y la verificación se ejecuta después de CSRF. En el sitio del estudio, un envío sin token y un envío con token basura volvieron ambos con 403, y un envío al honeypot volvió con 200 sin guardar ni enviar nada.⁷⁰

La verificación en el navegador. En un Chromium real controlado por Playwright, el widget se renderizó en ambas páginas, el script de Turnstile se cargó y el campo oculto cf-turnstile-response tenía un token de 730 caracteres en ambas páginas en menos de seis segundos.⁷⁰ Eso prueba menos de lo que parece. La página de pruebas de Cloudflare advierte que «Automated testing suites (like Selenium, Cypress, or Playwright) are detected as bots by Turnstile» (Turnstile detecta como bots las baterías de pruebas automatizadas, como Selenium, Cypress o Playwright), y solo siteverify decide si un token pasa.⁶⁷ Lo que prueba la verificación es que el widget funciona bajo ambas políticas y llena su campo. Lo que no he hecho es la prueba que más le importa a un lector de este post: una persona que llena el formulario y recibe una respuesta. Esa prueba envía un correo, así que me toca a mí hacerla, y todavía no la he hecho.

7. Para qué sigue sirviendo el límite de tasa

Turnstile reemplazó a los límites de tasa como puerta. No los reemplazó como cerca. Una verificación de bots responde quién; algo tiene que seguir respondiendo cuántos, porque cada envío que llega a la verificación con un token no vacío de tamaño válido cuesta ahora una llamada a la API siteverify de Cloudflare, y cada envío que pasa sigue costando un envío de correo.¹² La propia guía del lado del servidor de Cloudflare incluye el límite de tasa entre sus recomendaciones para la llamada a siteverify en sí: «Rate limit to protect against validation flooding.» (aplica un límite de tasa para protegerte de las avalanchas de validaciones).⁶⁰ Mis dos límites se quedan: la regla del borde de 3 envíos cada 10 segundos por dirección y por centro de datos, y el limitador de la aplicación de cinco envíos por minuto por dirección.⁹¹⁷

La regla del borde merece una descripción honesta ahora que sé cómo cuenta. Cloudflare expone el diseño sin rodeos: «Cloudflare tracks request rates by maintaining separate counters for each unique combination of values in a rule’s characteristics» (Cloudflare sigue las tasas de solicitudes manteniendo contadores separados para cada combinación única de valores de las características de una regla), y «Cloudflare does not support global rate limiting counters across the entire network.» (Cloudflare no admite contadores globales de límite de tasa en toda la red).⁶ Una dirección que llega a mi zona por dos centros de datos recibe dos cupos, y los envíos del escáner del 2 de noviembre sí llegaron por dos; esa es mi explicación más sólida de por qué la regla guardó silencio, coherente con los totales por minuto pero no probada por ellos.⁵ Añade la advertencia de precisión de Cloudflare, que las reglas «are not designed to allow a precise number of requests to reach your origin server» (no están diseñadas para dejar llegar un número preciso de solicitudes al servidor de origen), y la mejor descripción de la regla es un presupuesto nominal, no un tope probado: 3 envíos del formulario cada 10 segundos por dirección y por centro de datos, el equivalente nominal de 18 por minuto, aplicado de forma aproximada.⁴⁸⁹ En el plan Free es además la única regla de límite de tasa que tengo, con un periodo fijo de 10 segundos y conteo solo por IP.⁴⁸

Un detalle del plan Free importa si te tentó, como a mí, convertir el propio límite de tasa en el desafío. La página de parámetros de Cloudflare dice que en los planes Free, Pro y Business una regla de límite de tasa con acción de desafío siempre limita el caudal en lugar de mantener una duración, y que «When visitors pass a challenge, their corresponding request counter is set to zero.» (cuando los visitantes superan un desafío, su contador de solicitudes vuelve a cero).⁷¹ Un desafío sobre el POST por XHR del formulario también fallaría por la razón de la sección 6.⁶³ Así que la regla del borde sigue siendo un bloqueo, y el desafío vive en el widget.

El limitador de la aplicación necesita el arreglo que pide su fuga: un almacén de contadores con un incremento atómico, para que dos envíos no puedan leer el mismo conteo, y una ruta de fallo que no divida el conteo entre procesos. El código actual, una lectura de KV seguida de una escritura aparte con un respaldo por proceso, no ofrece ninguna de las dos cosas, así que esto es un cambio de almacén y no un parche de una línea.¹⁷³ Con Turnstile como condición añadida para cada envío que podría llegar a la bandeja, un envío que la fuga deje pasar todavía tiene que llevar un token que Cloudflare acepte, así que la fuga cuesta volumen y dinero, y la decisión de quién puede enviar ya no descansa en el conteo. Un limitador es un presupuesto. Un presupuesto que se desvía en 47 en una avalancha es un mal presupuesto, pero nunca fue un guardia.

La guía de autenticación de OWASP plantea la misma estratificación en sus propios términos. Trata un CAPTCHA «as a defense-in-depth control to make brute-force attacks more time-consuming and expensive, rather than as a preventative.» (como un control de defensa en profundidad para que los ataques de fuerza bruta lleven más tiempo y cuesten más, y no como una medida preventiva).⁷² Y su guía contra el relleno de credenciales señala 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» (la mayoría de las herramientas usadas en estos ataques hacen solicitudes POST directas al servidor y leen las respuestas, pero no descargan ni ejecutan JavaScript).⁵⁰ Mis dos escáneres sí descargaron las páginas del sitio, la vía más probable por la que llegaron a tener tokens CSRF válidos. Un cliente que envía el formulario sin ejecutar el widget no tiene ningún token de Turnstile que enviar, y ambos formularios rechazan ahora un envío sin él: en este sitio, un envío con un token CSRF válido y sin token de Turnstile volvió con 403, y lo mismo un envío sin token en el sitio del estudio.⁷⁰

La lista de verificación

Para un formulario de contacto detrás de Cloudflare, en el orden en que lo haría ahora:

1. Pon una verificación de bots en el formulario y verifica cada token en el servidor. En palabras de la propia Cloudflare: «The client-side widget alone does not protect your forms.» (el widget del lado del cliente por sí solo no protege tus formularios).⁶⁰ Verifica también el nombre de host y la acción en la respuesta, como aconseja la misma página, para que un token generado en otro lugar no pase, y deja los dominios locales fuera de la sitekey de producción, porque «Cloudflare recommends that sitekeys used in production do not allow local domains».⁶⁰⁶⁶⁶⁷
2. Falla cerrado. Un token ausente, demasiado largo, rechazado o imposible de verificar es un rechazo, porque «Tokens can be forged.» (los tokens pueden falsificarse).⁶⁰¹²
3. Reinicia el widget después de cada envío. Los tokens son de un solo uso y valen 300 segundos, así que un reintento sin reinicio es un reintento con un token gastado.⁶⁰⁶⁹
4. Permite el origen de desafíos en ambas directivas de la CSP. Cloudflare pide script-src y frame-src para https://challenges.cloudflare.com, y una política con solo default-src 'self' bloquea el iframe.⁶²¹²
5. No pongas un desafío gestionado en un formulario que envía con XHR o fetch. Cloudflare dice que la página de desafío «fails when the browser expects a non-HTML response» (falla cuando el navegador espera una respuesta que no es HTML), y un envío HTMX es ese tipo de solicitud.⁶³
6. Devuelve un error que una persona pueda ver. Mi rechazo CSRF era un 403 en JSON que el formulario HTMX nunca mostraba, así que una persona con un token vencido habría hecho clic en Enviar y no habría visto nada, y mi primer arreglo escuchaba en el formulario mientras HTMX dispara el evento de inserción en el destino de la respuesta, el hermano del formulario, así que prueba el rechazo en un navegador.¹²⁶⁸
7. Mantén el honeypot delante de la verificación de bots. Atrapó 42 de 52 envíos en el sitio de mi estudio al costo de un campo oculto y un if.⁷²⁵
8. Mantén el límite de tasa, y dimensiónalo como tope de costo, no como puerta. Cloudflare lo cuenta por dirección y por centro de datos, y el escáner del 2 de noviembre llegó por dos, la razón más probable de que nunca se activara, aunque los totales por minuto no pueden probarlo.⁶⁵
9. Respalda el limitador de la aplicación con un almacén que incremente de forma atómica. El mío leía el conteo y lo volvía a escribir en una solicitud aparte, lo reiniciaba a uno cuando fallaba su segunda lectura, recurría a la memoria de un solo proceso cuando fallaba KV, y dejó pasar 47 y 9 envíos por encima de su propio techo; los logs no pueden decir qué ruta tuvo la fuga.¹⁷³
10. No confíes en una regla de agente de usuario para detener a un escáner. Ambos escáneres enviaron una cadena simple de Chrome, al menos 69.322 veces el 30 de octubre y 9.725 veces el 2 de noviembre.³²⁴¹
11. Cuenta los correos en el proveedor de correo, no en el formulario. Mi controlador responde 200 en sus rutas de fallo, y el evento email.sent de Resend solo significa que «the API request was successful» (la solicitud a la API tuvo éxito); el campo last_event de un correo consultado dice qué pasó después.²⁴²⁸⁷³
12. Consulta los análisis antes de que pase un mes. Los conjuntos de datos adaptativos de Cloudflare conservan «at least 31 days of data on every plan» (al menos 31 días de datos en todos los planes).²⁷
13. Vuelve a contar cuando la ventana se haya cerrado. Mis notas escritas minutos después de la avalancha del 30 de octubre se quedaron cortas en los envíos del formulario, porque Cloudflare no había terminado de ingerir los últimos minutos.¹⁶
14. Trata un bloqueo de dirección como limpieza. El mío llegó unos 50 minutos después del primer envío del formulario el 30 de octubre y 8 minutos después del inicio del escaneo el 2 de noviembre, y ningún envío de ninguno de los dos días llegó después del minuto del bloqueo: 101 antes el 30 de octubre, y 26 antes y 5 dentro el 2 de noviembre.¹¹⁹²

Qué podría cambiar

Son condiciones, no pronósticos. Cada una nombra lo que tendría que pasar y lo que yo haría al respecto.

Si un escáner empieza a superar los desafíos gestionados. Las verificaciones de Turnstile se ejecutan en el navegador y buscan automatización; una herramienta que ejecute un navegador completo lo bastante bien como para superarlas, a escala, convertiría el widget en un costo más para ella y no en un muro. La señal serían envíos del formulario con tokens que siteverify acepta, desde direcciones que también envían cadenas de inyección en la cabecera User-Agent. Batchelder escribió la versión honesta de esto para los honeypots en 2007: «If and when they do, we can switch back to CAPTCHAs.» (si llegan a hacerlo, y cuando lo hagan, podemos volver a los CAPTCHA).⁴⁹ Mi alternativa sería la misma en espíritu, un desafío más fuerte, y mientras tanto el honeypot y los límites de tasa siguen en pie.

Si añado una verificación en el borde con preautorización. Cloudflare recomienda la preautorización de Turnstile para las solicitudes que no pueden mostrar una página de desafío, y una cookie cf_clearance permite a un visitante «bypass WAF Challenges on all subsequent requests on the zone, including API requests» (saltarse los desafíos del WAF en todas las solicitudes posteriores a la zona, incluidas las de la API).⁶⁵⁶³ Si la adopto, el borde podría desafiar el propio POST del formulario sin romper HTMX para un visitante cuya cookie tenga una autorización válida del nivel del desafío o superior, y la página de CSP de Cloudflare añade un requisito para ese modo: «your connect-src directive must include ‘self’.» (tu directiva connect-src debe incluir ‘self’).⁶² La cookie llega «in addition to the default Turnstile token» (además del token predeterminado de Turnstile), y siteverify sigue siendo obligatorio, así que el desafío del borde sería una segunda verificación delante de la de mi servidor, no un reemplazo.⁶⁵ No lo he hecho, y el post describe el diseño de widget y siteverify que está en producción.

Si exporto el log de Resend para las dos ventanas. Cada conteo de correos de este post es un techo, porque un 200 del formulario es un envío, o un fallo al que mi controlador también responde con 200.²⁴ El endpoint de consulta de Resend devuelve un last_event para cada correo, como delivered, y su lista de eventos distingue «sent - The email was sent successfully.» (enviado: el correo se envió con éxito) de «delivered - Resend successfully delivered the email to the recipient’s mail server.» (entregado: Resend entregó el correo al servidor de correo del destinatario).⁷³⁷⁴ Con esa exportación, 101 y 31 se convertirían en conteos exactos, y solo podrían bajar.

Si una persona envía el spam a mano. Turnstile pregunta si hay un navegador y, a veces, una persona. No pregunta por qué. Una persona a la que pagan por pegar un discurso de venta en formularios de contacto puede superarlo, y también los remitentes de generación de leads del sitio de mi estudio si hay una persona detrás. Para ese caso, las defensas son las de siempre: un límite de tasa para el volumen y mi propio criterio en la bandeja de entrada.

Si el goteo de Tor necesita una respuesta día a día. La lista de salidas que revisé es la que descargué el 3 de noviembre, y el servicio CollecTor del Tor Project conserva listas pasadas.⁵³⁵⁵ Si lo consulto para los ocho días, la atribución a Tor descansaría en las listas de los días en que llegaron los envíos, no en el código de Cloudflare más la lista del 3 de noviembre. Cloudflare también ofrece Onion Routing en todos los planes, que sirve a los usuarios de Tor directamente a través de la red Tor; Cloudflare dice que con él «Human Tor users and bots can be distinguished by our Onion services, such that interactive challenges are only served to malicious bot traffic.» (nuestros servicios Onion pueden distinguir a los usuarios humanos de Tor de los bots, de modo que los desafíos interactivos solo se sirven al tráfico de bots maliciosos).⁷⁵ No lo he activado, y querría medir el tráfico de Tor del sitio del estudio después de Turnstile antes de hacerlo.

Conclusiones clave

Si tienes un formulario de contacto:

• Un token CSRF y un límite de tasa juntos siguen dejando que un escáner te escriba. Mis dos escáneres tenían tokens válidos, y mi limitador dejó pasar 101 y 31 envíos.¹²
• Verifica en el servidor el token de una verificación de bots, falla cerrado y reinicia el widget después de cada solicitud; el widget por sí solo «does not protect your forms.» (no protege tus formularios).⁶⁰
• Prueba tu limitador bajo carga y bajo fallos, no de una solicitud en una. Un contador de leer y luego escribir con un respaldo por proceso dejó pasar 18 envíos en un minuto configurado para permitir cinco.¹¹⁷
• Mantén el honeypot. Es el filtro más barato de la pila, y atrapó el 80,8 % de estos envíos en el sitio de mi estudio, en ocho días, antes de que el controlador revisara una dirección, guardara una fila o enviara un correo.⁷²⁵

Si gestionas el borde del sitio:

• Sabe qué cuenta tu límite de tasa. En Cloudflare cada regla cuenta por centro de datos, y un escáner que llega por dos recibe dos contadores.⁶⁵
• Sondea tus propias reglas y lee después los eventos de firewall. Once eventos de firewall de mi prueba me dijeron más sobre la regla que un día razonando sobre por qué había guardado silencio.¹⁸
• No desafíes un POST por XHR o fetch con una página de desafío; Cloudflare documenta que falla y recomienda la preautorización para ese caso.⁶³
• Espera que las reglas de agente de usuario solo atrapen a las herramientas honestas. Los escáneres de aquí enviaron una cadena de navegador; mi prueba con curl provocó desafíos.³²³⁹

Si eres quien lee la bandeja de entrada:

• Cuando la bandeja se llene, revisa el remitente antes que el asunto. Tres de mis flujos de correo comparten una dirección de remitente, y por eso mi primera suposición fue errónea.²³
• Trata los 200 de un formulario como un techo de correos, no como un conteo, hasta que el log del proveedor de correo diga otra cosa.²⁴²⁸
• Lee los mensajes guardados antes de apagar el notificador. El mensaje de un cliente real se quedó una vez sin leer durante una semana, y ese mensaje es la razón de que el formulario del estudio me envíe correos.²⁵

Preguntas frecuentes

¿Por qué mi formulario de contacto recibe spam a pesar de Cloudflare?

Lo más probable es que nada delante del formulario le pregunte a cada envío si lo mandó una persona. Las reglas personalizadas de Cloudflare comparan direcciones, redes, rutas y cadenas de agente de usuario, y sus límites de tasa cuentan solicitudes por dirección y por centro de datos; un escáner que envía un agente de usuario de navegador, carga primero la página y envía a un ritmo moderado las supera todas. En mi sitio, dos escáneres hicieron exactamente eso y metieron 101 y 31 envíos, y el spam del sitio de mi estudio llegó casi siempre a razón de un envío por dirección en los ocho días que medí, algo que ningún conteo por dirección puede atrapar.⁹⁶¹²⁷

¿Un límite de tasa detiene a los bots?

Un límite de tasa acota lo rápido que puede ir una dirección; no distingue un bot de una persona. La propia documentación de Cloudflare dice que sus reglas «are not designed to allow a precise number of requests to reach your origin server» (no están diseñadas para dejar llegar un número preciso de solicitudes al servidor de origen) y que los contadores no se comparten entre centros de datos. Mi regla del borde nunca se activó con ninguno de los dos escáneres, y el limitador de mi aplicación, configurado en cinco por minuto, dejó pasar 18 en un minuto: su contador es una lectura seguida de una escritura aparte, una segunda lectura fallida lo reinicia a uno y un respaldo por proceso toma el control cuando falla el almacén; cualquiera de esas rutas puede dejar pasar envíos de más.^48641173

¿Basta con un campo honeypot?

Basta para los bots que llenan el campo oculto, y en el sitio de mi estudio eso fue el 80,8 % de estos envíos: el mío atrapó 42 de 52 envíos en ocho días, incluido, según la hora en que llegaron, cada envío desde una salida de Tor. No hace nada contra un remitente que deja vacío el campo oculto, y los 10 que dejó pasar, guardados y por tanto como máximo 10 correos, hicieron exactamente eso.⁷²⁰ Ned Batchelder, al describir la técnica en 2007, lo dijo: «In theory, it is possible for a spambot to defeat any of these measures.» (en teoría, un spambot puede vencer cualquiera de estas medidas).⁴⁹

Turnstile frente a un CAPTCHA: ¿cuál es la diferencia?

Un CAPTCHA clásico le pide al visitante que resuelva un acertijo. Turnstile ejecuta «a series of small non-interactive JavaScript challenges to gather signals about the visitor or browser environment» (una serie de pequeños desafíos de JavaScript no interactivos para reunir señales sobre el visitante o el entorno del navegador), y en modo gestionado solo muestra una casilla cuando el riesgo del visitante lo pide, con «No images or text to decipher.» (sin imágenes ni texto que descifrar).²¹⁵⁸ Cloudflare dice que sus desafíos no usan «CAPTCHA puzzles or visual tests like selecting objects or typing distorted characters.» (acertijos CAPTCHA ni pruebas visuales como seleccionar objetos o escribir caracteres distorsionados).⁷⁶ Ambos siguen necesitando que el servidor verifique el resultado; para Turnstile, esa es la llamada a siteverify.⁶⁰

¿Por qué la protección CSRF no detiene el spam?

Una defensa CSRF bien implementada sirve para impedir que otro sitio haga que el navegador de un visitante envíe tu formulario. Mi token es más débil que eso: no tiene estado y va firmado, vale una hora y no está ligado a una sesión, una cookie ni una dirección, así que solo prueba que el cliente tiene un token emitido por mi sitio en la última hora, no de dónde vino la solicitud. Ninguno de los dos tipos detiene a un cliente que carga tu página y envía el formulario por sí mismo, porque cargar la página es la forma en que un cliente obtiene un token válido, y ambos escáneres reunieron tokens válidos; la verificación rechazó cuatro de sus envíos en las dos avalanchas.¹⁵¹²

¿Cómo distingo en los logs un escáner de una persona?

Mira todo lo que hizo la dirección, no solo el formulario. Mis dos escáneres rastrearon miles de rutas, pusieron cadenas de inyección SQL en las rutas y en la cabecera User-Agent, enviaron un agente de usuario de Chrome en la mayoría de las solicitudes y uno que decía ser Googlebot en algunas que la regla de bots verificados de Cloudflare no aceptó, y enviaron el formulario en ráfagas de decenas a cientos por minuto.^31324441 Las cargas basadas en tiempo como sleep(15) y waitfor delay '0:0:15' pertenecen a familias de sondas documentadas.³³⁷⁷ Una persona envía un mensaje, desde una página que de verdad leyó, y no le pide a tu servidor que se duerma.

¿Turnstile recopila datos personales?

Cloudflare no dice que no recopile ninguno. Su anexo de privacidad de Turnstile nombra las señales que procesa, «such as client IP address, TLS Fingerprint, User-Agent Header and Sitekey and associated origin» (como la dirección IP del cliente, la huella TLS, la cabecera User-Agent y la sitekey con su origen asociado), dice que el propósito es «solely to detect and block bots» (solo detectar y bloquear bots), y dice que Cloudflare es responsable del tratamiento de esas señales para mejorar su detección de bots. Su descripción general dice que Turnstile «does not access, store, or transmit user communications, form entries, or other page inputs.» (no accede a las comunicaciones del usuario, lo que se escribe en los formularios ni otras entradas de la página, ni las guarda ni las transmite).²²²¹ Así que ve datos de conexión, no lo que escribe una persona.

Relacionado en este sitio. El modo auto de Claude Code no es una frontera de seguridad plantea el mismo argumento sobre otro control: un clasificador que juzga cada acción no es el muro. Agents.txt no es control de acceso traza la línea entre declararles una política a los bots y hacerla cumplir. Fatiga de alertas: 82 correos en un día de mi monitor de seguridad cuenta el escáner del 2 de noviembre desde el lado de mi monitor: un bloqueo ocho segundos después de su primer hallazgo, ocho minutos después del inicio del escaneo, y cero correos sobre él. Lo que ejecuto antes de dormir es otro tipo de rutina de operaciones, una revisión nocturna de 15.000 páginas por estado, tiempo de respuesta y caché, y Qué se rompe realmente cuando ejecuta agentes de IA sin supervisión cataloga los modos de fallo de las sesiones de agentes sin supervisión, el tipo de automatización que opera mi infraestructura.

Fuentes

Notas del autor sobre los datos: cada conteo de mis propios sistemas proviene de la GraphQL Analytics API de Cloudflare para las dos zonas (los conjuntos de datos de solicitudes y de eventos de firewall), la tabla de mensajes del sitio del estudio, el log de mi monitor y el código de los dos formularios, todo guardado el 3 de noviembre de 2026 y convertido en un registro mediante un script. Las horas están en UTC salvo que se marquen como PDT o PST. Ninguna dirección, identificador de regla o de lista, clave ni ruta del sistema de archivos de esa evidencia aparece en este post.