Si bien puedo ver algunos de los gastos generales de la protección CSRF (generación de token, validación de token, trabajo adicional a implementar), no veo ninguna razón por la que no lo desee .
¿Hay algún caso en el que la protección CSRF sea algo que NO deba usarse? No estoy hablando de casos donde es innecesario, como acciones sin efectos secundarios, pero casos en los que su uso es realmente una mala idea.
En realidad, puede haber un caso de uso, pero es un poco artificial y depende de cómo se genera el token CSRF.
En muchos casos, el token CSRF es solo un token aleatorio que está vinculado a la sesión y no está relacionado con ningún nivel de autenticación. Cuando el cliente solicita una página que contiene un formulario web, el formulario tiene el token incrustado en ella como un campo oculto Cuando el cliente publica los datos del formulario, el servidor verifica la El token es el mismo que el que envió y puede estar bastante seguro de que la respuesta es Desde el mismo cliente envió el formulario a. Todo bien.
Sin embargo, este flujo de trabajo es menos conveniente en el contexto de una API web donde el El contacto inicial con el servidor es de un cliente que está publicando algunos datos (a menudo en la forma de algunos JSON). En este caso, el servidor no ha podido enviar un simbólico. Normalmente, una API web tendría algún otro tipo de verificación, para Por ejemplo, si utiliza JWT, la aplicación cliente realizará una conexión inicial a servidor donde realiza alguna autenticación y obtiene un JWT que utiliza en todos futuras llamadas a la API.
A menudo, esto no es un problema ya que tendrá una separación de preocupaciones. Habrá ser un conjunto de direcciones URL utilizadas por un cliente web que sigue el formulario de solicitud normal a continuación, envíe el flujo de trabajo de datos y una URL API separada que utiliza algo como JWT. No hay necesidad de un token CSRF.
El problema puede ser cuando tienes diferentes requisitos similares para ambos. De verdad No quiero tener que mantener dos conjuntos de manejadores separados y preferiría solo tiene el que puede ser utilizado por un cliente web tradicional y también como un Cliente API En ambos casos, se utiliza un token, pero son de naturaleza diferente.
Dije que esto fue ideado. En realidad, solo he encontrado este tipo de problema al desarrollar un nuevo servicio donde quería una interfaz de cliente web como así como la API sólo para fines de desarrollo / depuración. En este caso, lo que yo han hecho es tener algún javascript en la versión basada en navegador que hace una autenticación inicial con el servidor y obtiene el JWT que copia en el formulario web como otro valor más. Sin embargo, puedo imaginar una situación en la que desea admitir una interfaz 'tradicional' basada en un navegador web general y una Aplicación que utiliza HTTP / HTTPS para la comunicación a través de una API.
Hasta cierto punto, esto es realmente solo semántica. El concepto básico de proporcionar una El token en formularios web para proteger contra CSRF no es diferente de un API que utiliza un token para authn / authz. La única diferencia real es que el token CSRF generalmente no implica nada más que el hecho de que la respuesta es del mismo cliente al que se enviaron los datos del formulario inicial, mientras que la API token está haciendo afirmaciones sobre el usuario real. Técnicamente, no hay por lo que este último no se puede usar para el primero, siempre que el servidor pueda manejar ese. Lo primero no puede ser usado para lo segundo.
No puedo pensar en un caso en el que no se deba usar CSRF, aparte de los casos innecesarios. Cuando dice que no se debe usar, ¿está hablando de un caso en el que esto fundamentalmente romperá algo? Un token CSRF no debería romper nada, por lo que no puedo pensar en un caso de este tipo
Lea otras preguntas en las etiquetas web-application appsec csrf