Qué es un ataque XSS o Cross-Site Scripting?

Ataque XSS

Cross-site Scripting (XSS) es una vulnerabilidad de seguridad que normalmente se encuentra en sitios web y/o aplicaciones web que aceptan información del usuario. Algunos ejemplos incluyen motores de búsqueda, formularios de inicio de sesión, tablones de mensajes y cuadros de comentarios. 

Los ciberdelincuentes aprovechan esta vulnerabilidad introduciendo cadenas de código malicioso ejecutable en estas funciones. Esto inyecta el código malicioso en el contenido del sitio web objetivo, haciéndolo parte del sitio web y permitiéndole así afectar a las víctimas que pueden visitar o ver ese sitio web. El código también puede presentarse como contenido transitorio que en realidad no forma parte del sitio web, pero que solo parece ser para el visitante. Esto hace que parezca que el sitio web está realmente comprometido por cibercriminales. 

Los cibercriminales también pueden utilizar esta vulnerabilidad para tomar el control o comprometer directamente un sitio web, así como explotar otras vulnerabilidades existentes en el servidor o software del sitio web. 

Cómo funciona XSS

  • Los ciberdelincuentes eligen su sitio web objetivo y analizan sus funciones vulnerables que aceptan la entrada del usuario. Algunos ejemplos son barras de búsqueda, formularios de inicio de sesión y cuadros de comentarios. 
  • Introducen código malicioso en la función que eligen. El código malicioso podría escribirse utilizando lenguaje de programación como HTML o JavaScript, entre otros. 
  • El código malicioso se inyecta en la página web que resulta de la función (resultados de búsqueda o un comentario en una página de comentarios). A continuación, se convierte en parte de esa página web, lo que la pone en peligro. 
  • Dependiendo de cómo se inyecte el código, es posible que el contenido malicioso ni siquiera esté en la propia página web, sino como un elemento transitorio que solo parece formar parte del sitio web durante la instancia particular de la explotación. Esto puede crear la ilusión de que el sitio web real está realmente comprometido, cuando en realidad no lo está. 
  • Los usuarios pueden convertirse en víctimas de la página web comprometida al ser vinculados a ella por los cibercriminales responsables o tropezarse con ella, dependiendo de la función que los culpables decidieron abusar. 
  • Las rutinas en las que el código inyectado podría ejecutarse en el sistema de una víctima pueden variar desde lo molesto inofensivamente hasta lo totalmente malicioso. Podría ser tan inofensiva como una imagen inesperada que se muestra entre el contenido publicado legítimamente en ese sitio web, a algo que redirige al usuario a un sitio web malicioso y/o descarga archivos maliciosos en su sistema automáticamente. También se puede utilizar para robar información personal crítica de la víctima, como información de inicio de sesión. 

¿Por qué XSS es peligroso? 

Con XSS, los cibercriminales pueden convertir sitios web de confianza en maliciosos, lo que provoca daños y perjuicios desmesurados no solo a las víctimas, sino también a la reputación del propietario del sitio web de confianza. 

Los sitios web que se ven comprometidos por XSS pueden provocar cualquier número de amenazas para atacar el sistema de un usuario. Esto puede implicar cualquier cosa, desde contenido inapropiado que se muestra hasta malware que se descarga en el sistema sin que el usuario lo sepa. 

¿Qué pueden hacer los usuarios? 

Por muy peligroso que sea XSS, existen formas de aplicar parches a dicha vulnerabilidad. Los propietarios de sitios web deben asegurarse de que todas sus aplicaciones web que acepten la entrada del usuario lo hagan de forma que desinfecten primero las cadenas introducidas antes de crear la página resultante de la entrada. Esto evita que se produzca cualquier inyección de código. Los usuarios, por otro lado, deben deshabilitar el scripting en sus navegadores, así como evitar hacer clic en enlaces de remitentes o partes sospechosas. 

Los desarrolladores/propietarios de sitios web deben: 

  • Asegúrese de que cualquier página de su sitio web que acepte entradas de usuario filtra las entradas de código, como HTLM y JavaScript. 
  • Busque vulnerabilidades de aplicaciones web y aplique parches en consecuencia 
  • Actualice su software de servidor y sitio web para evitar la explotación futura de vulnerabilidades que también pueden ser objetivo a través de un ataque XSS. 

Los usuarios deben: 

  • Desactive el scripting en páginas en las que no son necesarias o desactívelas por completo. 
  • Evite hacer clic en enlaces de correos electrónicos sospechosos o publicaciones en tablones de mensajes, ya que pueden dar lugar a páginas comprometidas. 
  • Acceda a los sitios web deseados directamente a través de su dirección y no a través de una fuente o enlace de terceros. 
  • Actualice regularmente el software y las aplicaciones de su sistema para evitar la explotación de vulnerabilidades secundarias. 

Tipos de ataques XSS

Según Open Web Application Security Project (OWASP), los ataques XSS se dividen en una de tres categorías: XSS reflejado, XSS almacenado y XSS modelo de objetos de documento (DOM). Estos se detallan a continuación. 

Ataque de scripting entre sitios reflejado (no persistente) 

Un ataque XSS reflejado se produce cuando un hacker entrega un script malicioso a una aplicación web vulnerable, que el servidor vuelve a la respuesta HTTP. El navegador de la víctima ejecuta el script malicioso como parte de la respuesta HTTP, comprometiendo al usuario legítimo y enviando información privada de vuelta al hacker. 

Los ataques de XSS reflejados normalmente se dirigen a mensajes de error o páginas de resultados de motores de búsqueda, ya que es fácil enviar un correo electrónico malicioso con un enlace en el que muchos usuarios harán clic. Cuando el usuario hace clic en el enlace, el servidor recibe la solicitud que contiene el script malicioso y, dado que no está almacenado, responde enviando un código de vuelta al usuario. Cuando las entradas de los usuarios no se validan y desinfectan adecuadamente, o cuando los datos se duplican de forma insegura a partir de una solicitud, existe el riesgo de vulnerabilidades de XSS reflejadas. 

La primera línea de defensa frente a los ataques XSS es filtrar el contenido y verificar las entradas del usuario. Puede utilizar listas seguras y listas de bloqueo de proveedores de scripts para rechazar patrones de datos de riesgo. 

Además, puede implementar una estricta Política de seguridad de contenido (CSP) para ayudarle a identificar el origen de los scripts en línea, reduciendo el riesgo de ataques XSS reflejados. Un CSP sólido le proporciona control de scripts y las ubicaciones de las páginas web donde se pueden cargar y ejecutar. 

Ataque de scripting entre sitios almacenado (persistente) 

En un ataque XSS almacenado, un script malicioso guarda la entrada del usuario en el servidor de destino. A diferencia de un ataque XSS reflejado, que se ejecuta en el servidor, un ataque XSS almacenado se ejecuta en el navegador del usuario. A continuación, los atacantes utilizan aplicaciones HTML5 modernas, normalmente con bases de datos HTML, para almacenar permanentemente scripts dañinos en el navegador. 

En un ataque XSS almacenado, el script se guarda y ejecuta en el servidor cada vez que el usuario accede al sitio web afectado. Es fácil para un atacante dirigirse a un gran número de víctimas y el resultado es persistente. Los ataques de XSS almacenados también pueden producirse cuando los usuarios sin formación intentan extraer datos del software sin tomar precauciones de desinfección o validación. 

Los ataques XSS almacenados tienen como objetivo reflejar un script malicioso a un usuario, por lo que la forma más fácil de evitarlos es desinfectar los datos del usuario y gestionar las entradas cuidadosamente, y la mejor forma de evitarlos es utilizar la vinculación de parámetros adecuada. 

Puede desinfectar los datos con un sistema de plantilla de escape automático o codificación HTML. Debe codificar los datos destinados a la salida para evitar que el servidor los interprete como contenido activo. Esto significa que la aplicación manejará caracteres especiales en sus datos guardados como contenido de etiqueta HTML, en lugar de HTML simple. 

La unión de parámetros (datos) de datos varía según el vector, pero siempre puede pasar variables como valores adicionales fuera de la funcionalidad normal de la función. También puede utilizar encabezados de respuesta adecuados para evitar ataques, normalmente solo añadiendo algunas líneas de código. 

Otra técnica para evitar que se produzcan ataques de XSS en tiempo real es emplear una seguridad dinámica que busque activamente intentos de explotación. Al bloquear patrones conocidos, puede evitar que los atacantes aprovechen los loopholes existentes. 

Por último, puede utilizar firewalls de aplicaciones web (WAF) para la detección y mitigación de ataques XSS en tiempo real. 

Ataque de scripting entre sitios del modelo de objetos de documento (DOM) 

La interfaz DOM permite el procesamiento y la manipulación del contenido de la página web leyendo y modificando documentos HTML y XML. Los ataques XSS basados en DOM introducen cambios maliciosos en el contexto DOM del navegador de la víctima, lo que provoca que el código del lado del cliente se ejecute de forma no intencionada. 

Los ataques XSS basados en DOM, a diferencia de los ataques XSS reflejados y almacenados, no almacenan el script malicioso ni lo envían al servidor. En este ataque, el navegador de la víctima es la única vulnerabilidad. Dado que son más difíciles de entender que otras categorías, las vulnerabilidades basadas en DOM son poco comunes, sofisticadas y difíciles de superar. Además, los escáneres de vulnerabilidades automatizados y los firewalls de aplicaciones web no pueden identificarlos fácilmente. 

Puede utilizar las mismas técnicas para evitar este ataque que las de los otros dos, pero debe tener especial cuidado para desinfectar el código del lado del cliente. Dos soluciones eficaces son evitar que las fuentes controladas por el usuario cambien las funciones potencialmente peligrosas de JavaScript (conocidas como fregaderos) o permitir solo contenido fiable utilizando una lista segura. Con estas precauciones, las cuerdas que podrían poner en peligro el DOM no se enviarán a los fregaderos. También puede desinfectar los datos utilizando la funcionalidad de navegador integrada, reduciendo el riesgo de problemas relacionados con el cambio de analizador. 

Una defensa novedosa contra este tipo de ataque es utilizar tipos de confianza. Este es un mecanismo de seguridad del navegador que garantiza que todas las partes peligrosas del DOM solo puedan ser utilizadas por datos que hayan pasado una política predefinida. Evita que las cadenas arbitrarias se pasen a fregaderos potencialmente peligrosos, lo que ayuda al navegador a diferenciar entre código y datos, eliminando la principal fuente de vulnerabilidad. 

XSS del lado del servidor frente a XSS del lado del cliente 

Los ataques XSS se clasifican como servidor XSS o cliente XSS. Los programas del lado del cliente se ejecutan en el dispositivo o navegador del cliente y se encargan de la interfaz de usuario y cualquier otro procesamiento que tenga lugar en el dispositivo del cliente. Los programas del lado del servidor operan en servidores y crean el contenido de una página web. 

XSS del lado del servidor se produce cuando todo el código del lado del servidor es vulnerable y el navegador renderiza la respuesta y ejecuta cualquier script legítimo incrustado en él. Por otro lado, XSS del lado del cliente se ejecuta en el dispositivo del usuario y modifica una página web después de que se ha cargado. 

Un ataque XSS es posible en cualquier lugar donde haya HTML. Tanto si están almacenados, reflejados o basados en DOM, todos los ataques XSS tienen el mismo efecto: Un atacante obtiene el control total de una sesión web. 

Estos ataques de XSS también pueden solaparse y un sitio web puede ser vulnerable a los tres simultáneamente. En el caso de un solo sitio web o una aplicación sin conexión, los tres tipos de ataque podrían presentarse directamente en el navegador. Sin embargo, su comportamiento puede diferir cuando los datos se guardan en el servidor en comparación con cuando se reflejan desde el servidor. 

Investigaciones relacionadas