Skip to main content

Vulnerabilidad CSRF

Hoy me toca estrenarme a mi en el blog. Mi nombre es Gerard y, para resumir, diré que no puedo vivir tranquilo sin saber cómo funcionan las cosas.

Hoy hablaré de un tema que, desafortunadamente, pasa desapercibido entre muchos programadores y que puede causar algún que otro dolor de cabeza: la vulnerabilidad de CSRF (Cross-site request forgery). Los grandes como TwitterFacebookInstagram, Flickr, GoDaddy, Avira y muchos otros han tenido algún que otro descuido en este tema. Si los grandes han tenido descuidos, no me quiero ni imaginar los que somos más pequeños 🙂

¿Cómo funciona?

La vulnerabilidad por CSRF se aprovecha de la inseguridad a la hora de establecer y comprobar las sesiones. Por ejemplo, supongamos que tengamos un panel de gestión de usuarios y un formulario que edita sus datos. Si nosotros (los programadores) no comprobamos la autenticidad de los datos ni del origen de la petición, es posible que alguien en otra página (por ejemplo este blog) tenga incrustado un iframe o una acción por AJAX que mande un post con los datos que queramos a la URL del formulario, y si el usuario visitante está logueado… adivina.

¿Cómo se previene?

La OWASP ha hecho una página para prevenir el CSRF bastante detallado. El método más básico y efectivo para prevenir esta vulnerabilidad es añadir un Token aleatorio en cada formulario. El Token tiene que ser único (o mantenido para cada sesión), pero lo más importante es que debe ser imprevisible; lo máximo aleatorio posible.

De este modo, el servidor genera un Token, lo mete en el formulario, y cuando se envia, se comprueba si el Token que se recibe del formulario coincide con el Token generado para esa sesión (y formulario).

También es muy recomendable usar encriptación SSL para los formularios con datos sensibles, así, si un

¿Cómo probar si mi sitio es vulnerable a CSRF?

La herramienta que yo he usado para probarlo en LVMCloud es el OWASP Tester, aunque si buscáis podéis encontrar muchísimas más (otras de la OWASP también).
Lo que hace el OWASP Tester es registrar las acciones de tu navegador (crea un proxy) y generar luego un index.html con formularios que envian los datos POST a la URL que ha registrado.

Si el sitio es vulnerable, podrás realizar las mismas acciones que hicistes antes (login, cambio de datos, etc) sin necesidad siquiera de estar logueado, poseer cookies etc.

Ejemplo

Supongamos que soy programador de Facebook. Si para borrar una foto no se pasara un token único, se podría hacer un JS automáticamente te redirigiera al link de eliminar foto. Si hay suerte y tú estás logueado en Facebook, la foto se borraría y tú no te darías ni cuenta.
En cambio, poniendo un token aleatorio para cada sesión (y acción) evitamos que esto pueda ocurrir, pues yo no podría hacer el JS porque no conocería el token aleatorio que Facebook tiene preparado para ti.

Conclusión

Si no eres programador, poca cosa puedes hacer para evitar este tipo de vulnerabilidad, a no ser que desactives JS (retrocediendo 20 años) y los iframes (ya obsoletos).

Si eres programador debes tener en cuenta estas cosas, porque sino te vas a encontrar con que algún día algún usuario te dirá que se ha cambiado nosequé y que él no ha sido, y no vas a saber por qué.

Hay muchos frameworks que ya incluyen seguridad para esta vulnerabilidad, como CakePHP, Symfony2, Yii, etc. Aunque en ninguno viene activado por defecto.

Deja un comentario

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