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

7 Min.
Los ataques de Falsificación de Peticiones en Sitios Cruzados (CSRF) WordPress están entre los más antiguos de la historia.

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 utilice una serie de servicios en los que existe la opción de permanecer conectado incluso después de haber abandonado el sitio. Si vuelve a visitar el sitio, no tendrá que volver a introducir sus datos de acceso, sino que se conectará directamente. Esto es, por supuesto, genial para el usuario, porque es - al igual que una gestión de contraseñas o un llamado un solo registro - un cansado formulario de llenado.

Lo siguiente sucede en segundo plano: Cuando se entra al 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. Si te quedas conectado, es una cadena de caracteres generada al azar.

La próxima vez que visite el sitio web, el servidor comprueba esta cadena de caracteres y, si puede encontrar la contraparte correspondiente, lo conecta automáticamente. Esto es por cierto la razón por la que estarás desconectado en todas partes, cuando tengas Caché del navegador vacío. Esto se debe a que todas las cookies también se eliminan durante este proceso.

Un ataque de CSRF es esencialmente un abuso de confianza

Ya se ha dado cuenta: con un ataque correspondiente, el atacante finge algo al servicio que lee las cookies. A continuación se explica cómo ocurre exactamente esto con dos ejemplos.

El peligro de esta manipulación radica en el hecho de que un tercero, es decir, el atacante, por ejemplo, hace cambios en su perfil de Facebook en su nombre. Sin embargo, la falsificación de solicitudes en sitios cruzados también suele depender de la suplantación de identidad (phishing). Aquí, también, la confianza se vuelve relevante - su confianza en el remitente de los correos electrónicos, por ejemplo.

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

¿Cuánta gente está WordPress en peligro de extinción?

Probablemente no haya escuchado el término Falsificación de Solicitudes en Sitios Cruzados tan a menudo como Brute Force Ataques o escritura de sitios cruzados. 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 el lista preliminar para 2017 El CSRF ocupa el 8º lugar de 10. En 2007 y 2010 el ataque todavía aterrizó en el 5º lugar, En 2013 subió al octavo lugar de la que no se puede prescindir.

Una razón para esto es probablemente que los ataques CSRF son casi tan antiguos como la propia Internet. Los desarrolladores profesionales son ahora hábiles en asegurar su código contra ellos. Por lo tanto, los riesgos de seguridad se arreglan fácil y rápidamente.

Con WordPress uno también está en guardia. Por ejemplo, en mayo se publicó la actualización de seguridad 4.7.5, que corrigió seis vulnerabilidades que podrían haber sido utilizadas por los piratas informáticos a través de secuencias de comandos o falsificación de solicitudes en sitios cruzados. A menudo pero aún así escritura de sitios cruzados se considera mucho más peligroso.

Además, la cuestión de la falsificación de solicitudes en varios sitios tiende a ser más pertinente para Plugin- y los desarrolladores de aplicaciones que para los diseñadores web, las agencias y las PYMES. Porque la protección contra el CSRF es también una cuestión de programación. El CSRF podría ser relevante, por ejemplo, para enPlugin-...serán comprados.

¿Pero cómo funciona todo esto ahora?

La anatomía de la falsificación de la solicitud de cruce de páginas

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

  1. El hacker hace que la víctima cargue una página manipulada 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. Al cargar o hacer clic en los enlaces o páginas manipulados, el navegador de la víctima ejecuta una solicitud HTTP sin que la víctima lo note.

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

Asumamos que Justus quiere llevar a Bob al sitio www.banco.es Transfiera 100 euros, y Skinny estará atento a un ataque de CSRF. Skinny puede ahora usar el método GET o POST para su ataque.

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

Falsificación de solicitudes en sitios cruzados para el método GET

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

Así que Justus se conecta en www.banco.es 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

Skinny ahora construye una URL que transfiere 100.000 euros a su propia cuenta en su lugar. Se parece a esto:

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

Por supuesto que Justus tiene que ejecutar la acción escondida detrás del enlace falso. Por lo tanto, Flaco envía a Justus un correo con un enlace falso. El código HTML podría verse así, por ejemplo:

">Si no puedes resolver este misterio, no eres un verdadero detective!

O le envía un correo electrónico que contiene una imagen "invisible" (porque 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 transfieren al servidor, la transferencia se inicia y 100.000 euros desaparecen de su cuenta.

Por supuesto que Justus tiene que hacer clic en el enlace mientras está conectado. Pero si desafortunadamente hay una cookie de acceso de su banco en su navegador el ataque funciona aunque no haya abierto la página en ese momento.

Esto es exactamente lo que hace que la Falsificación de Peticiones en Sitios Cruzados sea tan retorcida: la parte perjudicada puede ni siquiera ser consciente de que la galleta existe.

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

El método GET puede utilizarse en los enlaces y, por lo tanto, es particularmente 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 de GET no reciban permiso de escritura por principio.

El método POST permanece: Aquí los datos se transfieren a un servidor para que puedan ser procesados más adelante. Los datos no forman parte de la URL, sino que se adjuntan al encabezamiento.

Puede sonar un poco voluminoso, pero estoy seguro de que conoces la aplicación. Porque las formas funcionan de esta manera.

Para nuestro atacante, Skinny, esto significa que aunque tenga que hacer más esfuerzo, aún puede alcanzar su objetivo.

El mismo escenario: Justus quiere transferirle dinero a Bob. Así que se llena www.banco.es el siguiente formulario:

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

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

    <entrada escriba="texto" nombre="en">

    <entrada escriba="texto" nombre="amount_in_euro">

    <entrada escriba="presentar">

formulario>

Esto envía el comando geld_ueberweisung.php que se ve así

si(isset($_FORM["de"]) && isset($_FORM["en"]) &&isset($_FORM["crowd_in_euro"]) && isset($_CMOKIE["user_logged in"]))

{

    transMoney("de", "en", "cantidad");

    eco "¡Transferencia exitosa!";

}

Como puedes ver, el código primero comprueba si Justus está conectado usando la cookie. Sólo si lo es, la transferencia será ejecutada.

Skinny ahora deposita una forma invisible en un sitio web manipulado, por ejemplo.

<formulario método="POST" acción="http://www.banco.com/money_transfer.php">

    <entrada escriba="texto" nombre="de" valor="Justus" estilo="pantalla: escondida">

    <entrada escriba="texto" nombre="en" valor="Flaco" estilo="pantalla: escondida">

    <entrada escriba="texto" nombre="amount_in_euro" valor="100000" estilo="pantalla: escondida">

    <entrada escriba="presentar" valor="¡El que no puede 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.

atacar por medios engañosos

De ahí el nombre Cruza-Falsificación de solicitud de sitio: El hacker suele enviar el comando desde otro sitio. Por lo tanto, para atacar el lado A, deposita código malicioso en el lado B. Luego atrae al usuario desprevenido hasta aquí para que su navegador ejecute el código.

¿Qué tan peligrosos son los ataques de Cross Site Request Forgery (CSRF)WordPress ?

Cómo protegerse contra los ataques de CSRF

La buena noticia: La falsificación de solicitudes en sitios cruzados ha existido por años. Los desarrolladores conocen el riesgo y están trabajando duro 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.

Esto significa concretamente:

  • No instale demasiados Plugins y sólo el Pluginsque realmente necesitas
  • Cuidado con Pluginslos que no han sido actualizados por los desarrolladores durante mucho tiempo. Los agujeros de seguridad no resueltos pueden ser escondidos aquí.
  • Averigua sobre el Pluginsque instalas, por ejemplo, sobre su compatibilidad con otros Plugins o la WordPress versión que está usando (para que Pluginpueda ser actualizada).
  • Actualice su Pluginsy el WP-Core regularmente. Porque las continuas actualizaciones están exactamente ahí para cerrar esos agujeros de seguridad.
  • Usted es crítico con el phishing
  • Si no estás seguro, echa un vistazo Plugin en el depósito de WP. ¿Cuáles son los índices de audiencia, cuáles fueron los mayores problemas en el pasado, e hizo el Plugin una brecha de seguridad de alto perfil puede no haber sido cerrada?

Conclusión: El CSRF es un sombrero viejo

La falsificación de solicitudes en sitios cruzados ha existido virtualmente desde el comienzo de la era digital. Además, el número de casos ha aumentado en comparación con, por ejemplo, el de Brute Force Ataques extremadamente pequeño.

Esto también confirma la evaluación del OWASPAquí se supone que el ataque es más bien pequeño, fácil de detectar y sólo en ciertos casos específicos graves es.

Aún así, es bueno saber cómo funcionan los ataques. Porque a menudo los ataques sólo funcionan gracias a un error humano. Una y otra vez, por curiosidad, los usuarios abren los correos o hacen clic en los enlaces que no deberían haber abierto.

Así que ya sea un usuario o un operador, la mejor manera de protegerse de la falsificación de solicitudes en sitios cruzados es usar la investigación y un poco de sentido común.

Artículos relacionados

Comentarios sobre este artículo

Escriba un comentario

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