¿Debo usar la protección CSRF para las solicitudes GET?

La protección CSRF solo es necesaria para las operaciones de cambio de estado debido a la política del mismo origen . Esta política establece que:

  

un navegador web permite que los scripts contenidos en una primera página web accedan a los datos de una segunda página web, pero solo si ambas páginas web tienen el mismo origen.

Por lo tanto, el ataque CSRF no podrá acceder a los datos que solicita porque es un sitio cruzado (que es el CS en CSRF ) y está prohibido por la política del mismo origen. Por lo tanto, el acceso ilícito a los datos no es un problema con CSRF.

Como un ataque CSRF puede ejecutar comandos pero no puede ver sus resultados, se ve obligado a actuar a ciegas. Por ejemplo, un ataque CSRF puede decirle a su navegador que solicite el saldo de su cuenta bancaria, pero no puede ver ese saldo. Obviamente, esto es un ataque sin sentido (a menos que esté tratando de hacer DDoS al servidor del banco o algo así). Pero no tiene sentido si, por ejemplo, el ataque CSRF le dice a su navegador que le indique a su banco que transfiera dinero de su cuenta a la cuenta del atacante. La página de éxito o fracaso de la transferencia es inaccesible para el script atacante. Afortunadamente para el atacante, no necesitan ver la respuesta del banco, solo quieren el dinero en su cuenta.

Como solo las operaciones que cambian de estado probablemente sean blanco de ataques CSRF, solo necesitan defensas CSRF.

Generalmente, métodos seguros no tienen que estar protegidos contra CSRF porque no realizan cambios en el aplicación, e incluso si están devolviendo información confidencial, esto estará protegido por la Same Origin Policy en el navegador.

Si su sitio se implementa según los estándares, sus solicitudes GET deben ser seguras y, por lo tanto, no necesitan protección.

Sin embargo, hay un caso específico en el que se puede ejecutar un ataque "DoS entre sitios" ^* . Supongamos que su página de informes tarda 10 segundos en ejecutarse, con un 100% de uso de CPU en su servidor de base de datos y un 80% de uso de CPU en su servidor web.

Los usuarios de su sitio web saben que nunca deben ir a https://yoursite.example.org/Analysis/GetReport durante las horas de oficina porque mata el servidor y le da a otros usos una mala experiencia de usuario.

Sin embargo, Chuck quiere golpear tu yoursite.example.org de sitio web sin conexión porque no le gustas a ti ni a tu empresa.

En el foro ocupado que publica a menudo, http://forum.walkertexasranger.example.com , establece su firma en lo siguiente:

<img src="https://yoursite.example.org/Analysis/GetReport"width=0height=0/>

Tambiénsabequelosempleadosdesuempresafrecuentanelforo,amenudomientrastambiéniniciansesiónenyoursite.example.org.

CadavezquesusempleadosleenunadelaspublicacionesdeChuck,lascookiesdeautenticaciónseenvíanahttps://yoursite.example.org/Analysis/GetReport,porloquesusitioprocesalasolicitudygeneraelinforme,ysusistemasedesconectaporqueestassolicitudesconstantesconsumenalaCPU.

Entonces,aunquelasolicitudesunasolicitudGETynorealizaningúncambiopermanenteensusistema(tambiénconocidocomo"seguro"), es de hecho que desactiva su sistema cada vez que se ejecuta. Por lo tanto, sería mejor proteger esto con un método de prevención CSRF.

^{* XSDoS, o Negación entre sitios si es servicio, es una frase acuñada por mí, así que no lo busques en Google.}

La protección CSRF no se utiliza para proteger datos. Se utiliza para proteger a un usuario de un estado que cambia sin saberlo, como transferir dinero o desconectarse de una cuenta.

Por lo tanto, si su solicitud GET está cambiando un estado (lo cual no debería ser), entonces debería tener protección CSRF. Pero si solo está devolviendo datos, no necesita protección CSRF, porque la protección CSRF no protegería nada en este caso.

Puede ser útil volver a revisar esta página: enlace

CSRF, o falsificación de solicitudes entre sitios, no se trata de proteger los datos para que no se recuperen, sino de que los datos no se modifiquen. Esto también se conoce como cambios de estado. En una aplicación, los cambios de estado pueden incluir datos de perfil, como la dirección de correo electrónico, la contraseña del usuario o la biografía, o la transferencia de fondos.

Las solicitudes GET se deben usar para solicitudes idempotentes, o solicitudes que no cambian de estado. Estas solicitudes no necesitan tener tokens anti-CSRF.

Las solicitudes POST se usarán para solicitudes no identitarias, o solicitudes que cambien de estado.

Generalmente, las solicitudes POST deben usarse para cambiar el estado de algo. Si tiene configuradas las solicitudes GET para que puedan cambiar el estado (por ejemplo, www.example.com/settings?delete_account=True), debe usar la protección CSRF como una solución de curita.

Intente usar POST para cambiar el estado, no GET.