¿Los formularios de inicio de sesión necesitan tokens contra los ataques CSRF?

161

Por lo que he aprendido hasta ahora, el propósito de los tokens es evitar que un atacante falsifique el envío de un formulario.

Por ejemplo, si un sitio web tenía un formulario que ingresaba artículos agregados a su carrito de compras, y un atacante podría enviar spam a su carrito de compras con artículos que no desea.

Esto tiene sentido porque podría haber múltiples entradas válidas para el formulario de carrito de compras, todo lo que el atacante tendría que hacer es conocer un artículo que el sitio web está vendiendo.

Entiendo cómo funcionan los tokens y agrego seguridad en este caso, porque aseguran que el usuario haya completado y presionado el botón "Enviar" del formulario para cada artículo agregado al carrito.

Sin embargo, ¿los tokens agregan seguridad a un formulario de inicio de sesión de usuario, que requiere un nombre de usuario y contraseña?

Dado que el nombre de usuario y la contraseña son muy únicos, el atacante tendría que saber ambos para que la falsificación de inicio de sesión funcione (incluso si no tenía la configuración de tokens), y si un atacante ya lo sabía, podría iniciar sesión en el sitio web él mismo. Sin mencionar que un ataque CSRF que hace que el usuario inicie sesión no tendría ningún propósito práctico de todos modos.

¿Es correcto mi comprensión de los ataques y tokens CSRF? ¿Y son inútiles para los formularios de inicio de sesión de usuario como sospecho?

php token csrf

— php_learner
fuente

Pueden secuestrar su enrutador, porque probablemente use una contraseña predeterminada en eso, y no está protegido por CSRF para iniciar sesión.

— AbiusX

Sí, entonces otros sitios web no pueden imitar su formulario de inicio de sesión. ¿Qué pueden lograr al hacerlo? Primero no quieres permitir eso. Segundo: casos de fallas muy fáciles como el bloqueo del usuario debido a una contraseña incorrecta n. de veces, se puede evitar.

— mayankcpdixit

126

Si. En general, debe proteger sus formularios de inicio de sesión de los ataques CSRF como cualquier otro.

De lo contrario, su sitio es vulnerable a una especie de ataque de "phishing de dominio de confianza". En resumen, una página de inicio de sesión vulnerable a CSRF permite a un atacante compartir una cuenta de usuario con la víctima.

La vulnerabilidad se desarrolla así:

El atacante crea una cuenta de host en el dominio de confianza
El atacante falsifica una solicitud de inicio de sesión en el navegador de la víctima con las credenciales de esta cuenta de host
El atacante engaña a la víctima para que use el sitio de confianza, donde puede que no se dé cuenta de que ha iniciado sesión a través de la cuenta de host.
El atacante ahora tiene acceso a cualquier dato o metadato que la víctima "creó" (intencionalmente o no) mientras su navegador estaba conectado con la cuenta de host.

Como un ejemplo pertinente, considere YouTube . YouTube permitió a los usuarios ver un registro de "su propio" historial de visualización, ¡y su formulario de inicio de sesión era vulnerable a CSRF! Como resultado, un atacante podría configurar una cuenta con una contraseña que conociera, registrar a la víctima en YouTube usando esa cuenta, acosando qué videos estaba viendo la víctima.

Hay una discusión en este hilo de comentarios que implica que "solo" podría usarse para violaciones de privacidad como esa. Quizás, pero para citar la sección en el artículo CSRF de Wikipedia :

Iniciar sesión CSRF hace posible varios ataques novedosos; por ejemplo, un atacante puede luego iniciar sesión en el sitio con sus credenciales legítimas y ver información privada como el historial de actividades que se ha guardado en la cuenta.

Énfasis en "nuevos ataques". ¡Imagine el impacto de un ataque de phishing contra sus usuarios, y luego imagine que dicho ataque de phishing funciona a través del marcador de confianza del usuario en su sitio! El documento vinculado en el hilo de comentarios antes mencionado ofrece varios ejemplos que van más allá de los simples ataques a la privacidad.

— natevw
fuente

66

¿Cómo ayuda la protección CSRF? ¿Hay algo que impida que el atacante solicite su propio token CSRF y simplemente se someta con eso? Como no existe una sesión autenticada, no hay ninguna razón para que el servidor web prefiera un token sobre otro.

— A. Wilson el

2

"¿Hay algo que impida que el atacante solicite su propio token CSRF y simplemente se someta con eso?" - ¡Si! Esa es toda la suposición detrás de la lógica de prevención CSRF. Los navegadores permitieron / permiten el envío de un formulario para apuntar a otro origen, pero nunca [intencionalmente] permitieron que JS leyera datos a través de sitios, excepto ahora a través de CORS opcional. A menos que configure CORS incorrectamente, el atacante puede activar el envío de un formulario (que puede incluir un token CSRF existente en las cookies ) pero no tiene forma de conocer el token para enviar la segunda copia requerida (por ejemplo, en el cuerpo / encabezados). Entonces el código CSRF lo rechazará.

— natevw

77

Creo que tu último comentario es incorrecto (no entendiste lo que decía A. Wilson). Estamos diciendo que un atacante puede cargar http://good.com/login.htmlen un cliente, analizar el token CSRF anidado y luego publicarlo http://bad.com/login.htmlque contenga un formulario modificado que envíe su nombre de usuario, contraseña y token independientemente de lo que escriba la víctima. CORS no se aplica porque usted ' Tengo dos clientes separados: el atacante y la víctima. Entonces, para reiterar la pregunta: ¿la protección CSRF realmente funciona para los formularios de inicio de sesión?

— Gili

8

Sí, CSRF protegerá un formulario de inicio de sesión contra la falsificación de solicitudes entre sitios . Un token CSRF adecuado es criptográficamente único cada vez que se genera. Claro, el atacante puede obtener un token por sí mismo, pero aún NO EMPAREJARÁ la cookie [potencialmente no configurada] que la víctima tiene en su navegador, y el atacante no tiene forma de configurar dicha cookie sin comprometer una página en el buen dominio. (Sin embargo, su ejemplo parece un poco confuso entre CSRF y algún tipo de ataque de phishing extraño, así que no estoy seguro si estoy respondiendo su pregunta real ...)

— natevw

3

Puede que me equivoque, pero parece que existe una amenaza significativa si el usuario accidentalmente hace algo relacionado con la compra de artículos. Por ejemplo, un atacante engaña al usuario para que inicie sesión en un sitio web, y el usuario procede a comprar artículos sin darse cuenta de que están en otra cuenta (piense en Amazon o similar). Ahora el atacante tiene acceso a la información de pago guardada, puede redirigir las compras, etc.

— usted786

14

Su comprensión es correcta: el objetivo de CSRF es que el atacante puede falsificar una solicitud de apariencia legítima de antemano. Pero esto no se puede hacer con un formulario de inicio de sesión a menos que el atacante conozca el nombre de usuario y la contraseña de la víctima, en cuyo caso hay formas más eficientes de atacar (inicie sesión usted mismo).

En última instancia, lo único que puede hacer un atacante es incomodar a sus usuarios enviando spam por inicios de sesión fallidos, cuando el sistema de seguridad puede bloquear al usuario por un período de tiempo.

— Jon
fuente

2

¡Guau, respuesta súper rápida! ¡Muchas gracias! Ahora puedo seguir construyendo mi sitio web con confianza.

— php_learner

21

El CSRF de inicio de sesión todavía se puede usar para ataques a la privacidad del usuario seclab.stanford.edu/websec/csrf/csrf.pdf

— squiddle

66

@quiddle: Ese es un trabajo bastante interesante, gracias por el enlace Pero depende del inicio de sesión del usuario con una cuenta bajo el control del atacante y supone que el usuario no se dará cuenta de que algo no está bien y supone que el usuario producirá información confidencial que luego se almacenará en el servidor. Entonces, en mi humilde opinión, es bastante menos grave que el CSRF "clásico".

— Jon

66

@ Jon Sí, puede ser menos grave, pero al final puede ser más que un inconveniente, es decir, una invasión de la privacidad. Cada servicio tiene que definir su modelo de amenaza por sí mismo y manejarlo en consecuencia. Para hacer eso, necesita al menos estar al tanto de las posibles amenazas. Es por eso que agregué mis 2 centavos.

— Calamardo

1

Por favor, ¿podría explicar cómo lo harían? "En última instancia, lo único que puede hacer un atacante es incomodar a sus usuarios enviando spam por inicios de sesión fallidos, cuando el sistema de seguridad puede bloquear al usuario por un período de tiempo".

— samthebest

0

Sí , ¡otros sitios web no pueden imitar su formulario de inicio de sesión! Tan sencillo como eso.

¿Qué pueden lograr al hacerlo?

Primero: no quieres permitir eso.
Segundo: incluso casos de fallas muy simples como:
- bloqueo de usuario debido a una contraseña incorrecta nno. de veces, se puede evitar.
- Las alertas de pirateo informático pueden evitarse. etcétera etcétera.

— mayankcpdixit
fuente

La mayoría de estos puntos son incorrectos. El atacante puede crear un formulario de inicio de sesión, obtener las credenciales del usuario, cargar el formulario de inicio de sesión (con el token csrf) y publicar los tres datos en el destino. CSRF no evita esto.

— Snapey

Los navegadores @Snapey generalmente no permiten que JS lea datos CSRF. Usando JS no puede imitar la solicitud de envío de formulario genuino.

— mayankcpdixit

El token csrf a menudo se pasa al cliente para que lo use javascript. No estoy hablando de cors que estoy tomando sobre el atacante, solo solicito el formulario de inicio de sesión y las credenciales de relleno. @mayankcpdxit. Parece implicar que csrf evita el relleno de credenciales, lo que no hace.

— Snapey

Teóricamente, sí, no se puede prevenir. Pero no es posible automatizar el relleno de credenciales después de CSRF si deja de cargar formularios CSRF en iframes y deja de permitir la solicitud de origen cruzado.

— mayankcpdixit

-1

El inicio de sesión previo de validación CSRF no tiene demasiado sentido en mi humilde opinión.

Gracias a @squiddle por el enlace: seclab.stanford.edu/websec/csrf/csrf.pdf , podemos leer en la primera página:

The most popular CSRF defense is to include a secret
token with each request and to validate that the received
token is correctly bound to the user’s session,
preventing CSRF by forcing the attacker to guess the
session’s token.

Si intenta la validación CSRF antes del inicio de sesión, ¡entonces le da a un atacante potencial la oportunidad de raspar un código válido de su sitio web! Él / ella sería capaz de volver a publicar el token para derrotar el propósito.

Quizás un atacante pueda intentar adivinar un nombre de usuario de su sitio. Lo que he hecho, si la dirección IP intenta adivinar 10 nombres de usuario sin éxito, simplemente lo incluyo en la lista negra.

— Patrice Gagnon
fuente