¿Deshabilitar la protección CSRF a veces justificado?

Question

Estoy pensando en los formularios de inicio de sesión en particular:

Por su naturaleza, los formularios de inicio de sesión bloquean la entrada arbitraria: sin un nombre de usuario y contraseña válidos, solo se los devuelve. ¿Hay alguna razón por la cual estos incluso necesiten la adición de authenticity_token o una protección de falsificación de solicitud entre sitios similar?

Tengo curiosidad por si formularios de ingreso son un ejemplo en el CSRF incluso podría ser generalmente indeseable:

Dado un cliente anónimo, que se debe permitir que el primer punto de contacto con un sitio es publicar las credenciales de inicio de sesión válidas . CSRF evita esta interacción directa al requerir primero que el cliente realice un GET para establecer una cookie de sesión anónima, que se usa como base para su autenticidad_token. El token se debe volver a publicar con las credenciales de inicio de sesión. El paso inicial adicional parece inútil cuando el objetivo real aquí es autenticar a un usuario que llega sin una sesión y está tratando de dar sus credenciales.

¿Me falta alguna consideración de seguridad en este escenario?

Answer 1

Sin la protección XSRF, un atacante podría registrar al usuario en una cuenta maliciosa, que podría utilizar para rastrear su actividad. Esto se discute en Robust Defenses for Cross-Site Request Forgery.

No veo por qué el cliente debería poder POSTAR las credenciales de inicio de sesión como primer punto de contacto. Para una interfaz web, en la mayoría de los casos prácticos, el cliente debe OBTENER la página de inicio de sesión para recuperar el formulario.

Answer 2

Awesome question! Me tenía rascándome la cabeza por un tiempo.

¿Qué pasa con el escenario en el que el atacante ya ha adquirido la contraseña de la víctima por otros medios, pero no tiene acceso al sitio web? Se engaña a su víctima a ir a www.evil.com y tiene esto en la página inicial:

<image src="http://portal.internal/login.php?user=root&password=hunter2"/> 

Esto convence navegador de la víctima para autenticar la víctima al sitio. Luego, en otra página de www.evil.com, hay otra etiqueta de la imagen:

<image src="http://portal.internal/deleteEverything.php/> 

En este caso, el atacante imprescindible el uso CSRF para acceder al sitio interno, ya que no tiene otra manera de acceder a él. Además, tenga en cuenta que este ataque CSRF no necesita ejecutarse en un usuario que realmente tenga una cuenta en el sistema, solo un usuario que tenga acceso de red al sitio.