¿Por qué es necesaria la comprobación de remitentes para que Django impida el CSRF?

En primer lugar, gracias por la interesante pregunta. Antes no conocía los detalles de CSRF y tuve que buscar la respuesta a tu pregunta, pero creo que ahora sé la explicación correcta del comportamiento de Django.

Los desarrolladores de Django tratan HTTP y HTTPS se refiere de manera diferente porque los usuarios esperan cosas diferentes de los servicios web inseguros y seguros. Más específicamente, si una página web utiliza la seguridad de la capa de transporte, los usuarios esperan estar protegidos contra los ataques de intermediarios, lo que significa que confían en el principio de que incluso si alguien se sentó directamente entre ellos y el servidor remoto e interceptó a todos. mensaje, no pudieron hacer uso de esa información. Tenga en cuenta que esto no se espera de las conexiones HTTP simples.

Ahora considere el siguiente escenario, citado de la publicación de un desarrollador de Django aquí : / p>

  

• el usuario navega a enlace
  
• un MITM modifica la página que se devuelve, por lo que tiene un POST   forma que se dirige a enlace . El MITM tiene   para incluir un token CSRF, pero eso no es un problema porque   él puede inventar una y enviar una cookie CSRF para que coincida.
  
• el formulario POST se envía mediante javascript desde el navegador del usuario   y así incluye la cookie CSRF, un token CSRF correspondiente y la   la cookie de sesión del usuario, y así será aceptada.
  

No entendí este ataque al instante, así que intentaré explicar los detalles. En primer lugar, tenga en cuenta que estamos viendo una página que muestra formularios a través de conexiones simples pero que envía datos a través de SSL / TLS. Como entiendo, parte del problema es que la cookie y el valor de forma oculta (también conocido como "token CSRF") solo se comparan entre sí, no contra ningún valor que esté almacenado en el lado del servidor. Esto hace que sea fácil para el atacante proporcionar a su víctima una combinación de token de cookie que será aceptada por el servidor. Recuerde, la página que muestra el formulario no está protegida, por lo que los encabezados Set-Cookie y el contenido del formulario en sí pueden ser spoofed Una vez que se envía el formulario manipulado (a través de JS inyectado, por ejemplo), el servidor ve una solicitud perfectamente válida.

Agregar la estricta comprobación de Referer es la respuesta a este problema exacto. Al verificar estos encabezados, solo se aceptarán las solicitudes que se originen en https://example.com en otro punto final de https://example.com . Las páginas inseguras del mismo dominio serán tratadas como completamente no confiables, y con razón.

Ahora, para volver a la pregunta de por qué las solicitudes HTTP simples se tratan de manera diferente, solo tenemos que imaginar un sitio que no use cifrado en absoluto. En ese caso, un hombre en el medio también podría falsificar los encabezados Referer enviados con los datos reales del formulario, por lo que verificarlos no proporciona ninguna seguridad adicional. En otras palabras: no hay protección contra los ataques CSRF por parte de un hombre en el medio, pero, como mencioné anteriormente, los usuarios no esperan este tipo de seguridad de los sitios HTTP simples.

Con respecto a su pregunta sobre cómo otros frameworks web manejan este vector de ataque, honestamente tengo que decir que no sé.

Resumiré brevemente lo que he encontrado desde que hice esta pregunta.

No se puede garantizar que la primera solicitud de un usuario al sitio web sea https (desde el lado del servidor). Un atacante podría usar esta solicitud para establecer una cookie CSRF específica. Luego puede usar esto para hacer una solicitud entre sitios en nombre del usuario desde un dominio http fuera de su control. Esto es lo que impide la comprobación de referencias.

Una solución que podría venir a la mente es restablecer el token CSRF al iniciar una sesión autenticada. El atacante solo podría falsificar solicitudes a servicios anónimos, lo cual tiene pocos beneficios (solo podría hacerlo directamente él mismo, es anónimo después de todo).

El problema con esto es que el formulario de inicio de sesión en sí también es vulnerable a CSRF, a pesar de necesitar una contraseña. El atacante, en ese caso , no se hace cargo. la sesión del usuario, pero registra al usuario en la sesión del atacante. El atacante podría entonces ver cosas que el usuario hizo o ingresó.

Algunos casos raros en los que creo que podría desactivarse, todos asumiendo que HSTS está activado y usted cambia el token CSRF al iniciar sesión:

• Tiene un proceso de inicio de sesión que realiza una de estas acciones:

  • Involucre dos páginas, con el token CSRF cambiado después de la primera, para que no se pueda automatizar (también se establece X-Frame-Options ). P.ej. se requiere autenticación de dos factores, o solo una segunda página con un botón de aprobación manual.
  • La página de inicio de sesión tiene un CAPTCHA que protege contra solicitudes falsas.
  • No se engañará al usuario para que use la cuenta incorrecta para nuestro servicio en particular (por ejemplo, es altamente personalizado de una manera que es obvia para el usuario pero que el atacante no puede detectar).

• Sabes que la primera solicitud será a través de https, por ejemplo. se supone que solo se puede acceder a la página a través de su aplicación o software, en lugar de los navegadores normales.

• Los navegadores implementan una forma de ver si una cookie era https-only / se configuró en una conexión https (entonces los atacantes no pudieron establecer una cookie utilizable a través de http). Pero eso es imposible en este momento, y fuera de nuestro control.

(Hacer que los tokens CSRF sean dependientes de la sesión de forma secreta, y que se almacenen en el lado del servidor, no soluciona esto. El atacante no puede sobrescribir ni generar el token CSRF, pero solo puede pedirle a su servidor que lo haga. abriendo un formulario utilizando la sesión que eligió).