Un CSRF me robó la billetera

Conversando con un buen amigo en “reflexiones de un café” salió este tema, donde me di cuenta que si no entendemos y aplicamos algunos de las técnicas ya conocidas en el ámbito de la seguridad de sistemas podemos en algún momento pagarlo y pagarlo caro.

 

Para nada tenía previsto un escrito como este, pero creo que sirve como excusa en nuestro contexto para introducir un tema que de seguro estaré retomando en algún momento con profundidad, la CIBERSEGURIDAD. Un tema polémico en todo sentido, con el que he escuchado cualquier cantidad de criterios en todo el territorio nacional. Desde mi punto de vista es un apellido muy bien definido para lo que conocemos todos como política de informatización, quizás muchos lo vean como algo que flota sin sentido después de la palabra informatización, otros lo ven como una paranoia y otros lo entienden pero sin embargo no saben cómo aplicarlo.

Las definiciones de ciberseguridad son varias, pero podemos resumirlo en la protección de infraestructura computacional y activos digitales aplicando estándares, protocolos, métodos, reglas, herramientas, leyes etc…,  ¿una definición un poco corta y banal no?  Pues sí, con toda la intención del mundo, los detalles podemos dejarlo para un debate especializado, pero para usted mi querido lector está definición será suficiente para hacer un ejercicio de conciencia. Es muy cierto que hay mucho más detrás del término ciberseguridad, pero quiero enfocarme hoy en una de las tantas aristas que posee, relacionada a la seguridad de los sistemas de información, sobre todo porque estamos en una etapa donde la informatización y la implementación de herramientas y sistemas es crucial para lograr un determinado grado de desarrollo.

Todos los que hemos desarrollado algo en la web sabemos que cosa es hacer un submit de un formulario, lo mismo para completar datos personales o para algo tan importante como transferir dinero de una cuenta a otra. Aparentemente en ninguna de estas acciones hay peligro, a fin de cuentas estoy autenticado y bajo protocolo seguro (https), no hay forma que alguien pueda apoderarse del dinero que tanto esfuerzo me costó tener en mi cuenta. Pero en el diseño de la solución sucedió algo que cambiará la percepción del asunto, un olvido que costará al usuario su preciada billetera.

Aquí entra el CSRF, en ingles Cross-site request forgery o falsificación de petición en sitios cruzados, nadie se dio cuenta de este pequeño duende verde, malicioso y oportunista que robará la billetera de nuestro usuario. Básicamente un ataque CSRF obliga a un usuario a realizar una acción dentro del sistema no aprobada por él, por esta razón es conocido también como cabalgamiento de sesión, donde un atacante se monta en una sesión activa de cualquier usuario y lo obliga a realizar operaciones sin que este ni siquiera lo note. ¿Cómo se hace esto? Con un poco de creatividad, estudio del objetivo e ingeniería social.

Pepe, nuestro usuario de ejemplo le fascina los gatos, el atacante utilizará la ingeniería social como gancho para poder realizar el ataque CSRF y que finalmente pepe haga una transferencia desde su billetera hacia la billetera del atacante sin que este lo note. El atacante publica en el Facebook de Pepe un link de acceso a una página de ayuda animal relacionada a los gatos, lo que Pepe no sabe es que en realidad es una página diseñada por el atacante donde silenciosamente al entrar estará realizando una transferencia de saldo de su cuenta. En el cuerpo de esta página podremos encontrar un trozo de código como este:

<form method=’POST’ action=’https://vulnerablesite.com/tranf.php’ id=»csrf-form» >

<input type=’text’ name=’saldoTransferir’ value=’500′>

<input type=’submit’ value=’submit’>

</form>

<script>document.getElementById(«csrf-form»).submit()</script>

Explicando un poco basicamente este formulario es enviado automaticamente cuando la página es cargada, utilizando la sesión activa del usuario por lo que el sistema entiende de que es Pepe quién está solicitando la operación de transferencia, solo que él no aprobó en ningún momento la acción.

Esto es solo un ejemplo sencillo de como pudiera explotarse una vulnerabilidad como esta en un sistema sin protección contra ataques CSRF, afortunadamente la mayoría de los navegadores modernos no permiten realizar peticiones de sitios cruzados como esta gracias a CORS, una política restrictiva que evita las peticiones a sitios cruzados. Usted mi querido lector no se confíe, existen formas de burlar esta política, es necesario que piense, diseñe y desarrolle las soluciones desde la seguridad de la información. Mi recomendación, visite el sitio de mi buen amigo Henry Raúl González Brito, encontrará información muy valiosa para el desarrollo de sus soluciones.

La técnica más común es la implementación de un token CSRF en todas las operaciones de modificación de datos en el sistema, este token actua como firma validatoria de que realmente Pepe está realizando la acción dentro del propio sistema y aprobada por él. De esta forma se evitan que atacantes utilicen la sesión activa de cualquier usuario para realizar acciones en su favor.

Lo que he descrito solo es un ejemplo muy básico y puntual de cómo puede el apellido ciberseguridad influir en el nombre informatización. No quería dejar pasar el momento para realizar esta pequeña reflexión, de seguro que este tema continuará….

4 comentarios de “Un CSRF me robó la billetera

  1. Bien interesante, suerte q los que usan Raptor y los que pronto lo estaremos usando tenemos una gran ayuda..
    mis saludos… y no veo pos de Raptor 3 jaja.

    • Saludos mi amiga, bueno suerte los que usan cualquier tecnología e implenmentan la protección, pues claro n Raptor también está a la mano poderlo usar facilmente. Muy pronto !! Yami, muy pronto estaré hablando del tema del lanzamiento, un saludote.

  2. Muchas gracias mi estimado amigo William Amed. Efectivamente esta vulnerabilidad es una de las menos comprendidas por los programadores y en los posgrados que hemos impartido a programadores de experiencia, les cuesta trabajo entenderla porque no fuerza solo a la aplicación web sino que explota el propio funcionamiento del protocolo HTTP.

    Por eso quisiera también invitar a los desarrolladores de aplicaciones móviles a analizar este fenómeno y tratar de evitarlo también mediante la aplicación de tokens de comprobación ante una transferencia de operación, ya que en estos casos la apk asume la función de Agente de Usuario.

    • Efectivamente mi amigo !!, creo que hay que seguir elvando la cultura en este sentido. Recuerde siempre que tiene una invitación pendiente por acá y hacer un taller, veremos como la materializamos. Un gran abrazo

Responder a Ing. William Amed Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *