¿Por qué molestarse en validar el nombre de host para una respuesta de Google Recaptcha?

7

Recaptcha de Google tiene hostname de validación "baked-in". Cuando un usuario envía una respuesta de Recpatcha, el dominio del que se obtuvo la respuesta se valida en la lista blanca de dominios que proporcionó al configurar Recaptcha.

Sin embargo, si está utilizando Recaptcha con varios dominios, tiene la opción de desactivar la validación de hostname predeterminada de Google y manejarlo usted mismo ( enlace ).

Google acompaña esto con una advertencia prominente de que la no validación de hostname para cualquier respuesta dada lo abre a una vulnerabilidad de seguridad. Pero teniendo en cuenta lo fácil que es falsificar el hostname , no veo cómo este alguna vez proporcionó ningún grado de mejora de la seguridad.

Una prueba simple me demostró lo fácil que es falsificar el valor hostname que usa Google para validar el origen de la respuesta Recaptcha:

$ sudo nano /etc/hosts
127.0.0.1    spoofedhostname.com

Y luego, cuando envié una respuesta de prueba Recaptcha, el resultado que obtuve fue el siguiente:

{
    "success": true,
    "challenge_ts": "2016-12-24T14:15:22Z",
    "hostname": "spoofedhostname.com"
}

¿Por qué molestarse con la validación del nombre de host?

  1. Se sabe que la validación del nombre de host es inútil en vista de lo fácil que es falsear.
  2. Esto parece tener algo que ver con evitar que un atacante robe su clave pública de Recaptcha y luego genere un montón de respuestas de Recaptcha válidas, que podrían almacenar y luego usar cuando automatizan un ataque en puntos finales sensibles ( /login ,% código%). Teóricamente, esto podría usarse en algún tipo de ataque de fuerza bruta, pero en realidad no tiene sentido considerando que los tokens de respuesta expiran después de 1 minuto. Y aún tendría que resolver manualmente todos los Recaptchas, que simplemente podría hacer en el dominio real. Y, nuevamente, podrían fácilmente falsificar su dominio incluso si están haciendo validación de /reset-password .

Para mí, no tiene ningún sentido, pero teniendo en cuenta que es un producto de Google, debo pensar que sus ingenieros de seguridad saben algo que yo no.

¿Qué me estoy perdiendo?

    
pregunta AJB 24.01.2017 - 21:12
fuente

3 respuestas

6

Puede tener algo que ver con las personas que insertan tus captchas en un sitio que configuraron, y que utilizan los captchas resueltos para enviar spam a tu sitio.

Por ejemplo, configure un sitio y ofrezca algo gratis (películas / software pirateado, pornografía, etc.) pero solicite el captcha. Internamente, esto es en realidad su captcha, y cualquier captcha resuelto se transmite a un spambot que apunta a su sitio. Esto le da a un atacante un acceso rentable a la resolución de captcha humana en comparación con las granjas de captcha convencionales.

La validación del nombre de host evitaría que el JS de captcha se cargue en un sitio no autorizado.

Actualización: Recientemente he implementado una demostración de omitir esto al mostrar el captcha en el sitio original en un navegador sin cabeza y luego usar Websocket magic para transmitirlo en mi sitio "cebo" (en este caso, un simple acortador de URL que pregunta por el captcha antes de redirigir al sitio de destino). Esto requería una cantidad considerable de RAM (cada instancia de Firefox era de aproximadamente 500 MB) en comparación con el rendimiento de captcha directamente en el sitio de cebo, por lo que esta función de verificación del nombre de host es definitivamente un gran problema para los spammers.

    
respondido por el André Borie 14.02.2017 - 04:55
fuente
2

Hay dos teclas. La clave del sitio y la clave secreta. Ambos se le dan al administrador web al configurar reCAPTCHA.

Para la integración del lado del cliente, le darán la api.js y el fragmento, y la clave del sitio para insertar en el sitio web.

"Cuando sus usuarios envíen el formulario donde integró reCAPTCHA, obtendrá como parte de la carga útil una cadena con el nombre" g-recaptcha-response ". Para verificar si Google ha verificado ese usuario, envíe un Solicite GET con estos parámetros: "< - así que si estoy falsificando la URL, su servidor nunca obtiene la respuesta g-recaptcha. El secreto nunca se envía, el valor de 'g-recaptcha-response' nunca se envía, y la ip remota nunca se envía.

Me estoy perdiendo cómo el hacker está obteniendo la clave secreta del servidor web. Eso solo sería enviado directamente a google.

------ Explicación adicional de lo que estoy viendo.

La clave del sitio se ve fácilmente en el código html de su sitio. Sin embargo, no se puede acceder ni falsificar la clave secreta almacenada en su servidor. No sé cómo el pirata informático obtendría acceso a la clave secreta para completar la autenticación bidireccional con google.

Creo que esto es lo que te estás perdiendo. (la autenticación de dos vías)

Referencias: enlace (video sobre la configuración de Google ReCAPTCHA.

enlace

También: Google reCAPTCHA exploits, hay algunas inseguridades muy interesantes que involucran la incorporación de reCAPTCHA de otra persona en un sitio web para autenticarse automáticamente cuando hacen clic en cualquier parte de una página.

(la reputación es demasiado baja para publicar más de 2 enlaces)

    
respondido por el WorWin 09.02.2017 - 22:25
fuente
-1

La validación del nombre de host se usa como una medida anti-bot. Si está ejecutando su cosechadora CAPTCHA en localhost a través de la URL en la que se debe recopilar CAPTCHA, ya no podrá enviar solicitudes directamente al sitio desde su computadora, ya que serán redirigidas a localhost. Sin embargo, hay cosas que puedes hacer para solucionar esto.

    
respondido por el Tron 24.08.2018 - 12:48
fuente

Lea otras preguntas en las etiquetas