¿Qué es el cross-site scripting (XSS)?

XSS: definición y causa

Un sitio web se vuelve vulnerable cuando incorpora sin comprobar a sus páginas entradas de los usuarios, como comentarios, términos de búsqueda o datos de perfil. Si la entrada contiene código de script, el navegador del siguiente visitante lo ejecuta como si formara parte de la página. Así, el código tiene los mismos derechos que el código legítimo de la página.

El XSS figura desde hace años entre las vulnerabilidades más frecuentes de las aplicaciones web y se incluye en el OWASP Top 10 dentro de la categoría Injection. A diferencia de la inyección SQL, el objetivo inmediato no es el servidor, sino los visitantes y los administradores del sitio web.

Los tres tipos de XSS

En el XSS almacenado (stored), el código malicioso se guarda de forma permanente, por ejemplo en un comentario, y afecta a todo el que abra la página. En el XSS reflejado (reflected), está en un enlace manipulado que se envía, por ejemplo, en un correo de phishing. En el XSS basado en DOM, el fallo surge solo por el JavaScript del navegador, que escribe datos en la página de forma insegura.

• Toma de control de sesiones y cuentas de usuario
• Lectura de entradas, como contraseñas o datos de pago
• Presentación de formularios falsos en la página auténtica
• Redirección a sitios maliciosos
• Ataques a administradores a través del back end

Ejemplo práctico: la valoración en la tienda online

Una tienda online permite valoraciones de productos y muestra el texto sin filtrar. Un atacante deja, en lugar de una valoración, un pequeño script. Cuando más tarde un administrador de la tienda abre la valoración en el back end, el script podría capturar su clave de sesión y darle al atacante acceso a la administración.

La tienda se protege codificando las salidas según el contexto, de modo que los scripts aparezcan solo como texto, asegurando las cookies de sesión con los atributos HttpOnly y SameSite y aplicando una política de seguridad de contenidos (CSP) que solo admite fuentes de script autorizadas. El back end sanea además las valoraciones antes de mostrarlas.

Protección, límites y puesta en práctica

La medida más importante es la codificación de salida adecuada al contexto: los datos se escapan antes de mostrarse, de modo que el navegador los trate como texto y no como código. Los frameworks modernos como React lo hacen por defecto, salvo que los desarrolladores lo eludan deliberadamente. La CSP limita el daño si aun así se cuela algo; el HTML permitido, por ejemplo el de los editores de texto, se depura con bibliotecas comprobadas.

Nano Concepts revisa aplicaciones web y tiendas en busca de XSS, corrige fallos en el código y en los plugins y configura cabeceras HTTP relevantes para la seguridad, como la política de seguridad de contenidos. En los proyectos nuevos nos aseguramos desde el principio de que las entradas de los usuarios nunca lleguen a las páginas sin comprobar.

• Mostrar entradas sin comprobar en las páginas, sobre todo en comentarios y campos de búsqueda
• Usar innerHTML o funciones similares con datos de usuarios
• Confiar solo en filtros de entrada en lugar de en la codificación de salida
• Integrar scripts y plugins de terceros sin revisarlos
• Sin política de seguridad de contenidos y con cookies sin proteger