¿Puede el token anti-CSRF evitar el ataque de fuerza bruta?

Question

¿Puede el token anti-CSRF evitar el ataque de fuerza bruta?

#1 de TildalWave (17 votos)
#2 de rook (10 votos)
#3 de lzam (2 votos)
#4 de cherrysoft (0 votos)

8

No tengo mucha experiencia con ataques de fuerza bruta pero me estaba preguntando

Supongamos que tiene un sitio web www.example.com y desea realizar un ataque de fuerza bruta en ese formulario de inicio de sesión, pero ese formulario de inicio de sesión está protegido por un token anti-CSRF.

¿Es posible hacer una contraseña de fuerza bruta en el formulario protegido CSRF porque siempre se crea una clave única?

en AntiForgeryToken versus Captcha

Está escrito allí. Las presentaciones automáticas son posibles en un formulario protegido por CSRF, pero estaba pensando. Si intentara hacer fuerza bruta, tengo que crear una solicitud válida.

Por ejemplo:

enlace

que utilizaré esta solicitud para fuerza bruta pero este token anti-CSRF caducará después de una única solicitud, ¿cómo puede un nombre de usuario y contraseña bruta de ataque de fuerza bruta?

web-application attacks brute-force csrf

pregunta Deepanshu Singh 21.09.2014 - 05:05

fuente

4 respuestas

Lea otras preguntas en las etiquetas web-application attacks brute-force csrf

¿Las aplicaciones del teléfono son vulnerables a XSS o CSRF? (Webview, Phonegap, chrometab) Plantilla o ejemplo del plan de pruebas de seguridad

score 17 · Answer 1

Simple. Usted lee el token anti-CSRF de la página de inicio de sesión recién solicitada y cada vez que el token se adjunta a la respuesta del servidor. En este caso, antes de enviar una solicitud POST, primero lea la respuesta a su solicitud GET desde el servidor y se le adjuntará el token nuevo. Luego lo usas para generar una nueva solicitud POST de fuerza bruta. Puede haber otros problemas con los que se encontrará, como, por ejemplo, la limitación de velocidad de solicitud y demás, pero el token anti-CSRF no protege contra ataques de fuerza bruta.

score 10 · Answer 2

Un atacante puede realizar un ataque de fuerza bruta utilizando Burp Intruso, con una extensión de extensión para manejar el token CSRF . Agregar un captcha a la página de inicio de sesión no resuelve el problema, eleva el nivel al obligar al atacante a romper el servicio de craqueo de captcha en 1,000 soluciones por $ 1.

Para responder a tu pregunta, ni un captcha ni un token CSRF son una defensa adecuada. Un sistema de inicio de sesión seguro debe utilizar autenticación multifactor .

score 2 · Answer 3

Los ataques CRSF funcionan engañando a un usuario (generalmente ya ha iniciado sesión) para que realice una solicitud que sirva al final del atacante (ya sea haciendo que haga clic en un hipervínculo, a través de un método como XSS).

Un token anti-CSRF protege las solicitudes confidenciales, al requerir que se envíe un valor impredecible (proporcionado al usuario en una página anterior) como parte de las solicitudes confidenciales. El atacante no tiene forma de saber cuál será este valor, por lo que no puede falsificar la solicitud correctamente.

Sin embargo, esto no va a tener ningún efecto real en una página de inicio de sesión. En la mayoría de los casos normales, una página de inicio de sesión es accesible para todos. Incluso si la solicitud POST para el formulario de inicio de sesión requiere un token CSRF enviado por la página web de inicio de sesión, no hay nada que impida que el atacante visite la página de inicio de sesión repetidamente, obteniendo un nuevo anti-CSRF válido cada vez.

score 0 · Answer 4

Ya hay un montón de respuestas excelentes en CSRF aquí, así que pensé que me extendería sobre ellas ofreciendo un enfoque alternativo para protegerse contra tales ataques. Si está utilizando Apache, recomendaría usar mod_evasive ya que esto protegerá contra ataques de fuerza bruta y también ataques de DOS. Si está ejecutando IIS, puede utilizar la extensión de restricciones de IP dinámica. Puede configurar reglas en Nginx o utilizar un Firewall de aplicación web sería un enfoque más sofisticado. Espero que esto ayude.