CSRF, esta abreviatura aparece una y otra vez en las notas de actualización del núcleo WordPress. El método que se esconde detrás es ya antiguo y se aprovecha de las cookies, normalmente abundantes, de un navegador. Afortunadamente, sin embargo, puedes protegerte del cross site request forgery con bastante facilidad. Todo lo que necesitas es un poco de tiempo y atención.

Probablemente utilices varios servicios que ofrecen la opción de permanecer conectado incluso después de haber abandonado el sitio web. Si vuelves a visitar el sitio web, no tendrás que volver a introducir los datos de acceso, sino que iniciarás sesión directamente. Esto es genial, por supuesto, porque, al igual que la gestión de contraseñas o el llamado inicio de sesión único, te ahorra tener que rellenar formularios.

Lo siguiente ocurre en segundo plano: cuando te conectas al sitio web por primera vez, el sitio web coloca una cookie en tu navegador. Se trata de un pequeño archivo de texto en el que se puede almacenar cierta información. En el caso de permanecer conectado, se trata de una cadena generada aleatoriamente.

La próxima vez que visites el sitio web, el servidor comprobará esta cadena y, si encuentra la contrapartida correspondiente, te conectará automáticamente. Esta es también la razón por la que se cierra la sesión en todas partes cuando vacías la caché de tu navegador, porque todas las cookies también se borran durante este proceso.

Los ataques CSRF son en el fondo un abuso de confianza

Como puedes ver, en un ataque correspondiente, se engaña al servicio que lee las cookies. A continuación te explicaré cómo ocurre esto exactamente utilizando dos ejemplos.

El peligro de esta manipulación reside en que alguien realice cambios en tu perfil de Facebook en tu nombre, por ejemplo. Sin embargo, la falsificación de petición de sitio cruzado (cross site request forgery) también suele depender del phishing. Aquí también adquiere relevancia la confianza, concretamente tu confianza en los remitentes de correos electrónicos, por ejemplo.

¿Cómo de vulnerable es WordPress?

Probablemente no hayas oído el término Cross Site Request Forgery tan a menudo como ataques de fuerza bruta o Cross Site Scripting. Hay una razón para ello: la organización sin ánimo de lucro OWASP (Open Web Application Security Project) publica periódicamente una lista de las diez vulnerabilidades más críticas de las aplicaciones web. A lo largo de los años, CSRF se ha ido deslizando cada vez más hacia abajo en la lista de riesgos de seguridad, y ahora ha desaparecido de los 10 primeros.

Probablemente se deba en parte a que los ataques CSRF son casi tan antiguos como el propio internet. Los/as desarrolladores/as profesionales ya tienen práctica en proteger su código contra estos/as, por lo que los riesgos de seguridad son bastante fáciles y rápidos de solucionar.

WordPress también está en guardia. Por ejemplo, se publicó la actualización de seguridad 4.7.5 en mayo, que corregía seis vulnerabilidades que los hackers podrían haber utilizado para lanzar un ataque mediante cross site scripting o cross site request forgery. Sin embargo, el cross site scripting suele considerarse mucho más peligroso.

Además, la cuestión del cross site request forgery tiende a ser más relevante para los plugins y las apps que para el diseño web, las agencias y las PYMES. Esto se debe a que la protección contra la CSRF es también una cuestión de programación. La CSRF podría ser relevante en el caso de las compras dentro del plugin, por ejemplo.

Pero, ¿cómo funciona ahora todo esto?

Anatomía del Cross Site Request Forgery

La idea básica de un ataque CSRF es relativamente sencilla y suele producirse en dos pasos:

• Se engaña a la víctima para que cargue un sitio web manipulado o haga clic en un enlace, por ejemplo, haciendo que parezca que el mensaje procede de una persona de confianza. O se aprovecha la curiosidad humana. En otras palabras, el phishing desempeña un papel importante en este tipo de ataque.
• Al cargar o hacer clic en los enlaces o sitios web manipulados, el navegador de la víctima ejecuta una petición HTTP sin que la víctima se dé cuenta de nada.

Dos ejemplos relativamente sencillos ilustran cómo funciona un ataque de este tipo.

Supongamos que Justus quiere transferir 100 € a Bob a través del sitio web www.bank.de y Skinny está al acecho para llevar a cabo un ataque CSRF. Skinny puede utilizar el método GET o POST para su ataque.

Por cierto, los siguientes ejemplos proceden de las siguientes fuentes:

• "Cross Site Request Forgery (CSRF)" - el artículo de revisión de OWASP
• “Preventing CSRF Attacks In WordPress Using Nonces”, por qnimate.com.

Cross Site Request Forgery por método GET

El método GET se utiliza para solicitar un recurso a un servidor, por ejemplo un archivo HTML. Simplemente se añaden a la URL los parámetros necesarios para la llamada. Y como ya sabemos por las inyecciones de SQL: una URL es relativamente fácil de manipular.

Justus se conecta a www.bank.de e introduce todos los datos necesarios. La siguiente entrada (completamente ficticia) se transmitiría al servidor:

GET http://bank.de/transfer.do?acct=BOB&betrag=100 HTTP/1.1

Skinny construye ahora una URL que transfiere 100.000 euros a su propia cuenta en su lugar. Su aspecto es el siguiente:

http://bank.de/transfer.do?acct=SKINNY&betrag=100000

Por supuesto, Justus tiene que llevar a cabo la acción oculta tras el enlace falso. Por lo tanto, Skinny envía a Justus un correo con un enlace falso. El código HTML puede tener este aspecto, por ejemplo:

<a href="http://bank.de/transfer.do?acct=SKINNY&betrag=100000">Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!</a>

O le envía un correo electrónico que contiene una imagen "invisible" (porque es de 0 por 0 píxeles). Al intentar cargar la imagen, el navegador accede a la URL sin que Justus se dé cuenta:

<img src="http://bank.de/transfer.do?acct=SKINNY&betrag=100000" width="0" height="0" border="0">

Cuando Justus accede al enlace -consciente o inconscientemente- se pasan los parámetros al servidor, se activa la transferencia y desaparecen 100.000 euros de su cuenta.

Por supuesto, Justus tiene que hacer clic en el enlace mientras está conectado. Pero si, por desgracia, hay una cookie de inicio de sesión de su banco en su navegador, el ataque funciona aunque no tenga el sitio web abierto en ese momento.

Esto es exactamente lo que hace que el cross site request forgery sea tan peligroso: es probable que Justus ni siquiera sepa que existe la cookie.

Cross Site Request Forgery por método POST

El método GET puede utilizarse en enlaces y, por tanto, es especialmente fácil de difundir. Sin embargo, ahora los/as proveedores/as pueden asegurarse de que, en principio, las solicitudes GET no reciban permiso de escritura.

Queda el método POST: en este caso, los datos se transfieren a un servidor para que pueda procesarlos posteriormente. Los datos no forman parte de la URL, sino que se añaden al header.

Puede parecer un poco engorroso, pero seguro que conoces el caso de uso, porque los formularios funcionan así.

Para nuestro atacante Skinny, esto significa que tiene que esforzarse más, pero aún así puede llegar a la portería.

El mismo escenario: Justus quiere transferir dinero a Bob. Así que rellena el siguiente formulario en www.bank.de:

<form method="POST" action="geld_ueberweisen.php">

    <input type="text" name="von">

    <input type="text" name="an">

    <input type="text" name="betrag_in_euro">

    <input type="submit">

</form>

Esto envía el comando money_transfer.php, que tiene el siguiente aspecto:

if(isset($_FORM["von"]) && isset($_FORM["an"]) &&isset($_FORM["menge_in_euro"]) && isset($_CMOKIE["user_eingeloggt"]))

{

    transMoney("von", "an", "betrag");

    echo "Überweisung erfolgreich!";

}

Como puedes ver, el código utiliza la cookie para comprobar primero si Justus está conectado. Solo así se ejecutará la transferencia.

Skinny deposita ahora un formulario invisible en un sitio web manipulado, por ejemplo:

<form method="POST" action="http://www.bank.de/geld_ueberweisen.php">

    <input type="text" name="von" value="Justus" style="display: hidden">

    <input type="text" name="an" value="Skinny" style="display: hidden">

    <input type="text" name="betrag_in_euro" value="100000" style="display: hidden">

    <input type="submit" value="Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!">

</form>

Envía el enlace a este sitio web manipulado a Justus. Este se siente desafiado, pulsa el botón para ver el puzzle y, sin saberlo, ejecuta la función geld_ueberweisen.php (el texto en alemán incita a resolver un puzzle difícil). Como esta encuentra una cookie correspondiente en su navegador, se vuelven a transferir 100.000 euros a Skinny.

Ataque mediante desvíos

Por eso se llama Cross Site Request Forgery, en español, falsificación de petición entre sitios: el comando suele enviarse desde otro sitio web. Para atacar el sitio web A, deposita código malicioso en el sitio web B. Luego atrae a la víctima hasta aquí para que su navegador ejecute el código. Luego atrae a la víctima desprevenida hasta aquí para que su navegador ejecute el código.

Cómo protegerte de los ataques CSRF

La buena noticia: el Cross Site Request Forgery se conoce desde hace mucho tiempo. Se conoce el riesgo y el desarrollo está trabajando específicamente para eliminarlo.

La mala noticia es que en realidad no puedes protegerte contra esto a nivel técnico. En la actualidad, el núcleo WordPress está relativamente bien protegido y, como puedes ver en las continuas actualizaciones, se trabaja constantemente en este. Como ocurre con otros tipos de ataques, la mayoría de las vulnerabilidades provienen de los plugins. Así que tienes que confiar en que el desarrollo de las extensiones que utilizas está haciendo un buen trabajo.

Eso significa específicamente:

• No instales demasiados plugins y solo instala los que realmente necesites.
• Ten cuidado con los plugins que llevan mucho tiempo sin actualizarse. Pueden ocultar brechas de seguridad no corregidas.
• Infórmate previamente sobre los plugins que vas a instalar, por ejemplo sobre su compatibilidad con otros plugins o sobre la versión de WordPress que utilizas (para que el plugin también pueda actualizarse).
• Actualiza regularmente los plugins y el núcleo WordPress. Esto se debe a que las actualizaciones continuas están ahí precisamente para cerrar esas brechas de seguridad.
• Sé crítico/a con el phishing.
• Si no estás seguro/a, echa un vistazo al plugin en el WP Repository. ¿Cómo son las valoraciones, cuáles han sido los mayores problemas en el pasado y es posible que el plugin no haya cerrado un agujero de seguridad importante?

Conclusión: El CSRF es cosa del pasado

El Cross Site Request Forgery existe desde el principio de la era digital. Además, el número de casos es extremadamente pequeño en comparación con los ataques de fuerza bruta.

Esto también lo confirma la evaluación de la OWASP: aqui se supone que el ataque está bastante extendido, es fácil de detectar y solo es grave en casos muy concretos.

Sin embargo, es bueno saber cómo funcionan los ataques. Porque los ataques a menudo solo funcionan gracias al error humano. Una y otra vez, los/as usuarios/as abren los correos electrónicos por curiosidad o hacen clic en enlaces que hubiera sido mejor no abrir.

La mejor forma de protegerte del Cross Site Request Forgery es investigar y utilizar un poco de sentido común.