Resumen
- El skimming de tarjetas en línea es JavaScript malicioso en la página de pago de un comerciante que copia los datos de la tarjeta de pago mientras el cliente los escribe.
- Los atacantes colocan el script comprometiendo un complemento de terceros, una biblioteca de análisis o un gestor de etiquetas que el sitio ya carga.
- Los datos robados salen del navegador directamente a un servidor controlado por el atacante. El backend, el WAF y el procesador de pagos nunca lo ven.
- El Informe Semestral de Amenazas de Visa de Primavera 2025 identifica el skimming digital como "una de las amenazas más prolíficas y consistentes" del ecosistema de pagos.
- Los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1, obligatorios desde el 31 de marzo de 2025, existen específicamente para contrarrestar este tipo de ataque.
¿Qué es el skimming de tarjetas en línea?
- Skimming de tarjetas en línea
- El skimming de tarjetas en línea es un ciberataque en el que JavaScript malicioso se ejecuta en el navegador de un comprador en la página de pago de un comerciante. Mientras el usuario escribe su número de tarjeta, fecha de caducidad, CVV y dirección de facturación en el formulario de pago, el script copia esos datos y los transmite a un servidor controlado por el atacante, antes de que se envíe el pago.
El término "skimming de tarjetas" se origina del fraude físico: un dispositivo de hardware conectado a un cajero automático o terminal de punto de venta que lee la banda magnética de la tarjeta y registra el PIN cuando el cliente lo introduce. El skimming de tarjetas en línea funciona con el mismo principio pero no necesita ningún dispositivo físico. Unas pocas líneas de JavaScript reemplazan al hardware. El ataque no deja rastro físico, puede ejecutarse sin ser detectado durante meses y puede desplegarse en miles de sitios web simultáneamente a través de un único script de terceros comprometido.
El Informe Semestral de Amenazas de Visa de Primavera 2025 identificó el skimming digital como una de "las amenazas más prolíficas y consistentes" del ecosistema de pagos, señalando que el programa de Disrupción de Amenazas de eCommerce de la compañía escanea activamente sitios de comerciantes en busca de firmas de skimmers en América del Norte y Europa.
Para una perspectiva complementaria sobre el lado de la ejecución en el navegador de este ataque, consulte nuestra guía detallada sobre e-skimming.
Cómo los atacantes despliegan scripts de skimming de tarjetas
Los atacantes necesitan ejecutar código en la página de pago objetivo. Lo logran a través de puntos de entrada en la cadena de suministro en lugar de atacar directamente el servidor del comerciante:
- Un complemento de terceros, extensión de CMS o widget comprometido que el sitio del comerciante ya carga
- Una actualización maliciosa enviada a una biblioteca de análisis o gestor de etiquetas alojada en CDN
- Una vulneración del panel de administración del CMS o repositorio de código del comerciante
Una vez que controlan un archivo JavaScript que se ejecuta en la página de pago, añaden el payload de skimming. El script se engancha a los campos del formulario de pago. Mientras el cliente escribe, el script copia cada valor, codifica los datos y los envía por HTTPS a un dominio controlado por el atacante, típicamente un dominio parecido con typosquatting diseñado para mezclarse en los registros de tráfico de red. La solicitud de exfiltración nunca pasa por el servidor del comerciante.
Tres propiedades hacen esto casi invisible desde fuera del navegador: la solicitud saliente está cifrada; el dominio de destino imita a un proveedor legítimo; y el payload es lo suficientemente pequeño como para parecerse al tráfico de análisis rutinario.
Por qué los escáneres de código en reposo no lo detectan
La mayoría de las herramientas de seguridad para sitios web obtienen una página, analizan el código fuente HTML y JavaScript, y marcan firmas maliciosas conocidas. El skimming de tarjetas en línea evade este enfoque por una razón estructural: el skimmer se ejecuta en el navegador de un usuario real, donde el atacante puede aplicar lógica condicional que un escáner nunca activa.
Un script puede devolver código limpio a los rastreadores sin cabeza y activarse solo cuando detecta comportamiento humano, una dirección IP real o una región geográfica específica. El WAF, el servidor de origen y el procesador de pagos del comerciante nunca reciben ninguna evidencia del robo. Solo una capa de monitoreo que se ejecuta dentro de sesiones de visitantes reales puede observar el script tal como se comporta realmente.
Ataques de skimming de tarjetas en línea conocidos
British Airways (2018). Los atacantes plantaron 22 líneas de JavaScript en ba.com que exfiltraban datos de pago a un dominio parecido, baways[.]com. El script funcionó sin ser detectado durante aproximadamente dos meses y afectó a alrededor de 500.000 clientes y empleados. La Oficina del Comisionado de Información del Reino Unido emitió una multa inicial de £183 millones bajo el RGPD, posteriormente reducida a £20 millones. El caso fue una de las primeras acciones de aplicación del RGPD de alto perfil directamente vinculadas a un fallo de seguridad de pago del lado del cliente.
Magecart (en curso). El nombre se originó de ataques dirigidos a carros de compra basados en Magento, pero ahora cubre docenas de grupos de actores de amenaza distintos que utilizan skimming de tarjetas en línea en muchas plataformas. Los actores de Magecart han comprometido proveedores de scripts de terceros cuyas bibliotecas se ejecutan simultáneamente en miles de sitios de comerciantes, convirtiendo una única brecha en la cadena de suministro en un evento masivo de robo de tarjetas. Consulte los mayores ataques de Magecart registrados.
Requisitos de PCI DSS 4.0.1 para la prevención del skimming de tarjetas
PCI DSS 4.0.1 introdujo dos requisitos que abordan directamente el skimming de tarjetas en línea. Ambos se volvieron obligatorios el 31 de marzo de 2025:
Requisito 6.4.3 exige que cada script cargado en una página de pago esté documentado en un inventario, autorizado con una justificación empresarial y tenga su integridad protegida. La intención es evitar que scripts no autorizados se ejecuten donde se ingresan datos de tarjeta.
Requisito 11.6.1 exige un mecanismo de detección de manipulación que alerte sobre cambios no autorizados en scripts de páginas de pago y encabezados HTTP que afecten a la seguridad, evaluado al menos semanalmente o según un calendario analizado por riesgos.
Las auditorías manuales de scripts y los análisis en un momento específico no pueden satisfacer estos requisitos al volumen y frecuencia que especifican. El monitoreo automatizado y continuo de lo que los scripts realmente hacen en navegadores reales es la línea base que ambos requisitos están escritos para aplicar.
| Requisito | Qué exige | Obligatorio desde |
|---|---|---|
| 6.4.3 | Inventario de scripts, autorización e integridad en páginas de pago | 31 de marzo de 2025 |
| 11.6.1 | Detección de manipulación con alertas para cambios en páginas de pago | 31 de marzo de 2025 |
Cómo detectar el skimming de tarjetas en línea
La detección requiere visibilidad de lo que los scripts hacen dentro de los navegadores de visitantes reales, no solo del aspecto de su código fuente en el momento del análisis. cside despliega un único fragmento de JavaScript de primera parte (sin proxy, sin cambios de DNS) que monitorea el comportamiento de scripts a nivel del navegador en cada carga de página real.
Las señales que cside detecta para el skimming de tarjetas en línea:
- Scripts nuevos o modificados que aparecen en páginas de pago sin autorización
- Oyentes inesperados en campos de entrada que manejan datos de tarjeta
- Solicitudes salientes a dominios fuera de una lista de permitidos autorizada
- Comportamiento de scripts que difiere entre sesiones automatizadas y sesiones de usuarios reales
Esto produce el registro continuo en tiempo real que PCI DSS 4.0.1 requiere: un inventario de scripts autorizado para el 6.4.3 y evidencia de detección de manipulación para el 11.6.1.
Lecturas relacionadas:
