La principal amenaza actual para la información de tarjetas de crédito no es un skimmer físico; son los ataques a la cadena de suministro en sitios web. Los atacantes insertan JavaScript malicioso en las páginas de pago. Una vez inyectado, este script captura los datos de la tarjeta en tiempo real conforme se introducen, a menudo sin ser detectado.
El término Magecart se usa habitualmente como sinónimo de este tipo de ataques. Su origen está en ataques que ocurrían en la plataforma Magento, muy popular en el comercio electrónico. El nombre combina "Magento" y "Cart" (carrito), haciendo referencia a los carritos de compra donde suelen producirse estos ataques.
Tanto Magento como WordPress son objetivos frecuentes de ataques en el lado del cliente. Estos ataques suelen apuntar a versiones antiguas de las plataformas que no han sido actualizadas correctamente. Conoce más sobre los mayores ataques Magecart de la historia hasta la fecha.
El Informe Biannual de Amenazas de Primavera 2025 de Visa identifica el skimming digital como una de las "amenazas más prolíficas y constantes" del ecosistema de pagos. El informe señala que el sistema de Perturbación de Amenazas en eCommerce de Visa (eTD) analiza de forma proactiva los sitios de comerciantes en busca de firmas de skimmers en América del Norte y Europa.
La guía de Mastercard Digital Skimming: How to Stay Protected explica cómo su plataforma RiskRecon localiza estos scripts maliciosos, rastrea sus fechas de inyección y duración, e identifica las vulnerabilidades relacionadas.
Cómo funciona el skimming en la cadena de suministro
El atacante necesita acceso a un archivo JavaScript en la página objetivo. La forma de conseguirlo puede variar. El método más habitual es acceder a un script que ya está presente en el sitio web. Suelen ser plugins antiguos que no se actualizaron ni mantuvieron, o un script de terceros o herramienta de marketing que fue comprometida. A continuación, modifican el script para ejecutar su ataque.
Existen variantes de esto, como se vio en el ataque a Baways (British Airways). En ese caso, el atacante logró vulnerar el backend e instalar un script directamente en el sitio web de BA.
En cualquier caso, el script que se ejecuta en el lado del cliente (es decir, en el navegador) puede llevar a cabo todo tipo de funciones. En las operaciones de skimming, lo más habitual es:
- Copiar directamente los campos del formulario al enviarlo o mediante keylogging
- Redirigir la página de pago a un portal de pago falso
- Superponer un
<iframe>malicioso sobre la página de pago original - …
Cualquiera que tenga acceso a JavaScript en una página puede hacer prácticamente lo que quiera. Estos scripts son muy adaptables, dinámicos según distintos criterios, y constituyen la forma perfecta y silenciosa de robar datos de tarjetas de crédito e información personal (PII).
Resumen de soluciones
Basadas en proxy
El skimming en el lado del cliente es difícil de detectar precisamente porque ocurre fuera de tu infraestructura. Los scripts que se ejecutan en el navegador de tu cliente son dinámicos, y los atacantes suelen comprometer herramientas que ya tienen acceso legítimo.
Por eso es fundamental ver el payload real tal como se entrega a los usuarios reales. Sin esta visibilidad, nunca puedes estar completamente seguro de qué se ejecutó ni dónde comenzó el compromiso.
Construimos nuestra solución en torno a un modelo de proxy híbrido, porque es el único enfoque que ofrece cobertura completa y en tiempo real en los frontends modernos. Cada script que llega a tus usuarios pasa por el proxy. Nuestra solución de seguridad de cadena de suministro permite visibilidad total del payload realmente entregado, así como historial completo y análisis de los scripts.
Monitorización basada en JavaScript (Agentes)
Algunos proveedores ofrecen detección mediante etiquetas JavaScript que se insertan en la página. Esto significa que el atacante también las ve. Piénsalo como una trampa para ratones: se puede ver y se puede evitar. Si alguien está inyectando scripts en tu checkout, también puede modificar o deshabilitar el script de protección o monitorización.
Las herramientas de solo detección también tienden a generar alertas después de que los datos ya han sido exfiltrados. Creemos que la prevención es mejor.
Crawlers
Las herramientas basadas en crawlers funcionan simulando visitas a tu sitio web y capturando los scripts y recursos que se cargan durante esa visita. Lo fundamental es que no obtienen necesariamente el mismo payload de script que un usuario real. "Imitan" a un usuario.
Los scripts son dinámicos por naturaleza y los atacantes aprovechan esto a su favor. En teoría y en la práctica, estos crawlers son detectables y, por tanto, evitables.
Los crawlers son útiles para análisis superficiales. Pero los skimmers no operan en la superficie.
Política de Seguridad de Contenido (CSP)
La Política de Seguridad de Contenido (CSP) es una función del navegador que permite a los propietarios de sitios definir qué fuentes de contenido (como scripts) pueden cargarse en una página. Cuando está correctamente configurada, la CSP puede ayudar a bloquear código de terceros no autorizado o inesperado, restringiendo los orígenes de los scripts.
Es un control preventivo valioso, especialmente para reducir la exposición a inyecciones de scripts en línea o cargas desde dominios desconocidos. Recomendamos usar CSP solo como una capa adicional, porque la CSP no puede ver el payload del script.
En nuestras charlas y presentaciones, solemos usar la siguiente diapositiva para ilustrar la CSP:
Tienes 2 cajas. Una contiene un cachorro, la otra una bomba. ¿Cuál es cuál…? Eso es la CSP.
En nuestra página de comparación, profundizamos en los 4 enfoques aquí descritos con todo detalle.
Un breve resumen de las soluciones
Los scripts que se cargan en el navegador de tu cliente pueden acceder a campos de entrada, modificar contenido, enviar datos a otros destinos y mucho más. Son dinámicos, a menudo provienen de terceros y pueden ser alterados sin que lo sepas.
Por eso el skimming en el lado del cliente es tan efectivo. Y por eso prevenirlo requiere algo más que un análisis superficial.
¿Por qué es tan importante la ruta de entrega?
Porque es la única forma de ver qué llega realmente al usuario. Los scripts son dinámicos. Los atacantes pueden modificarlos en cualquier momento, a menudo de forma condicional. Si no estás en la ruta de entrega, dependes de instantáneas o suposiciones. Estar en el camino significa ver cada solicitud, en cada sesión, en tiempo real, y poder actuar antes de que se ejecute algo peligroso.
¿Cuál es la mejor forma de prevenir estos ataques?
El método más eficaz hoy en día es nuestra monitorización de scripts basada en proxy. Inspecciona cada script antes de que llegue al navegador, verifica su integridad y bloquea el código malicioso en tiempo real. Funciona en cada sesión de usuario y proporciona visibilidad completa, registro y cobertura de cumplimiento normativo.
¿Es la monitorización basada en JavaScript (Agentes) una buena opción?
Puede ayudar a detectar algunas amenazas, pero se ejecuta dentro del mismo entorno que los atacantes tienen como objetivo. Si un atacante puede inyectar un skimmer, probablemente también pueda deshabilitar o eludir el script de monitorización. Es útil, pero no suficiente por sí solo.
¿Es un crawler una buena opción?
Los crawlers simulan visitas a tu sitio y registran los scripts visibles. Son útiles para análisis periódicos, pero no operan dentro de sesiones reales. Si un skimmer solo está activo bajo ciertas condiciones (como un usuario autenticado o un rango de IP específico), los crawlers no lo verán.
¿Es la CSP una buena opción?
La CSP (Política de Seguridad de Contenido) puede reducir el riesgo limitando desde dónde se permite cargar scripts. Pero no analiza lo que hace un script una vez que se carga. Es una capa útil, pero no constituye un sistema sólido de detección ni de prevención.
