Las cookies como un peligro: Falsificación de solicitudes en sitios cruzados

Tobias Schüring Última actualización 21.01.2020
7 min.
Los ataques de falsificación de petición en sitios cruzados (CSRF) en WordPress  son uno de los ataques más antiguos de todos.

CSRF, esta abreviatura aparece repetidamente en las actualizaciones de seguridad y mantenimiento del WordPress Core. El método detrás de esto es ahora anticuado y aprovecha las abundantes cookies de un usuario de Internet. Afortunadamente, es bastante fácil protegerse de la falsificación de solicitudes en el sitio. Todo lo que necesitas es un poco de tiempo y atención.

Es probable que también utilices varios servicios que ofrecen la opción de seguir conectado incluso después de salir de sitio . Si a continuación vuelve a visitar sitio , no tendrá que volver a introducir los datos de acceso a tu , sino que se conectará directamente. Para el usuario, esto es, por supuesto, estupendo, porque -al igual que la gestión de contraseñas o el llamado Single Sign On- ahorra el molesto rellenado de formularios.

Lo siguiente ocurre en segundo plano: cuando usted se conecta a sitio por primera vez, el sitio web almacena una cookie en su 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 de caracteres generada aleatoriamente.

La próxima vez que visite el sitio web, el servidor comprobará esta cadena de caracteres y, si encuentra la contrapartida correspondiente, iniciará la sesión automáticamente. Esta es también la razón por la que se cierra la sesión en todas partes cuando se borra la caché del navegador. Porque todas las cookies también se eliminan durante este proceso.

Un ataque CSRF es, en esencia, un abuso de confianza.

Como puede ver, en un ataque correspondiente, el atacante engaña al servicio que lee las cookies para que crea algo. A continuación explico cómo sucede exactamente esto con dos ejemplos.

El peligro de esta manipulación radica en que un tercero, es decir, el atacante, realiza cambios en tu perfil de Facebook en tu nombre, por ejemplo. Sin embargo, la falsificación de solicitudes entre sitios también suele depender del phishing. Aquí también cobra relevancia la confianza, concretamente tu la confianza en, por ejemplo, los remitentes de los correos electrónicos.

Los ataques de Falsificación de Peticiones en Cross Site Request Forgery (CSRF) pueden ser prevenidos por el sentido común.

¿Cómo de vulnerable es WordPress ?

Probablemente no haya escuchado el término Cross-Site Request Forgery tan a menudo como Brute Force ataques o secuencias de comandos en el sitio web. Hay una razón para ello: la organización sin ánimo de lucro OWASP (Open Web Application Security Project) publica regularmente una lista de las diez vulnerabilidades más críticas en las aplicaciones web. En la lista preliminar para 2017 El CSRF ocupa el 8º lugar de 10. En 2007 y 2010, el ataque seguía ocupando el 5º lugar, En 2013, bajó al número ocho descendió.

Esto se debe probablemente en parte al hecho de que los ataques CSRF son casi tan antiguos como la propia Internet. Los desarrolladores profesionales tienen ahora mucha práctica en asegurar su código contra ellos. Así que los riesgos de seguridad son bastante fáciles y rápidos de solucionar.

WordPress también está al acecho. Por ejemplo, en mayo se publicó la actualización de seguridad 4.7.5, 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. A menudo El cross-site scripting suele considerarse mucho más peligroso.

Además, el problema de la falsificación de solicitudes entre sitios tiende a ser más relevante para Plugin- y los desarrolladores de aplicaciones que para los diseñadores web, las agencias y las pymes. Esto se debe a que la protección contra el CSRF es también una cuestión de programación. El CSRF podría ser relevante, por ejemplo, en el caso de las compras enPlugin.

Pero, ¿cómo funciona ahora todo el asunto?

La anatomía de la falsificación de solicitudes entre sitios web

La idea básica detrás de un ataque CSRF es relativamente simple y generalmente ocurre en dos pasos:

  1. El hacker engaña a la víctima para que cargue un sitio manipulado o haga clic en un enlace, por ejemplo, haciéndose pasar por una persona de confianza o explotando la curiosidad humana. En otras palabras, el phishing juega un papel importante en este tipo de ataque.
  2. Cuando los enlaces o páginas manipuladas se cargan o se hace clic en ellos, el navegador de la víctima ejecuta una petición HTTP sin que ésta se dé cuenta.

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

Para ello, vamos a suponer que Justus quiere contarle a Bob la sitio www.bank.de 100€, y Skinny está al acecho para realizar un ataque CSRF. Skinny puede ahora utilizar, por ejemplo, el método GET o POST para su ataque.

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

Falsificación de solicitud de sitio cruzado con el método GET

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

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

GET http://banco.es/transfer.do?acct=BOBetrag=100 HTTP/1.1

El Flaco construye ahora una URL que transfiere 100.000 euros a su propia cuenta. Se ve así:

http://banco.es/transfer.do?acct=SKINNYetrag=100000

Por supuesto, Justus tiene que realizar 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:

">¡Quien no pueda resolver este misterio no es un verdadero detective!

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:

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

Por supuesto, Justus tiene que hacer clic en el enlace mientras está conectado. Pero si, por desgracia, su navegador contiene una cookie de inicio de sesión de su banco el ataque funciona incluso si no ha abierto sitio .

Esto es exactamente lo que hace que la falsificación de solicitudes entre sitios sea tan insidiosa: la víctima puede ni siquiera ser consciente de que la cookie existe.

Falsificación de solicitudes entre sitios con el método POST

El método GET puede utilizarse en los enlaces y, por tanto, es especialmente fácil de difundir. Esto naturalmente juega a favor del atacante en términos de distribución. Ahora, sin embargo, los proveedores pueden asegurarse de que las solicitudes GET no reciban en principio permiso de escritura.

Queda el método POST: aquí se transfieren los datos a un servidor para que éste los siga procesando. Los datos no forman parte de la URL, sino que se añaden a la cabecera.

Puede sonar un poco voluminoso, pero seguro que conoces el caso de uso. Porque los formularios funcionan así.

Para nuestro atacante, el Flaco, eso significa que tiene que esforzarse más, pero aún puede llegar a su destino.

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

<formulario método="POST" acción="money_transfer.php">

    <entrada tipo="texto" nombre="de">

    <entrada tipo="texto" nombre="an">

    <entrada tipo="texto" nombre="importe_en_euro">

    <entrada tipo="submit" (enviar)>

formulario>

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 primero comprueba si Justus está conectado usando la cookie. Sólo si lo es, se ejecutará la transferencia.

Skinny ahora deposita un formulario invisible en una página web manipulada, por ejemplo

<formulario método="POST" acción="http://www.bank.de/geld_ueberweisen.php">

    <entrada tipo="texto" nombre="de" valor="Justus" estilo="display: hidden">

    <entrada tipo="texto" nombre="an" valor="flaco" estilo="display: hidden">

    <entrada tipo="texto" nombre="importe_en_euro" valor="100000" estilo="display: hidden">

    <entrada tipo="submit" (enviar) valor="¡Cualquiera que no pueda resolver este misterio no es un verdadero detective!">

formulario>

Él envía el enlace a este sitio web manipulado a Justus. Sintiéndose desafiado, pulsa el botón para ver el rompecabezas; y sin darse cuenta ejecuta la función money_transfer.php. Desde que encuentra una cookie correspondiente en su navegador, 100.000 euros son transferidos a skinny de nuevo.

Ataque mediante desvíos

Por eso el nombre CruzSite Request Forgery: El hacker suele enviar el comando desde otro sitio . Para atacar sitio A, deposita un código malicioso en sitio B. A continuación, atrae al usuario desprevenido hasta aquí para que su navegador ejecute el código. Luego atrae al usuario desprevenido para que su navegador ejecute el código.

¿Qué peligro tienen los ataques de falsificación de sitios cruzados (CSRF) en WordPress ?

Cómo protegerse de los ataques CSRF

La buena noticia es que la falsificación de peticiones en sitios cruzados existe desde hace mucho tiempo. Los desarrolladores conocen el riesgo y trabajan específicamente para eliminarlo.

La mala noticia es que no puedes protegerte contra eso en el aspecto técnico. El WordPress núcleo está ahora relativamente bien protegido, y como pueden ver en las actualizaciones en curso, se está trabajando constantemente en él. Como con otros tipos de ataques, la mayoría de las vulnerabilidades vienen con plugins él. Así que tienes que confiar en que los desarrolladores de las extensiones que usas están haciendo un buen trabajo.

Eso significa específicamente:

  • No instale demasiados Plugins y sólo los Plugins que realmente necesita.
  • Tenga cuidado con Plugins, que no ha sido actualizado por los desarrolladores desde hace tiempo. Aquí pueden esconderse vulnerabilidades de seguridad no corregidas.
  • Compruebe la compatibilidad del Plugins que está instalando con otros Plugins o la versión de WordPress que está utilizando (para poder actualizar el Plugin ).
  • Actualice regularmente tu Plugins y WP-Core. Porque las actualizaciones continuas están precisamente para cerrar esas brechas de seguridad.
  • Usted crítico en términos de phishing
  • Si no estás seguro: mira de cerca Plugin en el repositorio de WP. ¿Cómo resulta el valoraciones , cuáles fueron los mayores problemas en el pasado y si el Plugin no ha cerrado un agujero de seguridad importante?

Conclusión: el CSRF es algo antiguo

La falsificación de peticiones entre sitios ha existido desde el comienzo de la era digital. Además, el número de casos es extremadamente pequeño en comparación con, por ejemplo, los ataques deBrute Force .

Esto también lo confirma la evaluación de OWASP de que el ataque es más bien de bajo perfil, fácil de detectar, y grave sólo en algunos casos específicos. casos.

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

Por lo tanto, tanto si eres un usuario como si eres un usuario final, la mejor manera de protegerte de la falsificación de petición de sitios cruzados es con la investigación y un poco de sentido común.

Como administrador de sistemas, Tobias vigila nuestra infraestructura y encuentra cada tornillo para optimizar el rendimiento de nuestros servidores. Debido a sus incansables esfuerzos, a menudo se le puede encontrar por la noche en Slack .

Artículos relacionados

Comentarios sobre este artículo

Escribe un comentario

La dirección de correo electrónicotu no se publicará. Los campos obligatorios están marcados con *.