Cross-site scripting (XSS), manipulación del DOM y código skimmer inyectado

El cross-site scripting (XSS) en palabras sencillas

El cross-site scripting es una familia de fallos que permite a un atacante hacer que el navegador de una víctima ejecute el JavaScript del atacante como si fuera parte de su sitio. Ocurre cuando un sitio incluye en una página datos que no controlaba (un término de búsqueda, un comentario, un campo de formulario, un parámetro de la URL) sin tratarlos de forma segura. OWASP describe tres tipos comunes:

• XSS almacenado: el sitio guarda la entrada maliciosa (por ejemplo en una reseña o un perfil) y la sirve a todo visitante que la vea.
• XSS reflejado: la entrada se devuelve de inmediato en una respuesta, normalmente mediante un enlace manipulado que se convence a la víctima de abrir.
• XSS basado en DOM: el fallo está en el propio JavaScript de la página, que toma datos de algún lugar, como la barra de direcciones, y los escribe en la página de forma insegura.

En una página de pago, un fallo de XSS es peligroso porque el script inyectado se ejecuta con acceso total al formulario. Un skimmer que llega así no necesita ningún acceso a sus servidores.

Otras vías por las que llega un script a una página de pago

El XSS es solo una vía. Los incidentes documentados y la investigación describen varias más:

• Complementos, temas y extensiones vulnerables o maliciosos. Los sistemas de gestión de contenido y las plataformas de tienda dependen de complementos. Uno desactualizado o mal escrito puede permitir que un atacante escriba en archivos o en la base de datos, y uno malicioso puede contener un skimmer desde el principio.
• Bibliotecas vulnerables. Las versiones antiguas de bibliotecas de front-end con fallos conocidos pueden aprovecharse para ejecutar scripts o alterar lo que carga la página.
• Credenciales robadas. Los atacantes con una contraseña de administrador válida, un acceso de hosting o de FTP, o acceso a una canalización de despliegue pueden simplemente editar una plantilla o un script. El phishing y la reutilización de contraseñas son fuentes comunes.
• Terceros comprometidos. Se compromete un proveedor, un gestor de etiquetas o un servicio de alojamiento en el que su página ya confía. Vea riesgo de JavaScript de terceros y riesgo de los gestores de etiquetas.
• Almacenamiento o CDN mal configurado. Si el lugar donde se guardan sus scripts permite escribir a quien no debería, los archivos pueden ser reemplazados.

El malware en el dispositivo de un cliente o una extensión de navegador maliciosa también pueden manipular una página, pero eso queda fuera de lo que controla la página del comercio; los controles de esta biblioteca tratan de lo que entregan su sitio y sus proveedores.

Cómo es la manipulación del DOM

El Modelo de Objetos del Documento (DOM) es la estructura viva de la página en el navegador. Cualquier script al que se permita ejecutarse en la página puede cambiarlo, y los skimmers lo usan de varias maneras:

• añadir campos adicionales a un formulario, o un formulario invisible que recoja los mismos datos;
• escuchar las pulsaciones de teclas o el envío del formulario y copiar los valores;
• colocar un formulario de pago falso sobre uno real, o quitar un iframe de pago incrustado y poner un formulario en su lugar;
• vigilar los cambios de la página para que el skimmer solo se active en el paso de pago;
• envolver las funciones de solicitud del propio navegador para que los datos enviados con un fin legítimo se copien también a otro lugar.

Como estos cambios ocurren en el navegador, después de cargada la página, el HTML que envía su servidor puede estar perfectamente limpio. Por eso PCI DSS 11.6.1 habla de las páginas de pago tal como las recibe el navegador del consumidor, y por eso importa revisar el contenido entregado y no solo su repositorio. Vea la explicación del requisito 11.6.1.

Cómo dificultar la inyección y detectarla antes

Prevenir

• Tratar los datos de forma segura al construir las páginas. Codifique la salida según el contexto donde se escribe y evite escribir datos no confiables en la página con métodos inseguros. Las hojas de referencia de OWASP sobre prevención de XSS y de XSS basado en DOM dan reglas prácticas.
• Usar una Política de Seguridad de Contenido. Una política estricta limita qué scripts pueden ejecutarse y adónde pueden enviarse datos, y puede contener el daño de un fallo de XSS. Vea Política de Seguridad de Contenido para páginas de pago.
• Considerar Trusted Types. Esta función del navegador, hoy compatible con los navegadores basados en Chromium (consulte MDN para el soporte actual), ayuda a evitar que cadenas inseguras se conviertan en script.
• Aplicar parches con prontitud. Mantenga la plataforma, los complementos y las bibliotecas actualizados y elimine los que no use. El requisito 6.3.3 de PCI DSS trata de la instalación de parches de seguridad.
• Proteger las vías de entrada. Use autenticación multifactor para los administradores, limite quién puede publicar cambios y proteja los sistemas de compilación y despliegue.
• Desarrollar con seguridad. El requisito 6.2.4 de PCI DSS trata de técnicas para prevenir ataques comunes en software a medida y personalizado.

Detectar

• Compare los scripts y las cabeceras que un navegador recibe realmente con una línea base aprobada y avise de las diferencias: cómo detectar la manipulación del lado del cliente.
• Revise sus cabeceras de seguridad, porque un atacante que debilita la Política de Seguridad de Contenido está preparando el terreno para un skimmer.
• Monitoree los cambios de archivos en sus servidores y los registros de auditoría de su sistema de gestión de contenido y de sus herramientas de despliegue.