La inyección de JavaScript se produce cuando un atacante consigue insertar y ejecutar código JavaScript no autorizado en una aplicación web. Esto puede dar lugar al robo de datos, al secuestro de sesiones o a otras acciones maliciosas. La prevención requiere una validación de entrada adecuada, una codificación de salida, la implementación de la Política de Seguridad de Contenidos y un manejo cuidadoso de la evaluación dinámica de código.
La inyección de JavaScript es la introducción y ejecución de JavaScript no autorizado dentro de una aplicación web. Llega al navegador por varias vías: fallos de cross-site scripting que devuelven entrada sin escapar en una página, la evaluación dinámica insegura de cadenas mediante eval, el constructor Function o los callbacks de temporizadores, scripts de terceros comprometidos o maliciosos cargados desde un CDN, y datos controlados por el atacante escritos en un contexto de script. Una vez que el código se ejecuta, el navegador lo trata como un script legítimo que pertenece al origen del sitio. Algunas definiciones también incluyen el self-XSS de la consola del navegador y de los bookmarklets, donde se engaña a un usuario para que pegue código del atacante. En todos los casos la característica definitoria es que acaba ejecutándose dentro de la página JavaScript que el desarrollador nunca pretendió.
El JavaScript inyectado se ejecuta con toda la autoridad del origen de la página, así que su alcance es amplio. Puede leer y exfiltrar cookies, tokens de sesión y contenido del DOM, secuestrar sesiones, registrar pulsaciones de teclas y campos de formularios, enviar peticiones de forma silenciosa, reescribir la interfaz y cargar payloads adicionales. En las páginas de pago este es el mecanismo detrás de los skimmers digitales y Magecart: unas pocas líneas añadidas a un script de confianza copian discretamente los campos de tarjeta y dirección al dominio de un atacante mientras los registros del servidor y los firewalls no ven nada, porque el robo ocurre enteramente en el navegador. Los atacantes suelen ofuscar el código y limitarlo a páginas o condiciones concretas para eludir las revisiones, dejando que un único script inyectado se ejecute sin detección entre muchos usuarios durante meses.
Reduce la superficie eliminando la evaluación dinámica de código, codificando la salida, validando la entrada y aplicando una Content Security Policy estricta con nonces o Subresource Integrity de modo que solo se ejecuten scripts contrastados. Pero una CSP confía en los scripts por su dominio de origen, así que un proveedor incluido en la lista de permitidos pero comprometido sigue ejecutándose. Aquí es donde encaja cside directamente: enruta los scripts de terceros a través de un método Script y analiza el payload real de JavaScript antes de que se ejecute, detectando comportamientos maliciosos, leer campos de tarjeta o contactar con un dominio desconocido, por lo que el código hace y no por dónde se carga. cside puede bloquear ese comportamiento en tiempo real y conserva un registro forense del código exacto que se ejecutó, que es lo que exigen PCI DSS 6.4.3 y 11.6.1.
El XSS es la forma más común en que ocurre la inyección de JavaScript, inyectando script a través de entrada sin escapar. Pero la inyección también puede producirse sin un fallo clásico de XSS: mediante un script de terceros comprometido, la evaluación insegura de datos dinámicos o un usuario engañado que pega código en la consola. El XSS es una vía hacia la inyección de JavaScript, no la única.
Una CSP restringe qué dominios y scripts en línea pueden ejecutarse, lo que bloquea muchas inyecciones, pero confía en cualquier script servido desde una fuente de la lista de permitidos. Si un proveedor que ya permites resulta comprometido, el código inyectado se ejecuta como legítimo. Detener eso requiere inspeccionar lo que hace realmente cada script, no solo de dónde viene.
We answer client-side security questions every day. Bring yours.