Prevenir el Cross Site Request Forgery (XSRF)

Una de las amenazas a las que hace pocos años no se les hizo mucho caso fue el Cross Site Request Forgery conocido por las siglas XSRF o CSRF.

El CSRF o Cross Site Request Forgery también conocido como XSRF, al contrario del XSS que explota la confianza del usuario en un sitio en particular, explota la confianza del sitio en un usuario en particular. Convencionalmente el CSRF utiliza a un usuario validado para a través de este introducir solicitudes “válidas” que modifiquen el comportamiento de la aplicación a favor del atacante.

En palabras simples, el atacante usa a la victima para que sea ella misma la que realice la transacción dañina cuando la víctima se encuentra validada en el servidor y en la aplicación específica. El proceso es simple, muchos usuarios no finalizan correctamente (o no pueden hacerlo) sus sesiones en las aplicaciones bancarias o de otra índole que puedan ser afectadas por esta vulnerabilidad y las mantienen activas mientras navegan otros sitios, más aún en tiempos en que las pestañas de los navegadores son muy utilizadas, por tanto desde cualquier otra ventana en el navegador se pudiera inducir al usuario a pulsar un enlace con una orden a sitios en los que el usuario ha ya autenticado, para que el usuario ejecute sin saberlo la acción de ataque.

Todas las medidas de autentificación de usuarios a este punto ya han validado al usuario por lo que no sirven ya de nada para evitar el ataque. Un ejemplo podría darse en un sistema de banca en línea en el que el usuario ha accedido y mientras aún su sesión sigue activa el atacante logra mediante alguna treta que el usuario pulse por ejemplo un enlace como este:

https://mibanco.com/transferir.php?cuenta=NroCuentaDelAtacante&monto=1000

Algunas personas tienen la creencia de que este tipo de ataques solo puede ser ejecutado mediante el método GET, y siento decirles que por el método POST son inclusive mucho más efectivos. El ejemplo fue realizado con un enlace (GET) solo por fines didácticos.

Si bien el usuario ha validado su sesión, todos sus datos de verificación como por ejemplo su “cookie” de sesión serán enviados por el navegador a la aplicación del banco ya que este mantiene una sesión abierta con dicho sitio y esos datos son válidos. Esto sucede aunque el usuario haya pulsado el enlace desde otra página en el mismo navegador.

Es siempre importante educar al usuario acerca del hecho de que no debe desviar su atención y mantener la sesión con el sitio de su banco abierta mientras hace otras cosas. Sin embargo sabemos bien que cuando se trata de una cantidad grande de usuarios esto puede llegar a ser un trabajo enorme.

¿Cómo evitar entonces este problema a nivel de desarrollo?

Doble-posted cookie (envío doble de cookie):
Esta técnica se basa en que si bien el navegador envía toda la información relacionada a la sesión, si agregamos un campo oculto a cada formulario con el valor del identificador de sesión, podremos evitar el ataque, ya que el atacante debe conocer este valor para incluirlo en el enlace o el formulario oculto en su página. El navegador no se lo proporcionará por las políticas de seguridad de dominios cruzados. Sin embargo aunque de forma más compleja el atacante podría robar el cookie de sesión mediante otras técnicas, por lo que este método no es el más confiable.

Unique form nonce (formulario único para cada solicitud):
Se trata de generar un formulario con un campo oculto dinámico que es generado por cada solicitud. El contenido del campo debe ser generado aletoriamente utilizando un buen sistema de PRNG (Pseudo Random Number Generator) para que no pueda ser adivinado mediante técnicas estadísticas avanzadas. Este campo se guardará en el servidor y será eliminado apenas el formulario sea utilizado ya que una nueva solicitud del formulario deberá ser acompañada por un nuevo contenido en el campo. Si se recibe un formulario con un contenido no válido, simplemente se rechaza la solicitud.

Hay quienes han perfeccionado la técnica también asignando un nombre aleatorio al campo mediante el mismo concepto. Esta técnica es muy interesante ya que no solo elimina el  XSRF sino evita que un usuario introduzca dos veces la misma transacción (lo que puede suceder facilmente si el usuario presiona el botón de enviar dos veces porque la conexión es lenta y no ha recibido la respuesta esperada). Además este sistema evita también que el formulario sea escaneado en busca de vulnerabilidades, ya que la gran mayoría de los “scanners” de vulnerabilidades, cargarán el formulario una sola vez para luego proceder a “jugar” con el contenido de los diferentes campos.

Requerir credenciales de autentificación nuevamente:
Es una interesante técnica que se basa en requerir nuevamente los datos de ingreso del usuario al momento de generar una transacción. Algunos sitios han inclusive generado lo que denominan “clave para transacciones” que no es más que un factor adicional de validación solicitado solamente en caso de generar un procedimiento que involucra movimiento de capital. La desventaja de este método es lo fastidioso que puede llegar a ser si se hacen muchas transacciones, o el problema que puede significar para el usuario recordar una nueva clave.

One time Passwords:
Un OTP o dispositivo que genera claves de acceso de un solo uso es una solución definitiva ante el XSRF y muchos otros problemas, sin embargo su costo es el principal factor a tomar en cuenta en estos casos. Este tipo de solución podría ser sobre-dimensionada dependiendo del tipo de aplicación y la cantidad de usuarios de la misma. Si necesitas saber algo más acerca de este tipo de componentes puedes visitar el artículo que trata acerca de este tema.

Fuente: Blog de Mauro Maulini y II