Protección contra CSRF sin estado

En Stateless CSRF Protection se dan algunas ideas sobre protección contra CSRF (Cross Site Request Forgery) cuando no tenemos la ayuda de las sesiones en el servidor. En el caso de que tengamos una sesión, los consejos hablan de utilizar algún identificador adicional que envía el servidor y hay que re-enviarle, de forma que si la petición no viene de donde debe, ese identificador no será correcto.

Traditional anti-CSRF techniques use tokens issued by the server that the client has to post back. The server validates the request by comparing the incoming token with it’s copy. But that small word “copy” means server-side state. Not good.

Cuando no tenemos estado en la aplicación (cosa rara, la verdad, porque parece que eso de tener unas galletitas y sesiones se hace hasta cuando no hace falta para nada), la idea se que el cliente calcule un identificador y lo envíe como cookie y dentro de la petición (de esa forma sería más difícil para un atacante obligar a un usuario a enviar esa petición).

The protective measure of double submit lies in the fact that a malicious site cannot read the cookie and include it as request parameter. That condition still holds if the cookie is generated by the client and never saved by the server.

So let the client generate the anti-CSRF value and only compare and check format of cookie and request parameter on the server. Ergo, stateless CSRF protection!

Un pensamiento en “Protección contra CSRF sin estado

  1. Pingback: ¿Qué son los tokens anti-CSRF? | Mbpfernand0's Blog

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s