Cross-Site Scripting_XSS

Cross-Site Scripting - Cómo los hackers secuestran tu sitio

XSS, inyección SQL, XMLrpc: cuando se publica una actualización de seguridad de WordPress, los informes de actualización contienen sobre todo siglas crípticas. Aunque está claro que estas actualizaciones son necesarias y el plus de seguridad es muy agradable, es importante entender qué hay detrás de estas vulnerabilidades de seguridad. Porque sólo si entiendes qué lagunas cierran las actualizaciones, podrás también tomar una decisión informada. Por eso, hoy veremos el cross-site scripting, o XSS, que es, con mucho, el ataque complejo más común en los sitios de WordPress.

Los ataques de los hackers pueden compararse con los de los ladrones. Los ataques de fuerza bruta son más bien el método de la palanca. El delincuente sigue empujando contra la herramienta hasta que la puerta o la ventana se abren. Los ataques a las vulnerabilidades XSS, en cambio, son sofisticados: El ladrón sabe exactamente por dónde empezar y consigue un acceso selectivo a un sitio.

En el curso del cross-site scripting, se explotan deliberadamente las brechas de seguridad de los sitios web. Los hackers inyectan scripts maliciosos en un contexto de confianza (¡páginastu !). Al igual que un polizón en un barco, este código malicioso utiliza tu sitio como vehículo para perseguir sus propios objetivos.

En el peor de los casos, los atacantes consiguen así información confidencial o acceso al ordenador del usuario afectado. Estos ataques no son precisamente raros: La mitad de las vulnerabilidades de los plug-ins encontradas por el proveedor de seguridad Wordfence en 2015 y 2016 eran vulnerabilidades de scripting entre sitios.. Un ataque XSS suele ser la "base" de otros ataques, como el spam, el phishing o los ataques DDoS. Por eso, hoy te mostraré cómo funciona exactamente el cross-site scripting, qué tipos de ataques hay y cuán peligrosos son.

El cross-site scripting siempre funciona de forma similar: a través de una brecha, el código malicioso llega tu sitio

El cross-site scripting es siempre un peligro cuando una aplicación web reenvía los datos introducidos por el usuario al navegador web sin comprobar si hay código script. Un buen ejemplo de una aplicación web de este tipo es un chat de asistencia.

A través de la propia aplicación web los scripts maliciosos pueden llegar al servidor. A partir de ahí, el código malicioso acaba tarde o temprano en los clientes afectados. Un buen ejemplo de este tipo de vulnerabilidad XSS es el fallo descubierto en julio de 2016 en los metainfos de imagen en WooCommerce 2.6.2. Un fallo permitía a los atacantes inyectar código HTML en las meta descripciones de las imágenes desde el exterior. Cualquier cliente que mirara la imagen en cuestión más de cerca (por ejemplo, haciendo clic en la imagen) correría el riesgo de ser atacado. Por ejemplo, un hacker podría haber infectado los ordenadores de los clientes de tus con un virus.

Truco popular para el cross-site scripting: formularios manipulados

El XSS también puede permitir a los hackers sustituir formularios inofensivos por otros manipulados. Estos formularios recogen los datos de las víctimas (tus visitantes del sitio!). Do, ni siquiera la encriptación SSL puede proteger contra esto. HTTPS "sólo" significa que la conexión entre el servidor y el cliente está cifrada. Sin embargo, si el propio formulario ha sido manipulado, incluso una conexión encriptada es inútil.

Al igual que con otros tipos de ataques, el objetivo de los hackers suele ser monetizar sus maquinaciones. En concreto, esto significa que los atacantes roban datos que luego venden o quieren infectar sitios para integrarlos en una llamada red de bots que luego se alquila.

3 tipos de XSS: XSS reflejado, persistente y local

Los ataques de scripting cruzado pueden dividirse a grandes rasgos en tres tipos:

A grandes rasgos, los ataques XSS funcionan como sigue: Se inyecta código malicioso donde se espera la entrada del usuario (por ejemplo, en una búsqueda interna de la página). Como parte de la respuesta del servidor, el código malicioso se ejecuta en el cliente, es decir, en el navegador del usuario. Y aquí es exactamente donde se produce el daño, por ejemplo, se roban los datos de los usuarios.

Secuencia de comandos cruzada reflexiva

Algunas entradas, como las consultas de búsqueda, son reflejadas por el servidor. Esto significa que, por ejemplo, después de introducir "test" en el campo de búsqueda, en sitio aparece "Has buscado test". Así, lo que el usuario introduce pasa a formar parte de la respuesta del servidor.

Esto es exactamente lo que los atacantes explotan con astucia: Si se envía un script malicioso al servidor web en lugar de un término de búsqueda, el sitio puede ser manipulado para que finalmente lo ejecute. Este tipo de ataque también se conoce como no persistente tipo de ataque. Así, el código malicioso sólo se infiltra temporalmente en la respectiva sitio , pero no se almacena.

En julio, se encontró una vulnerabilidad de este tipo en el plugin WP Statistics (¡y ya se arregló el mismo día!). Un valor de entrada en la página sitio 'wps_visitors_page' se reenvió sin comprobar, lo que condujo a una vulnerabilidad a través de XSS reflejado. De este modo, se podría hackear un sitio si un administrador hubiera hecho clic previamente en un enlace manipulado de forma correspondiente.

Un ataque de scripting cruzado reflejado puede tener este aspecto, por ejemplo.
Un ataque de scripting cruzado reflejado puede tener este aspecto, por ejemplo.

Funciona asíEl atacante distribuye enlaces con parámetros manipulados a sus víctimas potenciales. Sin saberlo, el usuario envía una petición "manipulada" al servidor haciendo clic en el enlace, y el código malicioso se ejecuta junto con la respuesta del servidor. Como el código -a diferencia del XSS persistente- no se almacena en ningún sitio, el hacker debe distribuirlo en masa a las víctimas potenciales. Esto puede ocurrir, por ejemplo, a través del correo o de las redes sociales.

Secuencia de comandos persistente en el sitio web

En el caso del XSS persistente, los scripts maliciosos se almacenan en el servidor web y se entregan cada vez que son llamados por un cliente. Están predestinadas a ello las aplicaciones web que almacenan los datos de los usuarios en el servidor y luego los emiten sin comprobarlos ni codificarlos (por ejemplo, los foros). Este tipo de scripting puede ser especialmente peligroso en blogs y foros muy frecuentados, ya que el malware puede propagarse rápidamente debido al gran número de usuarios.

Este gráfico muestra una posible secuencia de un ataque persistente de cross-site scripting.
Secuencia de un ataque persistente de secuencias de comandos en sitios cruzados. Fuente: Blog SAP

Ejemplo: In un foro, las contribuciones publicadas se almacenan en una base de datos. No es infrecuente que se almacenen sin comprobar y sin cifrar. Los atacantes aprovechan esta oportunidad y añaden un script malicioso a un post del foro con un script malicioso (por ejemplo, con la ayuda de un comentario). Los usuarios reciben por correo electrónico el enlace respectivo a la entrada o llegan a la entrada correspondiente por casualidad y ejecutan el script cuando llaman a la entrada. Ventaja para el hacker: ahora puede "espiar" a los clientes afectados o añadirlos a su red de bots para nuevos ataques.

Secuencia de comandos del sitio cruzado basada en el DOM o local

A diferencia del XSS persistente y reflejado, el cross-site scripting basado en el DOM (Document Object Model) funciona ejecutando scripts del lado del cliente. Esto significa que el servidor no es consciente de dicho ataque y las medidas de seguridad del lado del servidor tampoco ayudan.

Un ejemplo bien conocido de esta brecha es el caso del paquete genericon. El paquete genericon es un conjunto de iconos que utilizan muchos plug-ins, incluido Jetpack. Era posible inyectar código malicioso a través de un archivo HTML en este conjunto de iconos.

Tras introducir esta URL, apareció una alerta de javascript. Esto es una prueba de que el código javascript introducido puede ser utilizado para manipular el respectivo sitio .
Tras introducir esta URL, apareció una alerta de JavaScript. Esto es una prueba de que el código JavaScript introducido podría utilizarse para manipular el respectivo sitio . Fuente: securityaffairs.co

Sin embargo, el requisito previo para un ataque XSS basado en el DOM es que el usuario haga clic en una URL manipulada. Al llamar a esta URL, el código malicioso puede ejecutarse a través de un hueco en un script del lado del cliente. Entre otras cosas, el hecho de que primero haya que hacer clic en un enlace hace que el XSS basado en el DOM sea un tipo de ataque algo más difícil y, por tanto, menos probable.

El gráfico muestra una posible secuencia de un ataque local de cross-site scripting.
Ejemplo de un ataque local de secuencias de comandos en sitios cruzados. Fuente: heise.de

Ejemplo: El usuario hace clic en la URL manipulada y envía una petición a la aplicación web. La aplicación responde pasando el código del script (que es defectuoso pero no manipulado) al navegador para que inicie la ejecución del script. Los parámetros manipulados de la URL se interpretan ahora en el navegador del usuario como parte del script y se ejecutan. La página web que se muestra en el navegador se modifica así y el usuario ve ahora -sin darse cuenta- el sitio manipulado.

Conclusión: Bastante frecuente y no exenta de peligro, por lo que es importante una protección adecuada.

Las vulnerabilidades XSS son una de las puertas de entrada más frecuentes para el código malicioso. Y un ataque correspondiente suele ser la base de otros ataques, como el spam, el phishing o los ataques DDoS. Los atacantes secuestran tu sitio y abusan de él para conseguir sus propios objetivos.

Los XSS reflejados y persistentes son especialmente comunes, ya que el cross-site scripting local es más elaborado y difícil de implementar. Páginas que Los datos del usuario en el navegador web sin comprobar la existencia de un posible código malicioso están especialmente en peligro. Sin embargo, encontrar esos huecos no es tan fácil. En principio, ésta es precisamente la tarea de los proveedores de seguridad, como sucuri y otros, que desarrollan constantemente sus medidas de seguridad.

Pero, por supuesto, también hay una manera de que los usuarios normales de WordPress se protejan de estos ataques. La actualización de todos los componentes de WordPress, por ejemplo, es una medida sencilla pero muy eficaz. El modo en que tú, como operador de un sitio, pero también como usuario de Internet, puedes evitar el cross-site scripting se explica en nuestro siguiente artículo sobre el tema.

¿Tienes algún comentario o pregunta? Entonces, ¡deja un comentario!

¿Te ha gustado el artículo?

Con tu valoración nos ayudas a mejorar aún más nuestro contenido.

Escribe un comentario

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