Scarnox · Blog

Cómo funciona reCAPTCHA v2 y cómo resolverlo (próximamente)

reCAPTCHA v2 es el captcha clásico de Google. Muestra una casilla con la etiqueta "No soy un robot" y, cuando no está seguro del visitante, añade un desafío de imágenes. Un solver para él tiene que producir un token de respuesta válido que el sitio pueda verificar con Google. El soporte de reCAPTCHA v2 en Scarnox llegará pronto. Esta guía explica cómo funciona el widget, los enfoques generales que la gente usa hoy y qué esperar de un solver basado en tokens.

Scarnox todavía no resuelve reCAPTCHA v2 en directo. El único tipo de tarea activo hoy es PopularCaptcha, sin proxy. Si tu proyecto necesita reCAPTCHA v2 ahora mismo, los enfoques de abajo son las opciones realistas.

Cómo funciona el widget

La página incrusta un elemento contenedor con un atributo data-sitekey. Esa sitekey identifica el sitio ante Google. Cuando el widget se carga, ejecuta comprobaciones en el navegador, observando el comportamiento del visitante, las cookies y el historial, y envía una evaluación de riesgo a Google.

Si la evaluación es de riesgo bajo, la casilla se marca sola y el widget escribe un token en un campo oculto llamado g-recaptcha-response. Si la evaluación es de riesgo más alto, el visitante ve un desafío de imágenes, como seleccionar casillas que contengan un objeto concreto. Superar el desafío también escribe el token.

El backend del sitio envía entonces ese token al endpoint de verificación de Google, junto con la clave secreta del sitio. Google responde con éxito o fallo. Como la verificación se hace en el servidor, un formulario que acepta un token sin comprobarlo con Google no está protegido por reCAPTCHA en absoluto.

Por qué se marca

La casilla es una decisión de riesgo, no un rompecabezas. Los desencadenantes habituales son:

Entender estos desencadenantes importa más que el propio widget. Si tu tráfico no activa la casilla, nunca verás el desafío de imágenes.

Enfoques generales que funcionan hoy

Estos enfoques se usan ampliamente, y son honestos. Reducen la frecuencia con la que aparece un desafío en un trabajo legítimo.

  1. Mantén sesiones reales. Reutiliza las cookies y un perfil de navegador coherente durante una sesión, en lugar de empezar desde cero en cada página.
  2. Dosifica tus peticiones. Un ritmo constante y lento parece mucho más una persona que una ráfaga.
  3. Usa un navegador real para el widget. Un navegador completo con configuración normal tiene menos probabilidades de ser marcado que una configuración headless simplificada. La guía de detección de navegadores headless enumera las señales habituales.
  4. Pide una excepción o una clave de prueba. Si el sitio es tuyo, usa las claves de prueba publicadas por Google en staging. Si no lo es, pide al propietario una lista de permitidos.
  5. Mantén a una persona en el proceso. Para tareas de bajo volumen, una persona puede completar la casilla y pasar el token. Es lento pero fiable.

Estos enfoques no garantizan que nunca aparezca un desafío. Reducen la frecuencia, que es lo que mantiene estable un trabajo legítimo.

Qué hará un solver basado en tokens

Un solver basado en tokens para reCAPTCHA v2 hace lo que PopularCaptcha hace hoy. Toma la sitekey y la URL de la página, produce un token g-recaptcha-response válido y lo devuelve a tu código. Tu código entonces escribe el token en el formulario y lo envía antes de que caduque.

Scarnox documentará el tipo de tarea y los campos adicionales en la referencia de la API cuando se publique el soporte de reCAPTCHA v2. Hasta entonces, no construyas sobre una interfaz supuesta. La forma de la petición será parecida al ejemplo de PopularCaptcha, pero consulta la documentación para los valores exactos.

Lista de comprobación para un trabajo con reCAPTCHA v2

Cuando planifiques un trabajo que toque un formulario con reCAPTCHA v2, revisa estos puntos:

Errores comunes

El fallo más frecuente en una integración con reCAPTCHA v2 es un token que el sitio rechaza aunque parece correcto. Tres causas explican la mayoría de estos casos. La primera es una discrepancia entre la sitekey y la URL de la página: el token está ligado a la página donde se mostró el widget, así que una sitekey tomada de una página y enviada a otra fallará. La segunda es un token caducado. Los tokens son de vida corta, así que un script que resuelve primero y después ejecuta una secuencia lenta de otros pasos enviará un valor caducado. La tercera es la falta de una comprobación del lado del servidor en tu extremo. Si tus pruebas solo confirman que existe un token, no notarás que el paso de verificación está fallando.

Un segundo grupo de errores viene del flujo de trabajo alrededor del widget. Iniciar sesión en una sesión y enviar el formulario desde otra es un error común, porque la verificación puede depender de la sesión que cargó el widget. Reintentar muchas veces seguidas un formulario rechazado también hace que la sesión parezca sospechosa, lo que puede convertir un único desafío en una serie de ellos. Cuando algo falle, haz una pausa, revisa el estado de la página e inténtalo una vez más con valores nuevos.

Scrapea de forma responsable

Si el formulario forma parte de un trabajo de scraping, revisa el robots.txt y los términos del sitio antes de empezar. Mantén el ritmo bajo, y no recopiles datos personales que no necesites. La guía sobre si el web scraping es legal cubre las consideraciones principales.

Próximos pasos