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

Tobias Schüring Última actualización 15.01.2020
6 min.
Cross-Site Scripting_XSS

XSS, inyección SQL, XMLrpc: cuando se publica una actualización de seguridad en WordPress , los informes de actualización contienen en su mayoría 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 tomar una decisión informada. Por eso, hoy vamos a analizar el cross-site scripting, o XSS, que es, con mucho, el ataque complejo más común en las páginas de WordPress .

Los ataques de los hackers pueden compararse con los de los ladrones. Brute Force Los ataques son más parecidos al método de la palanca. El delincuente se resiste a la herramienta hasta que la puerta o la ventana se abren. Los ataques a las vulnerabilidades XSS, por otro lado, son sofisticados: El ladrón sabe exactamente por dónde empezar y consigue un acceso selectivo a sitio.

Durante el 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 víctima. Estos ataques no son precisamente raros: Una buena mitad de las vulnerabilidades encontradas por el proveedor de seguridad Wordfence en 2015 y 2016 fueron vulnerabilidades de scripting entre sitios en Plugins .. A menudo, un ataque XSS constituye la "base" para 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 qué peligrosidad tienen.

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

El cross-site scripting es un peligro cuando una aplicación web reenvía los datos introducidos por el usuario al navegador web sin comprobar si hay código de script. Un buen ejemplo de este tipo de aplicación web 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 las imágenes 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. Todos los clientes que hubieran mirado de cerca la imagen en cuestión (por ejemplo, haciendo clic en la imagen) correrían el riesgo de ser atacados. 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 entonces los datos de las víctimas (¡los visitantes del sitiotus !). Do, ni siquiera el cifrado 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 cifrada 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 botnet que luego se alquila.

3 tipos de 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 de la siguiente manera: 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 es precisamente aquí donde se produce el daño, por ejemplo, el robo de 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, la página sitio muestra "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 aprovechan de forma inteligente: 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 ejecutarlo finalmente. Este tipo de ataque también se conoce como no persistente se denomina no persistente. Esto significa que el código malicioso sólo se inyecta temporalmente en la respectiva sitio , pero no se almacena.

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

Por ejemplo, un ataque de scripting cruzado reflejado podría tener este aspecto.
Por ejemplo, un ataque de scripting cruzado reflejado podría tener este aspecto.

Funciona asíEl atacante distribuye enlaces con parámetros manipulados a sus potenciales víctimas. 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.

secuencias de comandos cruzadas persistentes

Con el 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 verificación ni codificación (por ejemplo, los foros). Este tipo de secuencias de comandos puede ser especialmente peligroso en blogs y foros muy frecuentados, ya que el malware puede propagarse rápidamente en ellos debido al gran número de usuarios.

Este gráfico muestra una posible secuencia de un ataque persistente de cross-site scripting.
Flujo de un ataque persistente de scripting entre sitios. 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 (por ejemplo, con la ayuda de un comentario) a un mensaje normal del foro. un mensaje normal del foro con un script malicioso (por ejemplo, con la ayuda de un comentario). Los usuarios reciben por correo electrónico el enlace correspondiente al puesto o llegan a la entrada correspondiente por casualidad y ejecutan el script cuando llaman al puesto. La ventaja para el hacker es que ahora puede "espiar" a los clientes afectados o añadirlos a su red de bots para nuevos ataques.

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

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 está al tanto de tal ataque y las medidas de seguridad del lado del servidor tampoco ayudan.

Un ejemplo bien conocido de este tipo de vulnerabilidad es el caso del paquete genericon. El paquete genericon es un conjunto de iconos que es utilizado por muchos Plugins, incluyendo 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 podría 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 ser utilizado para manipular el sitio particular. Fuente: securityaffairs.co

Sin embargo, un 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 una brecha 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 scripting cruzado. Fuente: heise.de

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

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

Las vulnerabilidades XSS se encuentran entre las puertas de entrada más comunes 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 ella para conseguir sus propios objetivos.

Los XSS reflejados y persistentes son particularmente comunes, ya que el cross-site scripting local es más elaborado y difícil de implementar. Páginas que que reenvían los datos del usuario al navegador web sin comprobar la existencia de posibles códigos maliciosos están especialmente expuestos. Sin embargo, encontrar esos huecos no es tan fácil. En principio, esta es precisamente la tarea de los proveedores de seguridad como sucuri and Co, que desarrollan constantemente sus medidas de seguridad.

Pero, por supuesto, los usuarios normales de WordPress también pueden protegerse de estos ataques. La actualización de todos los componentes de WordPress , por ejemplo, es una medida sencilla pero muy eficaz. Cómo puede usted, como operador de un sitio, pero también como usuario de Internet, evitar el cross-site scripting, lo explicamos en nuestro siguiente artículo sobre el tema.

¿Todavía tiene comentarios o preguntas? Entonces, ¡deja un comentario!

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 *.