Resumen: el riesgo de proteger solo las páginas de pago bajo PCI DSS
- Cumplimiento no es cobertura: PCI DSS 4.0 solo obliga a monitorizar scripts en las páginas de pago, así que los proveedores muestrean con gusto el 10% de las sesiones en un puñado de URLs y lo llaman cumplimiento, mientras dejan las páginas de login, KYC y de cuenta abiertas exactamente a la misma clase de scripts de terceros.
- Cada página, cada sesión: Una dependencia alojada en CDN comprometida plantó cuatro backdoors distintas en aproximadamente 1.000 sitios simultáneamente; cside se sitúa entre el tercero y el usuario en cada página, ofrece visibilidad completa de scripts en el 100% de las sesiones y a menudo mejora el rendimiento gracias a la caché.
- Antes de firmar: Antes de tu próxima firma de PCI DSS 6.4.3, decide si el XSS en páginas que no son de pago, el secuestro de sesión de usuarios autenticados con MFA y los ataques de cadena de suministro en scripts auxiliares entran dentro del alcance de tu programa de seguridad web.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
PCI DSS 4.0 ya está aquí. A partir de marzo de 2025, exige que los portales de pago cuenten con un mecanismo para autorizar cada script en las páginas de pago. Los sitios web deben mantener un inventario de todos los scripts (al menos en esos portales de pago) y garantizar su integridad. Ahora es necesario detectar y responder a modificaciones no autorizadas en las páginas de pago, incluidos cambios en las cabeceras HTTP y el contenido de las páginas. Las organizaciones deben verificar estas configuraciones al menos una vez cada siete días o según lo determine su evaluación de análisis de riesgos.
Lee los requisitos completos aquí.
Otra línea importante: PCI DSS 4.0 ahora fomenta un cambio de las auditorías anuales hacia la monitorización continua de la seguridad, lo que implica revisiones y actualizaciones periódicas de los componentes del sistema y del software.
¡Por fin!
Por el momento, solo los portales de pago están obligados a contar con un sistema para controlar el JavaScript de terceros. Por eso, muchos de nuestros competidores (lee lo que pensamos sobre ellos aquí) limitan sus servicios a unas pocas páginas. Algunos incluso muestrean la sesión, de modo que solo el 10% de las sesiones están protegidas.
Pero eso es buscarse problemas.
Por qué deberías proteger todas las páginas
Sigue existiendo riesgo de brecha de datos si no aseguras todas las páginas.
Los actores maliciosos podrían usar scripts comprometidos en otras partes de tu sitio para secuestrar sesiones de usuario. Esto les permitiría suplantar a usuarios legítimos y realizar acciones no autorizadas, pudiendo incluso eludir algunas formas de autenticación de dos factores. Eso podría acabar sorteando la protección de scripts de terceros en los portales de pago.
Otra área que dejarías expuesta al riesgo son las vulnerabilidades de Cross-site scripting (XSS). Permiten a los atacantes inyectar scripts maliciosos en páginas web vistas por otros usuarios. Si solo el portal de pago está protegido, otras páginas podrían ser explotadas para ejecutar ataques XSS, afectando igualmente los datos y la privacidad de los usuarios.
Los ataques a la cadena de suministro tampoco quedan totalmente bloqueados. Los scripts de terceros son un vector habitual para los ataques a la cadena de suministro. Si los atacantes comprometen un proveedor o un script utilizado en todo tu sitio, concentrar las protecciones solo en el portal de pago no impedirá la explotación a través de otras integraciones de terceros. Un único script alojado en CDN de cdn.csyndication[.]com se utilizó para plantar cuatro backdoors distintas en 1.000 sitios web de forma simultánea: una sola dependencia comprometida, cuatro puntos de entrada para el atacante.
Las vulnerabilidades de Ejecución Remota de Código (RCE) e Inyección de Comandos son riesgos significativos que muestran aún más por qué necesitas proteger todas las páginas, no solo las áreas críticas como los portales de pago. RCE permite a los atacantes ejecutar código arbitrario en tu servidor, lo que puede derivar en un compromiso total del sistema. Esto puede ocurrir mediante el manejo inseguro de entradas de usuario, como la evaluación de código subido por usuarios o inyectado a través de campos de formulario.
Las vulnerabilidades de Inyección de Comandos surgen cuando entradas de usuario no seguras se ejecutan como comandos del sistema, especialmente a través de entradas JavaScript incorrectamente saneadas. Esto puede permitir a los atacantes manipular acciones del servidor o acceder a bases de datos del backend, lo que lleva a cambios no autorizados en los datos o a su robo.
Por último, la ingeniería social y el phishing son una amenaza real. Los atacantes podrían modificar contenido o redirigir a los usuarios a sitios maliciosos, engañándolos para que proporcionen información sensible.
Otras vulnerabilidades
Incluso si tus portales de pago están protegidos y la protección funciona, otras páginas siguen corriendo el riesgo de ser vulneradas.
Si eso ocurre, sigues arriesgándote a perder la confianza de los usuarios y podrías enfrentar implicaciones legales o regulatorias, especialmente en relación con leyes de protección de datos como el RGPD o la CCPA. Los daños derivados de esas sanciones, o el daño reputacional, son difíciles de cuantificar. Pero ahí están.
Así que hazlo bien, desde ya
Al igual que las reglas de PCI DSS 4.0, también animamos a cualquier propietario de sitio web a adoptar la monitorización continua de la seguridad. Y espero haber dejado claro que hacerlo en todas las páginas es la mejor opción.
El nivel gratuito de cside hace que tu sitio cumpla con PCI DSS en lo relativo a scripts de terceros, y funciona en todas las páginas. Sin embargo, nuestro enfoque es diferente al de la competencia. Nuestro script reescribe las fuentes de otros scripts de tu sitio para enrutarlos a través de cside y realizar algunas detecciones en el lado del navegador. Esto hace que cside se sitúe en el flujo de la solicitud entre el usuario y el script de terceros sin añadir latencia, y en algunos casos incluso mejora el rendimiento mediante el almacenamiento en caché de scripts estáticos.
Esto ofrece una visibilidad total de los scripts servidos, en el 100% de las sesiones y en todas las páginas, protegiéndote tanto a ti como a tus usuarios.
Si quieres saber más sobre cómo nuestro enfoque se diferencia del resto, visita esta página.
