Entendiendo los ataques CSRF

Acabo de leer un interesante artículo  en Linux Magazine en el que se explica cómo funcinan los ataques tipo CSRF (cross-site  request forgery o también cross-site reference forgery que vendría a ser algo así como falsificación de petición/referencia cruzada a un sitio). Voy a intentar explicarla brevemente.

Actualmente la mayoría de los navegadores nos permiten tener varias ventanas y/o pestañas abiertas que comparten cierta información. Por ejemplo, si tenemos abierta una sesión de gmail y en otra pestaña abrimos nuestro adsense automáticamente nos autentificará con la cuenta de gmail de la sesión activa. Si a esto le añadimos que cada vez existen más aplicaciones web que tenemos constantemente abiertas tenemos un problema.

Imaginemos que mantenemos nuestra cuenta de correo web abierta y en otra pestaña abrimos nuestra sesión en una red social, en ese momento nos encontamos a un contacto que conoce nuestra dirección de correo-e y al que no se le ocurre otra cosa que montarnos una trampa en forma de javascript o url montada aproposito escondida en una imagen o cualquier otro elemento para que lo visitemos en su perfil de la red social. Con esto esa persona podría conseguir que cargaramos por ejemplo una url con esta forma.

http://dominio-mi-correo-web.com/contrasenya?nombre=midireccion@correo.com&contrasenya=nuevacontraseña

A tenor de lo explicado anteriormente nuestro navegador ejecutaría dicho código al tener la sesión de nuestro correo-e abierta y con ello esa tercera persona ha conseguido usurparnos nuestra cuenta de correo-e de la forma más absurda.

Os preguntaréis como nos va a meter esa url sin que nos demos cuenta. Pues es muy fácil, que se ejecute un javascript o que lance una url mediante un enlace incrustado en un texto es de lo más sencillo. También tenemos cosas ligeramente más sofisticadas como las citadas en el artículo que consisten en poner la url en el src de una imagen.

Ahora que sabemos como funciona tenemos que pensar en cómo evitarlo. La propuesta del artículo consiste en crear una señal en el servidor que generaremos de forma aleatoria antes de enviar una página de solicitud de información como puede ser un formulario. Posteriormente ya sea mediante un campo oculto de formulario, una cookie o una url deberemos recibir de nuevo esa señal para cotejarla con la original y así asegurar que no es una inyección mediane el truco anteriormente descrito sinó que es consecuencia de la ejecución de una página generada por nosotros. En el escenario anterior la url que montaba la tercera parte no funcionaría ya que le faltaría un tercer parámetro que sería la señal que habíamos generado aleatoriamente.

Otras sugerencias son:

  1. Utilizar un navegador en exclusiva para este tipo de aplicaciones.
  2. Utilizar un navegador que aisle cada pestaña como puede ser el nuevo chrome de google.

Por lo que se comenta en el artículo pocas páginas están diseñadas para evitar ataques XSS y particularmente del tipo CSRF. Tendremos que ponernos las pilas.

Cheli

Deja una respuesta

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

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.