¿Es necesaria la protección CSRF para los clientes que no aceptan cookies?

  

Django rechaza todas las solicitudes POST

Solo con el mecanismo csrf habilitado. Django emite cookies csrf en dos casos:

1. Si está utilizando el middleware csrf en settings.py . Middleware se aplica a todas las solicitudes según la WSGI spec .
2. Si decora vistas individuales con @csrf_protect , sin el software intermedio

En el caso de 1, todas las vistas están protegidas a través de este mecanismo y se compara una comparación de {% csrf_token %} (un campo input en el formulario que contiene el token csrf) con la cookie enviada.

Tienes dos opciones para deshabilitar esto, por lo tanto:

1. En todo el sitio: elimine el middleware y sus solicitudes POST comenzarán a funcionar nuevamente.
2. A través del uso cuidadoso de @csrf_exempt , puede optar por ciertas vistas (POST urls) fuera del mecanismo de protección csrf.

¿Entonces no es un riesgo el uso de la protección csrf? Depende de lo que es su solicitud POST. Lea la la descripción de csrf de OWASP. Básicamente, la idea es que construya una solicitud y convencer a un usuario para que la ejecute; cuando lo hacen, sus datos se modifican de manera que no pretendían que sucediera. La idea detrás de la comparación del token es que solo la página web emisora tendrá el token válido, lo que significa que una solicitud maliciosa debe ser rechazada.

Como tal, la respuesta a esto es sí, lo más probable es que sea un riesgo. Para la mayoría de las aplicaciones y sitios web, desea este tipo de protección.

  

mi plan es modificar el comportamiento de Django (a través de la extensión del middleware CSRF) de manera que permita a través de solicitudes POST que no tengan ninguna cookie.

Por las razones anteriores, no aconsejaría eso. Creo que pretende extenderse desde el marco existente (lo que no necesita hacer), pero solo quiero cubrir el otro caso que otros usuarios podrían considerar, es decir, parchear el propio marco django para hacer esto. En cuyo caso ... no, porque a menos que cada sitio tenga su propio virtualenv , extenderá esta vulnerabilidad a todos los sitios que usen ese código, ahora y hasta que actualice su instalación de django.

Eliminar completamente la protección CSRF significa que no puede confiar en la información de registro para mostrar la fuente real de una solicitud (por ejemplo, la dirección IP). Esto puede estar bien en tu caso.

Una alternativa es agregar información aleatoria a un campo oculto.

Luego concatene esta información con una cadena secreta, que solo es conocida por el servidor. El hash se puede utilizar como un token CSRF sin estado. Dependiendo de su caso de uso, puede ser una buena idea agregar una marca de tiempo al campo oculto y al hash, y luego verificar que no tenga más de media hora, por ejemplo.

Para verificar el token, solo calcula el hash nuevamente en función del campo oculto y el secreto.

No conozco ningún problema devastador con tu plan. Sin embargo, permítanme explicar mi razonamiento y los riesgos potenciales, para que pueda formarse su propia opinión sobre el nivel de riesgo asociado con la eliminación de las defensas CSRF.

Permítame comenzar con una pregunta: ¿Está diciendo que su servidor enviará un correo electrónico cada vez que reciba una solicitud POST, sin cookies de sesión, sin autenticación, sin autorización, de cualquier persona en el mundo? Cualquier persona en el mundo que le envíe esa solicitud POST hará que el servidor envíe un correo electrónico, ¿un correo electrónico por solicitud POST? Si es así, esto significa que alguien malicioso puede hacer que su servidor envíe toneladas de correos electrónicos, enviando correo basura al destinatario deficiente. Si es un problema serio o no, no lo sé. Tendrá que decidir por sí mismo según su propia tolerancia al riesgo.

En general, cada vez que una solicitud POST puede desencadenar algún efecto secundario en su servidor, o puede hacer que su servidor realice alguna acción confidencial, sin requerir autenticación, puede pensar con cuidado para asegurarse de no abrirse. Hasta ataques de spam / denegación de servicio.

Si elimina la protección CSRF, aumenta el riesgo. Significa que un atacante puede crear un anuncio malicioso que, cuando se ve, hace que el navegador del espectador envíe automáticamente una solicitud POST a su servidor, lo que desencadena el efecto secundario. Esta es una forma muy económica de que un atacante pueda generar muchas solicitudes POST a su servidor, de manera que no proporcione una forma fácil de bloquear el flujo de solicitudes maliciosas (ya que cada solicitud provendrá de una dirección IP diferente) o rastrear al atacante Los tokens CSRF hacen que este ataque sea más difícil: ahora el atacante tiene que enviar las solicitudes POST desde su propia máquina, y no puede explotar los anuncios para usar a otros como un chismoso.

El riesgo añadido es bastante modesto. Además, si está ejecutando un sitio de bajo perfil de bajo valor, tal vez nadie se molestará en atacarlo, así que tal vez no valga la pena preocuparse por esto. Solo quería señalar el riesgo, incluso si resulta ser insignificante en su situación particular.

Comencé a agregar un comentario sobre la respuesta de Hendrik Brummermann, pero rápidamente se quedó sin espacio, por lo tanto ...

No entiendo por qué una ausencia de protección CSRF afectaría el registro de una dirección IP. E incluso si lo hiciera, en ausencia de cualquier gestión de sesión, ¿qué relevancia tiene una dirección IP para gestionar la integridad de una transacción?

Además, para evitar repeticiones, el token debería variar entre transacciones, por lo que el servidor tendría que generar nuevos valores para cada operación y recordar entre solicitudes, lo que implica una sesión, lo que implica una galleta!

Lo que falta en la pregunta original son los detalles del modelo de amenaza, especialmente en ausencia de sesión, ¿qué es lo que está tratando de proteger?

Suponiendo que los ataques de reproducción no son un gran problema, entonces podría incluir tanto un valor aleatorio (R) como el hash de ese valor aleatorio + sal (f (R + X)) como campos ocultos. Al incrustar una marca de tiempo en R, se reduce la ventana para cualquier ataque de repetición (cuando agrega la maquinaria para verificarlo).

Se podría implementar una solución sin estado utilizando la información provista en cada solicitud, por ejemplo. usando el agente de usuario y los encabezados de aceptación y (digamos) los primeros 16 bits de la dirección IP del cliente Y un sal secreto.

Tenga en cuenta que regularmente he señalado la tontería de usar la información de la dirección IP para la autenticación, y que la dirección IP de un cliente puede cambiar (por ejemplo, al conectarse a través de proxies de carga equilibrada), sin embargo IME, la única vez que los bits más significativos el cambio de la dirección IP se produce cuando el cliente intenta deliberadamente ocultar su identidad a través de un servicio como TOR, en cuyo caso es probable que no quiera sus POST.

Hay otras formas de hacer que este identificador de usuario sea más exclusivo, por ejemplo, propiedades SSL negociadas , el conjunto de cookies actual (incluso si está vacío!),

Consulte también panopticlick para obtener más información sobre las huellas dactilares de los clientes, pero tenga en cuenta que es probable que haya una gran cantidad de superposición entre usuarios que no aceptan cookies y usuarios que no ejecutarán su javascript.

Obviamente, cualquier dato de referencia que utilice para la verificación, si desea implementar esto a través de Django, entonces deberá reemplazar tanto el generador de token como el verificador (CsrfViewMiddleware).