¿Que es el Cross Site Request Forgery (CSRF)?

Cuando apenas empezamos a controlar el dolor de cabeza generado por el XSS (Cross Site Scripting) nos vemos las caras con otra amenaza que aunque lleva tiempo en el ruedo de la seguridad web últimamente pareciera tomar auge definitivo para convertirse en una de las peores amenazas de los próximos años. 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.

¿Cómo evitar el CSRF?

Uno de los mejores consejos para los usuarios es simplemente hacer una sola cosa a la vez cuando se trate de manejar sus cuentas en línea, y salir de las aplicaciones haciendo el respectivo "logout" que casi siempre significa pulsar un simple botón de "salir" o "abandonar la aplicación". Por ejemplo: No pulsar un enlace recibido mediante en "Messenger" o en otra pestaña del navegador cuando estamos utilizando la aplicación de nuestro banco puede ser la mejor solución imaginable ante un ataque de CSRF.

Sin embargo para el programador es un poco más difícil prevenir este tipo de ataque. Lo primero indudablemente es darle al usuario la posibilidad de cerrar su sesión. Aunque parezca raro, usted se asombraría de la cantidad de sitios y aplicaciones que no disponen de esta opción una vez que el usuario ha validado su ingreso a las mismas.

En cuanto a código, el mejor de los aliados para controlar el CSRF es el control estricto del Session TimeOut de la aplicación, de forma que si el usuario no se conecta nuevamente y olvida "salir" correctamente de la aplicación, el servidor deberá en un lapso corto de tiempo dar dicha sesión por finalizada.

Otra eficiente forma de controlar el CSRF es la introducción de un "token" dinámico adicional en las solicitudes del cliente que se asocia a la sesión de éste en el servidor y se agrega a todos los enlaces y solicitudes. Este token será siempre diferente por sesión y por usuario por lo que de esta forma se le hace más difícil al atacante tratar de emular el enlace necesario para efectuar el ataque debido a que el token es variable.

Muchos programadores hacen públicos los enlaces privados, y esta es también una razón para que los atacantes utilicen estos enlaces privados a discreción. Los enlaces privados solamente deben ser vistos si un usuario ha validado su sesión y jamás deben ser expuestos en e-mails o páginas públicas. Esto también parece obvio pero se asombraría al ver la cantidad de enlaces "privados" de un sitio que se pueden obtener mediante técnicas de GHDB (Google Hacking Database).

Hasta la próxima.