python - csrfmiddlewaretoken - ¿Los ataques CSRF se aplican a las API?
csrf_token django (5)
En particular, estoy escribiendo una API RESTful de Django para respaldar una aplicación iOS, y sigo corriendo con las protecciones CSRF de Django cada vez que escribo métodos para manejar las solicitudes POST.
Tengo entendido que las cookies administradas por iOS no son compartidas por las aplicaciones, lo que significa que mis cookies de sesión son seguras y ninguna otra aplicación puede usarlas. ¿Es esto cierto? De ser así, ¿puedo simplemente marcar todas mis funciones API como exentas de CSRF?
De acuerdo con la documentación de DRF, las API son vulnerables al ataque CSRF siempre que el servidor utilice sesión autenticada (en lugar de preguntar cada contraseña de tiempo)
La solucion es
- Asegúrese de que las operaciones HTTP ''seguras'', como
GET,HEADyOPTIONSno puedan usarse para alterar ningún estado del lado del servidor. - Asegúrese de que cualquier operación HTTP ''insegura'', como
POST,PUT,PATCHyDELETE, siempre requiera un token CSRF válido.
Ese no es el propósito de CSRF. CSRF es evitar la publicación directa de datos en su sitio. En otras palabras, el cliente debe publicar a través de una ruta aprobada, es decir, ver la página del formulario, completarla, enviar los datos.
Una API prácticamente excluye el CSRF, ya que su objetivo general es permitir que las entidades externas accedan y manipulen los datos en su sitio (el "sitio cruzado" en CSRF). Entonces, sí, creo que, por regla general, cualquier vista de API debe estar exenta de CSRF. Sin embargo, aún debe seguir las mejores prácticas y proteger cada punto final de API que realmente realice un cambio con alguna forma de autenticación, como OAuth.
Esta respuesta actualmente aceptada (mayo de 2012) es en su mayoría correcta, excepto cuando usa autenticación basada en sesiones. También vale la pena mencionar el papel de CORS.
El escenario más simple es que visite foo.com y el sitio web ejecute Javascript para realizar una solicitud DELETE basada en AJAX a api.com/users/123 y termine borrando al usuario en su nombre. Ahora esto no siempre es posible debido a CORS: los navegadores evitarán que foo.com realice una solicitud a api.com menos que api.com explícitamente a la lista blanca de foo.com . Esto también asume que está utilizando la autenticación basada en la sesión para sus API en lugar de la autenticación basada en token. En la autenticación basada en sesión, cualquier usuario que haya iniciado sesión en api.com puede ejecutar solicitudes mientras permanecen conectados. Si tiene autenticación basada en token (cada solicitud debe elaborarse con un encabezado de Authorization HTTP que contenga el token de autenticación), entonces estan seguros. La autenticación basada en la sesión envía implícitamente el token de autenticación a través de cookies.
Un escenario levemente peor es si uno de sus dominios CORS de confianza se ve comprometido, digamos que tiene un formulario que no desinfecta JavaScript y un usuario logra inyectar JS en su sitio a través de ese formulario. Si está utilizando la autenticación basada en sesiones, un usuario autenticado que visite la página verá que se ejecuta Javascript y realizará una solicitud de API. Esto podría ser desastroso y una posibilidad muy real si está usando la autenticación basada en sesiones para su API.
Los ataques CSRF se basan en cookies que se envían implícitamente con todas las solicitudes a un dominio en particular. Si sus puntos finales API no permiten la autenticación basada en cookies, debe ser bueno.
Incluso si usa la autenticación basada en cookies, sus cookies son seguras porque las aplicaciones de iOS no comparten cookies . Sin embargo, a menos que bloquee intencionalmente navegadores web requiriendo un encabezado inusual de usuario-agente, otra parte podría construir una aplicación basada en navegador que use su API, y esa aplicación sería vulnerable a ataques CSRF si su API admite autenticación basada en cookies y no lo hace No aplica la protección CSRF.
Se aplican si también está utilizando su API para admitir un sitio web.
En este caso, aún necesita algún tipo de protección CSRF para evitar que alguien incrustando solicitudes en otros sitios tenga efectos de paso en la cuenta de un usuario autenticado.
Chrome parece denegar solicitudes POST de origen cruzado por defecto (otros navegadores pueden no ser tan estrictos), pero permite que las solicitudes GET tengan origen cruzado, por lo que debes asegurarte de que las solicitudes GET en tu API no tengan efectos secundarios.