¿Cuándo no debo usar la protección CSRF para un formulario?

Question

¿Cuándo no debo usar la protección CSRF para un formulario?

Navega tus respuestas

#1 de Hendrik Brummermann (7 votos)
#2 de AviD (3 votos)

5

De forma predeterminada, tengo protección CSRF para todos mis formularios con un token.

Sin embargo, noté otra aplicación web que tiene una función similar a una de mis formas. Y no usaron el token CSRF.

Así que asumí que no protegían contra el ataque CSRF para esa forma.

Entonces

pregunta 1) aparte del token CSRF, no debería haber otra forma de protegerse contra CSRF, ¿verdad?

Supongo que la respuesta es que esta es la única manera. por lo tanto mi pregunta principal es

pregunta 2) ¿cuándo no debe utilizar la protección CSRF?

Conozco una posible instancia que es cuando el formulario POST está dirigido a direcciones URL externas.

Lo leí en django docs .

¿Hay otros casos en los que no debería usar la protección CSRF o es innecesario?

ACTUALIZAR

a) otros métodos de protección CSRF incluyen la autenticación de usuario

b) PUEDE escapar sin protección contra CSRF para formularios POSTBACKs cuando no requiere que el usuario inicie sesión. (vea las respuestas y comentarios de nbnh)

web-application appsec csrf

pregunta Kim Stacks 12.03.2011 - 05:37

fuente

2 respuestas

7

Sí, el uso de tokens es la única forma de protegerse de forma fiable contra los ataques CSRF.

Si se requiere o no una protección depende de las acciones que el programa realice con los datos enviados.

Como regla general: si los datos se modifican con los permisos o el contexto del usuario actual, necesita la protección.

Si no se realizan modificaciones, puede estar bien no proteger. Un ejemplo común son los formularios de búsqueda y los resultados. Tenga en cuenta que el registro de qué búsquedas se realizan según qué usuario es un tipo de modificación y, por lo tanto, el formulario debe estar protegido.

respondido por el Hendrik Brummermann 12.03.2011 - 12:18

fuente

Lea otras preguntas en las etiquetas web-application appsec csrf

¿Cómo un troyano como Trojan: JS / BlacoleRef.BV infecta un sitio web? Solaris: IP Spoofing a través de puertos Ethernet

score 3 · Accepted Answer

No, los tokens no son la única forma de proteger de manera confiable contra CSRF.
De hecho, fue solo recientemente que las bibliotecas empaquetadas tenían la madurez suficiente como para justificar una recomendación, antes de que el rodar las suyas tuviera una alta probabilidad de empeorar las cosas.

Otra forma de protegerse contra CSRF es la re-autenticación. Es decir. Pidiendo al usuario su contraseña otra vez.
La ventaja de este enfoque es que la técnica es familiar para los desarrolladores, y es poco probable que se ensucie. La desventaja es que no es transparente para el usuario.
Hoy en día, con la mayoría de los marcos con la protección incorporada y las bibliotecas adicionales disponibles, diría que se prefieren los tokens CSRF ... pero no es la única manera.

En cuanto a Q # 2, como @nhnb escribió correctamente, si no se realizan modificaciones, podría estar de acuerdo con omitir la protección.
Si bien considera lo trivial que es en los marcos actuales, la transparencia del usuario y la sobrecarga mínima, es probable que sea mejor dejarlo dentro y no luchar contra el código para eliminarlo ...