Permite a los atacantes implantar scripts maliciosos en un sitio web legítimo (también víctima del atacante) para ejecutar un script en el navegador de un usuario desprevenido que visita dicho sitio y afectarlo, ya sea robando credenciales, redirigiendo al usuario a otro sitio malicioso, o para realizar defacement en un sitio web.

En la actualidad, OWASP explica que son tres las formas de ataques de XSS más comunes que apuntan a los navegadores de los usuarios. Por eso, en este artículo actualizado repasamos cuáles son los vectores de ataque utilizados por los atacantes para explotar esta vulnerabilidad, qué puede realizar un atacante mediante Cross Site Scripting, y compartimos también algunos recursos que probablemente no conocías para identificar la vulnerabilidad o la explotación de la misma. Para tener una idea del impacto y el interés que los atacantes mantienen por esta vulnerabilidad, el último año más de 100.000 reportes de ataques de Cross Site Scripting según Vulners.

 XSS (Cross Site Scripting) es una vulnerabilidad que permite a un atacante insertar scripts o secuencias de código malicioso en el navegador web de un usuario. El ataque se produce en el código del sitio web que se ejecuta en el navegador, y no en el servidor del sitio. 

Los ataques de tipo XSS pueden tener diversas consecuencias para los usuarios, entre ellas:

• Recopilación de datos personales
• Robo de credenciales (usuarios y contraseñas)
• Robo de cookies
• Redireccionamiento a sitios maliciosos
• Acceso al control del equipo de la víctima
• Cambio de la apariencia visual del sitio

Existen tres tipos de XSS qué permiten que se lleve a cabo este ataque. A continuación, repasamos cuáles son y las medidas que deberíamos tomar para poder protegernos:

XSS indirecto o reflejado

Reflected Cross-Site Scripting

En un ataque de XSS reflejado el payload suele ser inyectado en un parámetro de la solicitud HTTP, para luego ser procesado por la aplicación web y finalmente desplegado en un punto determinado, sin algún tipo de validación o codificación de los caracteres. Se trata de la variedad de XSS más simple y el script malicioso que busca afectar el navegador de la víctima es fácilmente modificable, probablemente sin que el usuario note el ataque.

Como se puede observar en el siguiente ejemplo, se crea un enlace de apariencia normal sin un parámetro marcado y se observa un vector de ataque delimitado por el control del número de página del sitio.

https://insecure-site.example/blog/page/1/latest

El punto vulnerable en este caso es un parámetro que no es detectable a simple vista, pero alguna aplicación podría estar utilizando el valor proveniente de la URL para poder utilizarlo en el sitio, y así dar origen a la vulnerabilidad Reflected Cross-Site Scripting.

XSS directo o persistente o almacenado

Stored Cross-Site Scripting

Esta variante tiene como característica que la aplicación web guarda el valor de entrada en un medio de almacenamiento y persiste el script inofensivo, hasta que el valor es recuperado por la aplicación y utilizado para conformar parte del documento HTML.

Los puntos de entrada más conocidos en los cuales se suele observar esta vulnerabilidad están en los comentarios de sitios web, entradas de blog, nombres de usuario, chats, formularios de contacto, detalle de alguna orden, etc. Y así como existen diversos valores de entrada, un XSS persistente podría llegar de distintos medios. La respuesta del protocolo HTTP es el más común, así como mensajes mediante SMTP, servicios de mensajería instantánea, notificaciones vía socket, por mencionar algunos.

XSS basado en DOM

DOM-based Cross-Site Scripting

El Document Object Model (DOM) es una interfaz de programación para representar la estructura de un documento web y conectarlo con un lenguaje de scripting. En este sentido, el DOM facilita la estructura de documentos como HTML o XML y permite a los programas modificar la estructura, estilo y contenido del documento. En el caso de un ataque de XSS basado en DOM el payload malicioso es ejecutado como resultado de la modificación del entorno DOM en el navegador de la víctima. Esto lleva a que el usuario ejecute código desde el lado del cliente sin saber que lo está haciendo.

A partir de la evolución de muchas librerías de JavaScript es cada vez más común que se implemente el proceso de los datos desde fuentes no confiables (insegura o sin la adecuada codificación de los datos) desde el lado del cliente, usualmente escribiendo estos datos en el DOM del sitio web.

Algunas funciones en JavaScript que pueden ser un indicador de un posible punto vulnerable son:

• domain
• write()
• writeln()
• innerHTML
• insertAdjacentHTML
• onevent
• Element.outerHTML

Sin olvidar las librerías como JQuery, en donde utiliza métodos específicos para facilitar algunas funciones tradicionales del propio JavaScript, u otras librerías sin la adecuada codificación de los datos:

• $.parseHTML()
• add()
• after()
• animate()
• append()
• before()
• constructor()
• has()
• html()
• index()
• init()
• insertAfter()
• insertBefore()
• parseHTML()
• prepend()
• replaceAll()
• replaceWith()
• wrap()
• wrapAll()
• wrapInner()

Herramientas para identificar ataques y la explotación de Cross Site Scripting

Por suerte, existen muchas herramientas para identificar un ataque de Cross-Site Scripting e incluso la explotación utilizando scripts elaborados para diversos usos. Aquí es donde el framework Beef entra en acción con la amplia gama de scripts disponibles. A continuación se listan los más usuales.

• epsylon/xsser
• s0md3v/XSStrike
• ssl/ezXSS
• beefproject

Prevenir ataques XSS

Medidas de prevención para navegantes

Lo más sencillo para que los clientes eviten el Cross Site Scripting es desactivar JavaScript en el navegador. Si se hace eso el XSS basado en DOM, cuyo objetivo son los códigos de Java del explorador, no tiene ningún efecto, ya que no se ejecutará ningúna función maliciosa. Hay navegadores donde es posible activar Add-ons que protegen de ataques de XSS. Para Mozilla Firefox, por ejemplo, existe la extensión NoScript: su configuración estándard fija el bloqueo automático de contenidos activos tales como JavaScript, Java Applets, Adobe Flash o Microsoft Silverlight. Si se desea, se puede levantar el bloqueo temporalmente o configurar una lista blanca de páginas si estamos absolutamente seguros de que son de confianza. Y un último consejo que deberías tener siempre en cuenta en relación con los riesgos del Cross Site Scripting es que te mantengas siempre escéptico ante datos ajenos como los enlaces, que deberías siempre examinar detenidamente antes de abrir.

Medidas de prevención contra ataques de XSS para administradores web 

Sustituir los problemáticos caracteres meta HTML por referencias textuales, de forma que los caracteres meta se lean como texto y los archivos potencialmente infectados no se puedan ejecutar. Para ello, la mayoría de lenguajes de programación como Perl, JavaScript o PHP contienen funciones predefinidas para la sustitución o enmascaramiento de caracteres que puedes usar sin problemas. Los Web-Application-Firewalls (WAF) suponen también una efectiva defensa frente a ataques sencillos de XSS. 

Un ejemplo de equivalencias a string o cadena de caracteres de algunos de los caracteres usados para inyectar código es el siguiente:

 

OWASP nos ofrece un modelo preventivo bajo algunas reglas que deberíamos tomar en cuenta para evitar la ejecución de comandos en el navegador (XSS). Las mismas se describen de forma general a continuación:

• Implementar y habliar una política de seguridad bajo el encabezado CSP (Content Secure Policy) considerando al menos los siguientes puntos:
  • Evitar la ejecución de scripts insertados en HTML
  • Prevenir la carga de scripts de una fuente desconocida
  • Evitar el uso de funciones inseguras como Eval
  • Restringir el uso del tag HTML object
• Establecer el atributo de seguridad HttpOnly para reducir el impacto del ataque XSS
• Validar cualquier dato de entrada bajo una lista blanca de caracteres permitidos
• Codificar la salida de los datos, al menos para los caracteres especiales (&, <, >, “, ‘), en su respectivo código HTML según el contexto, ya sea JavaScript, CSS, HTML
• Utilizar las librerías para sanitizar los datos como HtmlSanitizer o inputfilter
  

Vulnerabilidad CSRF o Cross-site request forgery

Por último pero no por ello menos peligrosa para la seguridad de la tienda está la vulnerabilidad CSRF, del inglés Cross-site request forgery. Para entender esta vulnerabilidad supongamos que un usuario tiene abierto en su navegador una página web vulnerable a este ataque y otra web legítima como por ejemplo su cuenta de correo, dicha web vulnerable a CSRF por medio de un código malicioso previamente introducido, podría llevar a cabo una acción en la otra página legítima sin que el usuario sea consciente de ello. En este tipo de ataque los ciberdelincuentes suplantan la identidad de la víctima pudiendo llevar a cabo multitud de acciones maliciosas como por ejemplo alterar configuraciones en cuentas de correo o realizar movimientos bancarios no autorizados.

Para las vulnerabilidades descritas, y otras muchas que no han sido tratadas en este artículo, la principal vía para proteger el portal de eCommerce es contar con una correcta política de actualizaciones, la utilización de APIs de seguridad para validar los datos de entrada, etc.

Destacar que cuando una tienda electrónica cuenta con todos sus componentes actualizados a la última versión liberada por el desarrollador, la probabilidad de sufrir uno de estos ataques se reduce considerablemente. Esto es debido a que los fabricantes además de mejorar las funcionalidades del CMS encargado de gestionar la tienda, buscan vulnerabilidades y las corrigen mediante las respectivas actualizaciones de seguridad. En consecuencia, un eCommerce que cuente con todos sus componentes actualizados a la última versión probablemente estará menos expuesto a este tipo de problemas.

Fuentes:

https://www.welivesecurity.com/la-es/2021/09/28/que-es-ataque-xss-cross-site-scripting/

https://blog.hackmetrix.com/xss-cross-site-scripting/