El XSS (Cross-Site Scripting) almacenado se produce cuando se almacenan permanentemente scripts maliciosos en los servidores de destino y luego se muestran a los usuarios que acceden a las páginas afectadas. Este tipo de XSS es particularmente peligroso, ya que afecta a todos los visitantes de la página comprometida. La prevención requiere una validación de entrada adecuada, una codificación de salida y políticas de seguridad de contenidos.
El cross-site scripting almacenado, también llamado XSS persistente, ocurre cuando una aplicación acepta contenido proporcionado por el atacante, lo guarda y más tarde lo sirve a otros usuarios sin codificarlo correctamente. El script malicioso se escribe una sola vez, en un campo de comentarios, la reseña de un producto, una publicación de un foro, un perfil de usuario o un ticket de soporte, y luego se ejecuta en el navegador de cada visitante que carga la página afectada. A diferencia del XSS reflejado, no hace falta ningún enlace creado a medida ni ingeniería social por víctima; el payload espera en el servidor y se dispara automáticamente. Como el marcado inyectado pasa a formar parte del contenido normal de la página, puede persistir mientras exista el registro y seguir infectando a nuevos visitantes.
El XSS almacenado es la variante de XSS más peligrosa porque se autopropaga y alcanza a todos los que ven la página envenenada. Un payload colocado en un hilo popular o en un perfil compartido puede ejecutarse en miles de sesiones, y si acaba en algún lugar que vea un administrador, puede escalar hasta el control total de la cuenta o la aplicación. Al ejecutarse bajo el origen del sitio, el script puede robar tokens de sesión y cookies que no sean HttpOnly, capturar pulsaciones de teclas y datos de formularios, actuar en nombre de la víctima o propagarse por sí mismo a más registros. Los gusanos de XSS históricos se propagaron exactamente así, añadiéndose a cada perfil que tocaban e infectando a nuevos usuarios en cada visita.
La defensa está principalmente del lado del servidor y del código: valida y sanea la entrada al recibirla, codifica la salida para su contexto exacto al emitirla y limpia cualquier HTML enriquecido con un saneador contrastado antes de que llegue al DOM. Una Content Security Policy limita lo que puede hacer un script inyectado aunque alguno se cuele. cside no reemplaza estos controles en el código de tu propia aplicación. Donde ayuda es en la capa de ejecución en el navegador: enruta los scripts de terceros a través de un método Script, analiza el payload de JavaScript que realmente se ejecuta, puede bloquear comportamientos maliciosos como la exfiltración de datos en tiempo real y conserva registros forenses que respaldan PCI DSS 6.4.3 y 11.6.1.
Porque el payload se guarda en el servidor y se sirve a todos los que abren la página afectada, no necesita ningún enlace ni clic por víctima. Una sola inyección puede ejecutarse en la sesión de cada visitante, y si un administrador la ve, el atacante puede obtener acceso elevado, lo que da al XSS almacenado un radio de impacto mucho mayor.
No. La vulnerabilidad tiene que ver con cómo se renderiza el contenido, no con dónde se guarda. Si los datos almacenados se insertan después en una página como HTML sin codificación ni saneamiento, se ejecutarán. Markdown incluso puede añadir riesgo si permite HTML sin procesar o enlaces inseguros, así que la salida debe sanearse igualmente.
We answer client-side security questions every day. Bring yours.