¿La acción de inicio de sesión y cierre de sesión tiene protección CSRF?

Posiblemente debería protegerse contra CSRF de inicio de sesión . Sin esta protección, un atacante puede revertir efectivamente un ataque CSRF. En lugar de que la víctima haya iniciado sesión en su propia cuenta y el atacante intente conducir la sesión realizando solicitudes al sitio utilizando las cookies de la víctima, iniciará sesión en el sitio con las credenciales del atacante, lo que permitirá al atacante secuestrar las solicitudes de manera efectiva. dominio que la víctima pensó que era anónimo o que estaba bajo su propia cuenta y luego lo envió a la cuenta del atacante. Por supuesto, si esto es relevante para su sitio en particular o no depende de la naturaleza de su sitio y si algo como esto es ventajoso para un atacante. Un ejemplo es un ataque CSRF de inicio de sesión en un motor de búsqueda para que el atacante pueda ver los términos que se buscan cuando se registran en la cuenta del atacante en lugar de la de la víctima.

Los objetivos principales para este tipo de ataque es donde las acciones autenticadas pueden realizarse fuera de la aplicación principal. p.ej. desde un complemento de navegador o widget incrustado en otro sitio. Esto se debe a que estas acciones se autenticarán mediante el uso de cookies y, si un atacante le ha iniciado sesión, todas las acciones se registrarán en su cuenta.

También debe proteger su mecanismo de cierre de sesión contra CSRF. Al principio, parece que todo lo que un atacante puede hacer es cerrar la sesión del usuario, lo que en el peor de los casos sería molesto. Sin embargo, si combina esto con un ataque de phishing, el atacante puede atraer a la víctima para que vuelva a iniciar sesión utilizando su propio formulario y luego capture las credenciales. Consulte aquí un ejemplo reciente: LostPass .

¿Iniciar sesión? Sí. ¿Cerrar sesión? No.

¿Por qué iniciar sesión? Existe este divertido ataque de inicio de sesión CSRF, donde el atacante inicia sesión en la víctima con una cuenta controlada por el atacante, y luego puede "obtener control sobre el contenido creado por la víctima mientras está conectado con esa cuenta". El impacto es bastante escaso de la OMI, pero comenzaron a ver esto como un problema ahora que los vectores de ataque más jugosos se han ido. ;-)

¿Por qué no cerrar sesión? No hay impacto de seguridad. Lo mejor que puede hacer es cerrar la sesión del sistema, lo que provoca molestias a lo sumo.

EDIT : no hay ningún impacto de seguridad en el cierre de sesión de CSRF por sí solo . Es posible que haya casos en los que se pueda usar esto en un ataque en varias etapas para cerrar la sesión de alguien y luego pedirle que inicie sesión en una página falsificada.

¡La protección CSRF en el cierre de sesión es una necesidad!

¿Por qué? Supongamos el siguiente escenario:

1. Estás en una página de comercio y preparas un pedido de compra para, por ejemplo, 1000 Daimlers en un intercambio XETRA.
2. Hasta que esté preparando el pedido, alguien que sepa que ha iniciado sesión en enlace , le enviará un enlace de phishing. p.ej. enlace
3. Al hacer clic en el enlace, se cerrará la sesión y quizás el pedido no haya finalizado.
4. Después de iniciar sesión nuevamente, reconoces que el precio para los 1000 Daimlers es superior a un minuto antes de que te desconectes con este enlace de phishing.
5. Ahora tienes que pedir un precio más alto.

Un token CSRF en el cierre de sesión hubiera evitado este lío.

Cerrar sesión e iniciar sesión CSRF es realmente muy explotable.

Si encuentra una manera de obtener un XSS privado / privado permanente (como un campo privado no seguro, como en las preferencias del usuario), puede forzar el cierre de sesión de la víctima, iniciar sesión con su cuenta, que tiene el XSS automático aplicado, y luego ejecuta algún código para realizar un ataque de phishing , excepto que está en el dominio correcto con un certificado SSL válido . Si el usuario inicia sesión (o tiene un llenado automático que le permitiría robar sus credenciales antes de que incluso presionen enviar Y luego inicie sesión automáticamente para que puedan ver su página en blanco y luego estén donde esperan) usted ahora Tienen su contraseña y una misma ejecución de origen. Ahora simplemente ejecute alguna persistencia de exploits en sus configuraciones privadas y ahora tiene una ejecución remota y permanente de JS en la cuenta de los usuarios.

Esto permite ataques muy importantes, especialmente porque muchos desarrolladores no lo hacen con explotaciones de inyección de HTML en campos privados porque solo el usuario debería poder ver eso y no tienen ninguna razón para ejecutar código contra ellos mismos. Un exploit de CSRF de inicio de sesión te permite realizar el phishing del mismo origen y, si tienen los mismos iframes de origen habilitados, también puedes incrustar la página de inicio de sesión en pantalla completa y luego ejecutar el código que quieras dentro del iframe aparentemente legítimo.

Cualquiera de los errores solo van desde inútiles hasta molestos, en el mejor de los casos, pero si tienes estos dos (y siempre es mejor asumir que sí), un atacante puede secuestrar una cuenta de usuario con un solo anuncio desagradable.

CSRF para iniciar sesión generalmente sí, pero depende de su aplicación. un atacante puede iniciar sesión en una cuenta maliciosa, por ejemplo, en Google y luego monitorear todas sus visitas al sitio.

CSRF para el cierre de sesión: sí, absolutamente puede prevenir DOS