Captcha

Un CAPTCHA es una prueba diseñada para distinguir si lo que hay al otro lado de un formulario es una persona o un programa automatizado.

La idea es pedir algo que a un humano le resulte fácil y a un script incómodo: leer un texto distorsionado, elegir las imágenes que contienen un objeto determinado o, simplemente, comportarse de una forma que un motor de puntuación considere humana sin llegar a mostrar ningún reto.

Su propósito no es autenticar a nadie. Es encarecer una acción repetitiva lo suficiente como para que hacerla un millón de veces deje de merecer la pena.

Para qué se usa

Frenar la creación masiva de cuentas. El caso clásico: un script que registra miles de cuentas para abusar de un plan gratuito, para publicar spam o para dejarlas ahí esperando.

Ralentizar los ataques contra credenciales. Frente al credential stuffing no consigue que una contraseña robada deje de ser válida: consigue que probar millones de ellas sea lento.

Proteger todo aquello cuya ejecución cuesta dinero. Endpoints de búsqueda, correos de alta, envío de SMS, restablecimiento de contraseña. Cada uno de ellos es una manera de gastar el presupuesto del operador desde fuera.

Evitar que los formularios se conviertan en un relé de spam. Los formularios de contacto y las cajas de comentarios son objetivos automatizados, y siempre lo han sido.

Dónde encaja y dónde no

Un CAPTCHA es un control de fricción. Va al lado del rate limiting, que hace el mismo trabajo por otra vía, y no lo sustituye: el rate limiting actúa sobre peticiones que no llegan a pasar por ningún formulario, como una API a la que se llama directamente.

Conviene ser claro sobre sus límites, porque a menudo se despliega como si fuera una frontera:

Se puede resolver. Existen servicios comerciales que responden retos a gran escala, y el reconocimiento de imágenes moderno resuelve muchos de los rompecabezas clásicos. A una automatización decidida y bien financiada no la detiene; a la oportunista, sí.

Solo está donde tú lo pongas. Un reto en el formulario web y ninguno en el endpoint de la API que hay detrás no protege nada, y ese hueco es uno de los hallazgos más habituales de su categoría.

Les cuesta algo a los usuarios reales. Cada reto es fricción para gente que iba a completar el formulario legítimamente, y cae con más dureza sobre quienes usan tecnología de apoyo. La accesibilidad no es aquí una nota al pie: un reto solo visual deja fuera a los usuarios que no pueden verlo.

Un ejemplo

Un sitio permite que cualquiera se registre para acceder a contenido restringido.

Sin un reto, un script envía el formulario de registro de forma continua y llena la base de datos de cuentas que solo existen para publicar enlaces.

Con un reto, ese mismo script tiene que resolver algo en cada intento. El coste por cuenta deja de ser cero y, para la mayoría de los operadores, ahí se acaba la campaña.

La cuenta que un atacante decidido consigue crear de todos modos es otro problema, y el control para esa es lo que ocurre después del registro, no durante.

Dónde aparece esto en una auditoría

Se repiten dos hallazgos. El primero es el reto que protege la página y no la petición: el endpoint que hay debajo acepta una llamada directa sin token alguno. El segundo es el reto que se valida en el lado del cliente, donde la respuesta se comprueba en el navegador y el servidor da el resultado por bueno. Los dos son el mismo error con distinto disfraz, que consiste en tratar un control como si fuera una frontera porque en pantalla lo parece.