Cross Site Scripting

Cross Site Scripting: Cómo se secuestra a tu sitio web

XSS, SQL Injection, XMLrpc: Cuando se publica una actualización de seguridad WordPress, los informes de actualización contienen en su mayoría siglas crípticas. Aunque está claro que estas actualizaciones son necesarias y que el plus en seguridad es muy agradable, es importante entender qué hay detrás de estas vulnerabilidades de seguridad porque solo si entiendes qué lagunas cierran las actualizaciones podrás también tomar una decisión con conocimiento de causa. Por eso hoy nos ocuparemos del Cross Site Scripting, o XSS, que es con diferencia el ataque complejo más común contra los sitios WordPress.

Los ataques de hacker pueden compararse a un robo. Los ataques de fuerza bruta se parecen más al método de la palanca. Los delincuentes se resisten a la herramienta hasta que se abre la puerta o la ventana. Los ataques a vulnerabilidades XSS, en cambio, son sofisticados. Los delincuentes saben exactamente por dónde empezar y acceden a un sitio web de forma muy selectiva.

En el Cross Site Scripting, se explotan deliberadamente las brechas de seguridad de los sitios web. En este caso, se inyectan scripts maliciosos en un contexto de confianza (¡el sitio webtu !). Al igual que un polizón en un barco, este código malicioso utiliza tu sitio web como vehículo para perseguir sus propios objetivos.

En el peor de los casos, se obtiene así información confidencial, o incluso acceso al ordenador del usuario víctima. Este tipo de ataques no son precisamente raros: una buena mitad de las vulnerabilidades en plugins detectadas por el proveedor de seguridad Wordfence en 2015 y 2016 eran vulnerabilidades de cross site scripting. Un ataque XSS suele ser la "base" de otros ataques, como spam, phishing o ataques DDoS. Por eso hoy te mostraré cómo funciona exactamente el Cross Site Scripting, qué tipos de ataques hay y lo peligrosos que son.

El Cross Site Scripting tiene un principio básico

El Cross Site Scripting funciona según el principio básico de explotar una laguna e inyectar código malicioso en tu sitio web. Siempre es un peligro que una aplicación web reenvíe los datos introducidos al navegador web sin comprobar la existencia de un posible código script. Un ejemplo ilustrativo de este tipo de aplicación web es un chat de soporte.

Los scripts maliciosos pueden llegar al servidor a través de la propia aplicación web. Desde allí, el código malicioso acaba tarde o temprano en los clientes afectados. Un buen ejemplo de una vulnerabilidad XSS de este tipo es el fallo descubierto en julio de 2016 en los meta-infos de las imágenes en WooCommerce 2.6.2. Debido a un error, era posible introducir de contrabando código HTML en las meta-descripciones de las imágenes desde el exterior. Cualquier dispositivo en el que ahora se viera más de cerca la imagen afectada (por ejemplo, haciendo clic en la imagen) corría el riesgo de ser atacado. Así, entre otras cosas, los ordenadores en los que se visualizara esta imagen podrían haber sido infectados con un virus.

"*"indica que los campos son obligatorios

Me gustaría suscribirme a newsletter para estar informado sobre nuevos artículos del blog, ebooks, funciones y noticias sobre WordPress. Puedo retirar mi consentimiento en cualquier momento. Ten en cuenta nuestra Política de privacidad.
Este campo es de validación y no debe modificarse.

Truco popular para el Cross Site Scripting: Formularios manipulados

El XSS también puede permitir sustituir formularios inofensivos por otros manipulados. Estos formularios recogen entonces los datos de las víctimas (¡en tu sitio web!). Por cierto, ni siquiera el cifrado SSL puede proteger contra esto. HTTPS "solo" significa que la conexión entre el servidor y el cliente está encriptada. Sin embargo, si el propio formulario está manipulado, incluso una conexión encriptada es inútil.

Como ocurre con otros tipos de ataques, el objetivo en la mayoría de los casos es la monetización. En concreto, esto significa que, o bien se roban datos para luego venderlos, o bien los sitios web infectados se integran en una denominada botnet, que luego se alquila.

3 Tipos de XSS

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

  • Cross Site Scripting Reflejado
  • Cross Site Scripting persistente
  • Cross Site Scripting local o basado en DOM

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

Cross Site Scripting Reflejado

Algunas entradas, como las consultas de búsqueda, son reflejadas por el servidor. Esto significa que, por ejemplo, tras introducir "test" en el campo de búsqueda, el sitio web muestra "Has buscado test". El texto introducido pasa a formar parte de la respuesta del servidor.

Esto es precisamente lo que se explota astutamente: si se envía un script malicioso al servidor web en lugar de un término de búsqueda, se puede manipular el sitio web para que finalmente lo ejecute. Este tipo de ataque también se denomina "no persistente". En otras palabras, el código malicioso solo se inyecta temporalmente en el sitio web correspondiente, pero no se almacena.

En julio de 2017, se encontró una vulnerabilidad de este tipo en el plugin WP Statistics (¡y se solucionó el mismo día!). Un valor de entrada en la página sitio 'wps_visitors_page' se reenviaba sin comprobar, lo que provocaba una vulnerabilidad mediante XSS reflejado. Así, si un admin había hecho clic previamente en un enlace manipulado de forma correspondiente, se podía piratear un sitio web.

Cross Site Scripting XSS Reflejado
Este es el aspecto que puede tener un ataque de secuencia de comandos en sitios cruzados reflejado (cross site scripting reflejado).

Funciona así: se difunden enlaces con parámetros manipulados a las víctimas potenciales. Sin saberlo, la víctima 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. Dado que el código (a diferencia del XSS persistente) no se almacena en ninguna parte, debe distribuirse en masa a las víctimas potenciales. Esto puede ocurrir, por ejemplo, a través de correos electrónicos o redes sociales.

Cross Site Scripting Persistente

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 datos del usuario en el servidor y luego los emiten sin comprobarlos ni codificarlos (incluidos los foros). Este tipo de scripts 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/as.

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

Ejemplo: en un foro, los posts publicados se almacenan en una base de datos. No es infrecuente que se almacenen sin comprobar y sin cifrar. Esta oportunidad se aprovecha fácilmente y permite añadir un script malicioso a un post completamente normal del foro (de forma sencilla con la ayuda de un comentario). Los/as usuarios/as reciben el enlace correspondiente al post por correo electrónico o llegan a la entrada correspondiente por casualidad y ejecutan el script cuando llaman al post. Ahora, por ejemplo, los/as clientes/as afectados/as podrían ser "espiados/as" o añadidos/as a una red de bots para futuros ataques.

Cross Site Scripting basado en DOM (o local)

A diferencia del XSS persistente y reflejado, el Cross Site Scripting basado en DOM (Document Object Model) funciona ejecutando scripts del lado del cliente. El servidor no es consciente de tal ataque y las medidas de seguridad del lado del servidor tampoco ayudan.

Un ejemplo bien conocido de esta laguna es el caso de genericon package. Genericon package es un conjunto de iconos que utilizan muchos plugins. 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 demuestra que el código JavaScript introducido podía utilizarse para manipular el sitio web en cuestión. Fuente: securityaffairs.co

Sin embargo, un requisito previo para un ataque XSS basado en DOM es que se haga clic en una URL manipulada. Al acceder 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 DOM sea un tipo de ataque algo más difícil y, por tanto, menos probable.

Secuencia de comandos en sitios cruzados XSS local
Ejemplo de ataque local de secuencia de comandos en sitios cruzados (cross stie scripting basado en DOM).

Ejemplo: la URL manipulada se pulsa y envía una petición a la aplicación web. La aplicación web responde pasando el código del script (que es defectuoso pero no manipulado) al navegador para iniciar la ejecución del script. Los parámetros manipulados de la URL se interpretan ahora en el navegador del cliente como parte del script y se ejecutan. De este modo, el sitio web que se muestra en el navegador se modifica y los/as usuarios/as ven ahora el sitio web manipulado sin darse cuenta.

Medidas contra el Cross Site Scripting

Las mejores medidas contra los ataques de secuencia de comandos en sitios cruzados son sencillas de aplicar. Lo mejor es confiar en actualizaciones periódicas, cortafuegos y listas blancas. En segundo lugar, también se puede asegurar la salida del servidor.

Actualizaciones periódicas

Las vulnerabilidades a través de las cuales se infiltra el código malicioso se encuentran en el núcleo de WordPress, en los plugins o en los temas. Precisamente por eso son tan importantes las actualizaciones periódicas de todos estos componentes. Porque las vulnerabilidades que se han encontrado hasta ahora se solucionan en estas actualizaciones.

También tiene sentido leer regularmente los detalles de las actualizaciones para hacerse una idea de qué vulnerabilidades de seguridad se cierran regularmente mediante las actualizaciones. Para las actualizaciones de mantenimiento y seguridad del núcleo de WordPress, por ejemplo, esta información está documentada en el blog de WordPress.

Cortafuegos y listas blancas contra ataques XSS simples

Otra medida de protección sencilla contra los ataques XSS son los llamados cortafuegos de aplicaciones web, o WAF. Estos cortafuegos son el corazón de los grandes plug-ins de seguridad y son alimentados con las últimas vulnerabilidades por el respectivo equipo de investigación del fabricante. Por lo general, un WAF es un procedimiento que protege las aplicaciones web de los ataques a través del Protocolo de Transferencia de Hipertexto (HTTP).

Sin embargo, incluso estos mecanismos de protección tienen sus límites. En algunos ataques XSS, el ataque se produce a través de la base de datos. Por lo tanto, comprobar la entrada del usuario en busca de código malicioso es uno de los mecanismos de seguridad centrales en la lucha contra los ataques XSS. Por ejemplo, el contenido de los comentarios se escanea en busca de cadenas de caracteres sospechosas y se elimina si es necesario.

La salida de datos también debe estar asegurada

Regelmäßige Updates schließen vorhandene XSS Sicherheitslücken und Firewalls sowie Whitelists versuchen Schadcode auszufiltern, bevor dieser den Webserver erreicht und die Website infizieren kann. Doch sollte auch die Datenausgabe entsprechend gesichert werden. Die meisten Programmier- und Skriptsprachen, wie PHP, Perl oder JavaScript, besitzen hierfür bereits vordefinierte Funktionen zur Zeichenersetzung bzw. -maskierung. Diese sorgen dafür, dass „problematische“ HTML Metazeichen wie <> und & durch harmlose Zeichenreferenzen ersetzt werden. So wird verhindert, dass der Schadcode aktiv werden kann. Auch sollte der Code mithilfe von sogenannten sanitization libraries bereinigt werden. Hierfür wird ein Plugin auf dem Server installiert und zusätzlicher Code in den Quellcode deiner Website eingebunden. Der folgende Codeschnipsel sorgt dann zum Beispiel dafür, dass <class> zu den erlaubten Attributen hinzugefügt wird:

var sanitizer = new HtmlSanitizer();
sanitizer.AllowedAttributes.Add("class");
var sanitized = sanitizer.Sanitize(html);

Se necesitan conocimientos de programación para ponerlo en práctica. Esta protección de salida de datos es fácil de implementar para alguien con estos conocimientos.

Una buena dosis de escepticismo: cómo se protegen los usuarios

Pero no sólo el propio sitio web, también los clientes (es decir, los navegadores tu ) se ven afectados por los ataques XSS. Muchos ataques XSS pueden evitarse mediante un manejo crítico y cuidadoso de los enlaces "extraños". Entre otras cosas, existe la posibilidad de utilizar complementos NoScript. Éstos impiden la ejecución de scripts, es decir, las líneas de código dañinas que roban datos, entre otras cosas.

Los que quieran ir sobre seguro también pueden evitar el cross-site scripting del lado del cliente simplemente desactivando la compatibilidad con JavaScript en el navegador. Porque si se desactiva el llamado scripting activo, ciertos tipos de ataques XSS ya no tienen oportunidad, ya que las aplicaciones dañinas ni siquiera se inician. Sin embargo, la mayoría de los sitios web modernos dejan de "funcionar" correctamente o, en el peor de los casos, dejan de funcionar. Por tanto, es necesario sopesar los aspectos de seguridad y usabilidad. Si te interesa esta opción, puedes encontrarla en la configuración de tu navegador.

Conclusión

Las vulnerabilidades XSS se encuentran entre las puertas de entrada más frecuentes para el código malicioso. Y el ataque correspondiente suele ser la base de otros ataques, como spam, phishing o ataques DDoS. Tus sitios web son secuestrados y utilizados indebidamente para otros fines. Por tanto, el XSS no está exento de peligro, y por eso es importante una protección adecuada.

Los XSS reflejados y persistentes son especialmente comunes, ya que el cross site scripting basado en DOM resulta más complejo y difícil de implementar. Los sitios web que reenvían los datos del usuario al navegador sin comprobar la existencia de un posible código malicioso corren un riesgo especial. Sin embargo, encontrar estas brechas no es tan fácil. En principio, esta es precisamente la tarea de los proveedores de seguridad como sucuri y Cía., que desarrollan constantemente sus medidas de seguridad.

Pero, por supuesto, también hay una forma de que WordPress normal se proteja de estos ataques. Las actualizaciones de todos los componentes de WordPress son, entre otras cosas, una medida sencilla pero muy eficaz. Si mantienes actualizados los plugins y temas de tu y utilizas un WAF, ya has dado un gran paso en la dirección correcta. Si además utilizas listas blancas para el código entrante y saliente, ya habrás asegurado tu de forma excelente. Sin embargo, las dos últimas medidas en particular no son fáciles de aplicar sin conocimientos de programación.

En comparación con los ataques de fuerza bruta, más bien primitivos, los ataques XSS más complejos siguen teniendo éxito, por desgracia, con relativa frecuencia. Sin embargo, hay muchos menos de estos ataques denominados complejos que ataques de fuerza bruta en los sitios web de WordPress. No obstante, debes ponérselo lo más difícil posible a estos ataques. Un ataque exitoso no sólo cuesta tiempo y dinero para eliminar los scripts, sino que también puede poner en peligro la posición de tu en los motores de búsqueda.

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