¿Debo usar protección CSRF en los puntos finales de la API Rest?

Al principio no estaba apuntando a una auto-respuesta, pero después de más lecturas encontré lo que creo que es una respuesta integral que también explica por qué algunos todavía podrían estar interesados en la protección CSRF en los puntos finales REST. / p>

Sin cookies = Sin CSRF

Realmente es así de simple. Los navegadores envían cookies junto con todas las solicitudes. Los ataques CSRF dependen de este comportamiento. Si no usa cookies, y no confía en las cookies para la autenticación, entonces no hay absolutamente ningún espacio para los ataques CSRF, y no hay ninguna razón para poner la protección CSRF. Si tiene cookies, especialmente si las usa para la autenticación, entonces necesita protección CSRF. Si todo lo que desea saber es "¿Necesito protección CSRF para mi punto final de API?" Puedes detenerte aquí y marcharte con tu respuesta. De lo contrario, el diablo está en los detalles.

h / t to paj28: Si bien las cookies son el principal vector de ataque para los ataques CSRF, también es vulnerable si usa la autenticación HTTP / básica. De manera más general, si el navegador puede pasar automáticamente las credenciales de inicio de sesión para su aplicación, entonces CSRF es importante. En mi experiencia, las cookies son la tecnología más común que se explota para hacer que CSRF ocurra, pero existen otros métodos de autenticación que pueden resultar en la misma vulnerabilidad.

REST = Sin estado

Si le preguntas a alguien "qué es REST", obtendrás una variedad de respuestas que discuten una variedad de propiedades diferentes. Puede ver tanto porque alguien hizo esa pregunta en el desbordamiento de pila: enlace

Una propiedad de REST en la que siempre he confiado es que es apátrida. La aplicación en sí tiene estado de curso. Si no puede almacenar datos en una base de datos en algún lugar, su aplicación será bastante limitada. Sin embargo, en este caso, sin estado tiene un significado muy específico e importante: las aplicaciones REST no rastrean el estado de la aplicación del lado del cliente . Si está utilizando sesiones, entonces (es casi seguro) está haciendo un seguimiento del estado del lado del cliente y no es una aplicación llena de REST. Por lo tanto, una aplicación que utiliza sesiones (especialmente para inicios de sesión) que se rastrean a través de cookies no es una aplicación llena de REST (IMO), y es ciertamente vulnerable a los ataques CSRF, incluso si de otra forma se parece a una aplicación REST.

Creo que vale la pena señalar rápidamente que una de las razones por las que la falta de estado del lado del cliente es importante para las aplicaciones REST es que la capacidad de los intermediarios para almacenar en caché las respuestas también es una parte deseable del paradigma REST. Mientras la aplicación esté siguiendo el estado del lado del cliente, no es posible el almacenamiento en caché.

Resto ≠ Sin cookies

Por estos motivos, inicialmente asumí que una aplicación REST totalmente compatible nunca necesitaría sesiones, nunca necesitaría cookies y, por lo tanto, nunca necesitaría seguridad CSRF. Sin embargo, hay al menos un caso de uso que puede preferir las cookies de todos modos: inicio de sesión persistente.

Considere una aplicación web típica del lado del cliente (en este caso, del navegador, no móvil). Para comenzar, inicie sesión, que utiliza una API REST para validar las credenciales del usuario y, a cambio, recibe un token para autorizar futuras solicitudes. Para las aplicaciones de una sola página, puede mantener ese token en la memoria, pero al hacerlo se cerrará la sesión del usuario de manera efectiva si cierra la página. Como resultado, sería bueno mantener el estado en algún lugar que pueda durar más que una sola sesión de navegador. El almacenamiento local es una opción, pero también es vulnerable a los ataques XSS: un ataque XSS exitoso puede hacer que el atacante tome sus tokens de inicio de sesión y los envíe al atacante para que los use a su discreción.

Por este motivo, he visto algunas sugerencias de uso de cookies para almacenar tokens de inicio de sesión. Con una cookie puede establecer el indicador de solo http, lo que impide que la aplicación lea la cookie una vez que se haya configurado. Como resultado, en el caso de un ataque XSS, el atacante aún puede hacer llamadas en su nombre, pero no puede abandonar el token de autorización por completo. Este uso de cookies no viola directamente el requisito de apatridia de REST porque el servidor todavía no está rastreando el estado del lado del cliente. Solo busca credenciales de autenticación en una cookie, en lugar de en el encabezado.

Menciono esto porque potencialmente es una razón legítima para usar cookies con una API REST, aunque obviamente depende de una aplicación determinada para equilibrar las diversas preocupaciones de seguridad y usabilidad. Personalmente trataría de evitar el uso de cookies con las API REST, pero puede haber motivos para usarlas de todos modos. De cualquier manera, la respuesta general es simple: si está utilizando cookies (u otros métodos de autenticación que el navegador puede hacer automáticamente), entonces necesita protección CSRF. Si no estás utilizando cookies, entonces no.

  

"no hay forma de que un navegador proporcione automáticamente la autenticación   credenciales, incluso si de alguna manera se trata de visitar la API   punto final "

Solo tenga cuidado con las redes privadas que utilizan la autenticación integrada de windows / kerberos. En este escenario, Brower proporcionará credenciales automáticamente (kerberos o token NTLM) si está configurado para hacerlo.

Entonces, creo que en este caso se requiere CSRF.

  

Los puntos finales de la API Rest tienen una diferencia muy importante con respecto a otras solicitudes: son específicamente sin estado, y nunca deben aceptar / usar datos de una cookie o sesión.

Si así es como se define la "API REST", entonces no es posible un CSRF. CSRF, también llamado "sesión de sesión" [ citation ], obviamente no funcionará Si no hay sesión para "montar".