Los ataques de robo de datos roban la información de las tarjetas de pago directamente desde los navegadores de sus clientes. Estos ataques operan por completo del lado del cliente, lo que significa que su WAF, su SIEM y los registros de su servidor no ven nada inusual mientras los números de tarjeta fluyen hacia servidores controlados por los atacantes. Según una investigación de DataDome, los ataques de Magecart han comprometido más de 2 millones de sitios web en todo el mundo desde el primer ataque ejecutado a gran escala en 2015.
cside monitorea los scripts de terceros a medida que se ejecutan en sesiones reales del navegador, detectando la exfiltración de datos no autorizada y los cambios en los scripts en menos de 60 segundos de media. Este artículo explica qué es la protección contra el robo de datos, cómo funcionan estos ataques y qué puede hacer para detenerlos.
Puntos clave: qué es la protección contra el robo de datos para ecommerce
- La protección contra el robo de datos monitorea los scripts ejecutados en el navegador para detectar y bloquear el robo de pagos antes de que los datos de la tarjeta lleguen a los atacantes.
- Los ataques de Magecart y de formjacking inyectan JavaScript malicioso en las páginas de pago, operando por completo del lado del cliente donde las herramientas de seguridad del servidor no pueden verlos.
- Los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 ahora exigen el inventario de scripts, el monitoreo de integridad y la detección de cambios en las páginas de pago.
- cside automatiza el monitoreo de scripts, detecta cambios no autorizados y genera informes listos para auditoría que los QSA aceptan para el cumplimiento de PCI.
- Las herramientas de seguridad tradicionales como los WAF y las CSP no pueden detectar el comportamiento de los scripts en tiempo de ejecución, lo que deja las páginas de pago vulnerables a los ataques a la cadena de suministro.
¿Qué es el robo de datos en el ecommerce?
El robo de datos es un ataque basado en el navegador en el que un JavaScript malicioso captura los datos de la tarjeta de pago a medida que los clientes los introducen en las páginas de pago. El ataque ocurre en el navegador del cliente después de que su servidor entrega una página limpia. Su infraestructura de backend ve una transacción normal mientras el atacante recibe una copia de cada pulsación de tecla.
El nombre "Magecart" se refiere a varios grupos de hackers que fueron pioneros en esta técnica, dirigida originalmente al software de carrito de compras Magento. Hoy, el término describe cualquier ataque de web skimming que inyecta código malicioso en scripts legítimos de terceros o directamente en las páginas de pago.
Los atacantes suelen obtener acceso a través de uno de tres puntos de entrada: la vulneración directa del sitio web mediante fallos del CMS, ataques a la cadena de suministro de proveedores externos, o buckets de almacenamiento en la nube mal configurados que contienen recursos del sitio web. Una vez dentro, implantan código de skimming que se mezcla con los scripts legítimos de procesamiento de pagos.
¿Cómo funcionan los ataques de robo de datos?
Los ataques de robo de datos siguen un proceso de tres etapas: infiltración, implantación y exfiltración. Comprender cada etapa le ayuda a identificar dónde se necesita protección.
Infiltración: cómo obtienen acceso los atacantes
Los atacantes comprometen los sitios web directamente explotando vulnerabilidades en los sistemas de gestión de contenidos o en las plataformas de ecommerce. Esto les da acceso para modificar el código del sitio web sin activar las alertas del lado del servidor.
Los ataques a la cadena de suministro se dirigen a los servicios de terceros en lugar de a su sitio directamente. Cuando usted carga recursos desde un proveedor de analítica comprometido, un proveedor de chatbot o una biblioteca de pagos, el código malicioso se ejecuta junto a la funcionalidad legítima. Una sola brecha en un proveedor externo puede comprometer miles de sitios posteriores.
Implantación: cómo se instala el código de skimming
Una vez que los atacantes tienen acceso, inyectan código de skimming utilizando varias técnicas. La inyección de JavaScript inserta código malicioso que opera junto al procesamiento de pagos legítimo. La clonación de campos de formulario crea duplicados invisibles que capturan los datos a medida que los clientes escriben.
Los ataques avanzados reemplazan formularios de pago enteros con versiones fraudulentas visualmente idénticas. Para evitar la detección, los atacantes ofuscan su código utilizando codificación Base64, fragmentación de código y nombres de dominio de apariencia legítima como "google-analytics.net" en lugar de "google-analytics.com".
Exfiltración: cómo salen del navegador los datos robados
Los datos de pago capturados se transmiten a servidores controlados por los atacantes mediante transmisión directa o exfiltración sigilosa. Algunos skimmers almacenan los datos recopilados en el almacenamiento del navegador y los transmiten en pequeños lotes o cuando el usuario abandona la página. Esto dificulta la detección porque la transferencia de datos no ocurre durante el propio proceso de pago.
¿Qué es la protección contra el robo de datos?
La protección contra el robo de datos se refiere a los controles de seguridad que monitorean, detectan y bloquean el comportamiento no autorizado de los scripts en los navegadores de sus visitantes. A diferencia de la seguridad del lado del servidor, que se detiene en el límite de la red, la protección del lado del cliente observa lo que los scripts realmente hacen a medida que se ejecutan.
Una protección eficaz contra el robo de datos incluye la gestión del inventario de scripts, el monitoreo del comportamiento en tiempo real, la detección de cambios y capacidades de aplicación. cside recopila más de 250 señales del navegador y del dispositivo, monitorea cada carga útil de script de terceros en sesiones reales de visitantes y alerta a su equipo cuando los scripts intentan acceder a los campos del formulario de pago o exfiltrar datos hacia endpoints externos.
Por qué las herramientas de seguridad tradicionales no detectan el robo de datos
Los WAF inspeccionan el tráfico en el límite del servidor. No pueden ver el JavaScript que se ejecuta del lado del cliente, los datos que salen del navegador mediante llamadas de scripts de terceros, ni los ataques dirigidos a segmentos de usuarios específicos según la geografía o el valor del carrito.
Las Políticas de Seguridad de Contenido (CSP) restringen qué dominios pueden cargar scripts, pero no pueden monitorear el comportamiento de los scripts una vez cargados. Si un proveedor de confianza se ve comprometido, el código malicioso se ejecuta desde un dominio aprobado. La CSP no ve nada malo porque la fuente permanece en la lista de permitidos.
Por qué los sitios de ecommerce necesitan protección contra el robo de datos
Las páginas de pago de ecommerce modernas cargan docenas de scripts de terceros para analítica, marketing, chatbots y procesamiento de pagos. Los datos de HTTP Archive muestran que el sitio web promedio utiliza 23 scripts de terceros, y cada uno representa un posible punto de entrada para los atacantes.
British Airways sufrió un ataque de Magecart que comprometió los datos de pago de 380,000 clientes, lo que resultó en una multa de 20 millones de libras conforme al RGPD. Ticketmaster fue vulnerada a través de un servicio de chatbot de terceros comprometido, afectando a más de 800 sitios de ecommerce que usaban el mismo proveedor. Estos ataques pasaron desapercibidos durante semanas o meses mientras los datos de las tarjetas fluían hacia los atacantes.
Requisitos de PCI DSS 4.0.1 para la seguridad de las páginas de pago
Los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 se volvieron obligatorios el 2025-03-31. El requisito 6.4.3 exige que las organizaciones mantengan un inventario completo y autorizado de todos los scripts en las páginas de pago y documenten el propósito y la integridad de cada script.
El requisito 11.6.1 exige mecanismos de detección de cambios y manipulación para alertar al personal sobre la modificación no autorizada de los scripts de las páginas de pago. cside satisface ambos requisitos automáticamente: inventaria cada script en sesiones reales de visitantes, genera justificaciones redactadas por IA para cada script, monitorea los encabezados en tiempo real y produce informes listos para auditoría aceptados por los QSA. VikingCloud ha validado cside para estos requisitos.
Cómo desplegar la protección contra el robo de datos
Desplegar la protección contra el robo de datos comienza con obtener visibilidad de qué scripts se ejecutan actualmente en sus páginas de pago. No puede proteger lo que no puede ver.
Paso 1: cree un inventario de scripts
Documente cada script de terceros que se ejecuta en sus páginas de pago. Para cada script, registre su propósito, los datos a los que puede acceder y las prácticas de seguridad del proveedor. Este inventario constituye la línea base para detectar cambios no autorizados.
Paso 2: despliegue el monitoreo del lado del cliente
Agregue un script de monitoreo ligero a sus páginas. cside se despliega mediante un único fragmento de JavaScript agregado al encabezado de su página. Ningún tráfico se enruta a través de la infraestructura de cside, no hay proxy inverso, ni dependencia de CDN, ni cambios de configuración de DNS requeridos. El fragmento se ejecuta directamente en los navegadores de sus visitantes.
Paso 3: configure alertas y aplicación
Configure alertas para los cambios no autorizados en los scripts, las adiciones de nuevos scripts y la transmisión de datos sospechosa desde las páginas de pago. Los ataques de Magecart modifican scripts de confianza existentes o inyectan nuevos. Las alertas en tiempo real garantizan que su equipo conozca los cambios en cuestión de segundos, no después de un informe de brecha.
Limitaciones de los enfoques de protección comunes
Comprender lo que cada método de protección no puede hacer le ayuda a construir una defensa por capas.
Limitaciones de la protección basada solo en CSP
La CSP controla qué scripts pueden cargarse, pero no lo que hacen después de cargarse. Un script de proveedor comprometido se ejecuta desde un dominio aprobado. La CSP también tiene dificultades con los scripts dinámicos y el código en línea generado en tiempo de ejecución.
Limitaciones de las soluciones basadas en escáneres
Los escáneres revisan su sitio periódicamente, a menudo a diario o semanalmente. Los ataques dirigidos a sesiones de usuario específicas (pedidos de alto valor, ciertas geografías) evaden la detección porque el escáner ve una página limpia. Los escáneres tampoco pueden bloquear ataques en curso, ya que detectan las amenazas después de los hechos.
Limitaciones del registro del lado del servidor
Los registros del servidor documentan las solicitudes entrantes y las respuestas salientes. El robo de datos ocurre por completo del lado del cliente. Los datos robados de la tarjeta van directamente desde el navegador del cliente hasta el servidor del atacante sin tocar su infraestructura. Sus registros muestran una transacción de pago normal mientras ocurre la brecha.
En conclusión: cómo la protección contra el robo de datos asegura los pagos de ecommerce
La protección contra el robo de datos monitorea los scripts ejecutados en el navegador para detectar y bloquear el robo de pagos. Estos ataques explotan la brecha entre la seguridad del lado del servidor y la ejecución de código del lado del cliente, operando en el único lugar que sus herramientas existentes no pueden ver.
cside ofrece a su equipo visibilidad completa del comportamiento de los scripts de terceros en las páginas de pago. Agregue un script ligero a su sitio web para comenzar a monitorear scripts, detectar ataques de Magecart y generar evidencia de cumplimiento de PCI DSS 4.0.1 de inmediato. Para comenzar con cside, reserve una demostración.
