kali cookie certificado ataque php token csrf

php - cookie - ¿Los formularios de inicio de sesión necesitan fichas contra ataques CSRF?



csrf token spotify (2)

Según lo que he aprendido hasta ahora, el objetivo de los tokens es evitar que un atacante falsifique un formulario.

Por ejemplo, si un sitio web tiene un formulario que ingresa elementos agregados a su carrito de compras, y un atacante podría enviar correo basura 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 la compra, 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 añaden seguridad en este caso, ya que garantizan que el usuario haya rellenado y haya 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 debería conocer ambos para que funcione la falsificación de inicio de sesión (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, 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 entendimiento de los ataques y tokens de CSRF? ¿Y son inútiles para los formularios de inicio de sesión de usuario como sospecho?


Sí. 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 un tipo de ataque de "phishing de dominio confiable". En resumen, una página de inicio de sesión CSRF vulnerable permite a un atacante compartir una cuenta de usuario con la víctima.

La vulnerabilidad se desarrolla así:

  1. El atacante crea una cuenta de host en el dominio de confianza
  2. 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
  3. El atacante engaña a la víctima para que use el sitio de confianza, donde es posible que no se dé cuenta de que está conectado a través de la cuenta de host.
  4. El atacante ahora tiene acceso a cualquier dato o metadato que la víctima "creó" (intencional o involuntariamente) mientras su navegador iniciaba sesión 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 conocían, registrar a la víctima en YouTube usando esa cuenta, acechando los videos que la víctima estaba mirando.

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

Login CSRF hace posibles varios ataques nuevos; 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 de su propio marcador de confianza 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 de privacidad.


Su comprensión es correcta: el objetivo de CSRF es que el atacante pueda forjar una solicitud de aspecto legítimo 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 causar molestias a los usuarios al enviar correos basura fallidos, cuando el sistema de seguridad puede bloquear al usuario por un período de tiempo.