Resumen: qué es el e-skimming
- Qué es el e-skimming: El e-skimming es un ciberataque en el que se inyecta código en el sitio web de un comerciante. A los usuarios que visitan una página de pago, código malicioso que observa y "skimea" los datos de la tarjeta introducidos les roba la información.
- Robado antes del cifrado: El e-skimming captura los datos antes o durante el envío del pago. La información se roba antes de que llegue al perímetro del cifrado o de la seguridad del servidor.
- Cómo ayuda cside: Para prevenir el e-skimming, utiliza una herramienta como cside que monitoriza el comportamiento de los scripts de terceros y te alerta ante actividad sospechosa.
- Controles manuales del navegador: Como alternativa, usa controles del navegador como CSP y SRI para limitar manualmente qué scripts de terceros pueden acceder a las páginas de pago.
- El ángulo de cumplimiento: Los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 (obligatorios desde el 31 de marzo de 2025) exigen a los comerciantes inventariar todos los scripts de las páginas de pago y monitorizar cambios no autorizados: presión regulatoria directa para abordar el e-skimming.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
¿Qué es el e-skimming?
- E-skimming
- El e-skimming (también llamado "web skimming") es un ciberataque en el que un actor malicioso inyecta un fragmento de código en el sitio web de un comerciante. Cuando un usuario visita la página de pago, el código malicioso monitoriza los campos del formulario para capturar los datos de la tarjeta, que después se envían a un servidor controlado por el atacante para su uso fraudulento.
El e-skimming es un ataque del lado del cliente en el que JavaScript malicioso inyectado en la página de pago de un comerciante captura números de tarjeta, fechas de caducidad, CVCs y direcciones de facturación mientras los usuarios los escriben, antes de que los datos lleguen a ningún cifrado del lado del servidor. Los datos robados se envían en tiempo real a un servidor controlado por el atacante y se venden en mercados de la dark web o se usan directamente para cometer fraude con tarjetas. El e-skimming es el equivalente digital de un skimmer físico colocado en un cajero automático, salvo que es invisible, solo software, y puede operar sin ser detectado durante meses.
Para comparar, el skimming físico de tarjetas ocurre cuando se coloca un dispositivo en un cajero automático o en un teclado de pago. Un cliente desprevenido usa su tarjeta para realizar una compra, y el dispositivo captura la información de la tarjeta de crédito y el PIN introducidos. El dispositivo está diseñado para pasar desapercibido ante el personal de la empresa.
De manera similar, las inyecciones de código de e-skimming están diseñadas para ser invisibles. A menudo permanecen en las páginas de pago durante semanas (y en algunos casos meses) antes de que los propietarios del sitio web se den cuenta.
Qué datos se atacan en los ataques de e-skimming
| Tipo de dato | Precio medio en la dark web |
|---|---|
| Tarjeta de crédito de EE. UU. | $10 a $100 |
| Cuenta de Gmail | $60 |
| Credenciales de acceso bancario | $200 a $1,000 |
| Credenciales de acceso corporativo | $100 a $10,000 |
Aunque el e-skimming se refiere más habitualmente al robo de información de tarjetas de crédito, el web skimming también puede referirse en sentido amplio a ataques que tienen como objetivo esta información:
- Credenciales de inicio de sesión (nombre de usuario, correo electrónico, contraseña)
- Información personal (dirección, nombre legal, números de teléfono)
¿Es el e-skimming un ataque del lado del cliente?
Sí. El web skimming, el e-skimming o el digital skimming (distintos nombres para el mismo vector de amenaza) son una forma de ataque del lado del cliente.
Suelen ser ataques bien preparados y sofisticados, especialidad de ciertas comunidades de hackers que llevan a cabo ataques Magecart.
Existen otros ataques del lado del cliente, como el phishing con superposiciones de interfaz de usuario o páginas de pago falsas.
Durante el web skimming, los atacantes canalizan los datos robados hacia su propio servidor, normalmente a través de un dominio que se asemeja mucho al del comerciante legítimo. Este tipo de ataque se utilizó contra Ticketmaster y British Airways, entre otros.
¿Qué sitios web son vulnerables al e-skimming?
Cualquier sitio web que trabaje con scripts de terceros, especialmente cuando se ejecutan en páginas de inicio de sesión o de pago, es vulnerable. Los sitios construidos sobre Magento, WooCommerce u otras plataformas low-code son especialmente vulnerables.
Aunque las propias plataformas son seguras y sus equipos de seguridad trabajan activamente para parchear las vulnerabilidades conocidas, esas plataformas son utilizadas con frecuencia por usuarios no técnicos que tienen menos probabilidades de darse cuenta de que se está produciendo un ataque.
Previene el e-skimming con la seguridad automatizada del lado del cliente de cside
Cómo funciona el e-skimming y dónde falla la seguridad
Para entender cómo operan los e-skimmers, hay que analizar cómo funcionan los pagos en línea.
Cuando los compradores han llenado su carrito y están listos para hacer el pedido, llegan a la página de pago. Allí rellenan los campos del formulario. Una vez enviado el pago, los datos se cifran y se envían al comerciante y al emisor de la tarjeta. Si la transacción se aprueba, comienza el proceso de cumplimiento del pedido.
En cuanto se envía el pago, la información queda protegida por cifrado, controles del servidor, seguridad de API y otras capas de defensa. Lamentablemente, el e-skimming captura la información antes o durante el envío del pago. El código malicioso escucha las pulsaciones de teclas mientras el usuario introduce la información. Esta técnica concreta —enganchar los campos del formulario para capturar los datos mientras se escriben— se conoce como formjacking.
Cómo inyectan los hackers el código de e-skimming
Cuando un usuario visita una página de tu sitio web, su navegador carga una combinación de código. Parte es código propio que tu equipo creó (o escrito por la plataforma que utilizas, como Shopify o WooCommerce). Pero tu sitio web también sirve código de terceros.
En los sitios de comercio electrónico, esto incluye plugins y scripts de terceros:
- Herramientas de analítica (como Amplitude)
- Herramientas promocionales (como capturas de correo electrónico para newsletters)
- Constructores de paquetes
- Seguimiento de anuncios (Meta, Google)
Y muchas otras herramientas de terceros que son esenciales para los sitios de comercio electrónico.
Los scripts de terceros son un punto de entrada para el web skimming
Cada script de terceros es un punto de entrada para los atacantes. Pueden infiltrarse a través de diversos métodos:
- Dominios caducados: cuando un dominio antiguo no se renueva, los atacantes pueden comprarlo y modificar el código. Si tu sitio web obtiene código de ese dominio, el código malicioso quedará incorporado.
- Ataques a la cadena de suministro: si un tercero de confianza es hackeado, su script puede propagar código malicioso a tu sitio.
- A través de gestores de etiquetas: si los atacantes obtienen acceso a Google Tag Manager, pueden inyectar código que irá directamente a tu sitio web en producción sin ninguna revisión. La actividad de ese script quedará oculta al estar agrupada con otros scripts.
- Credenciales expuestas: las credenciales robadas pueden otorgar a los atacantes acceso interno a tus sistemas. En lugar de intentar forzar la entrada a la caja fuerte (tus servidores), pueden optar por inyectar código en tu sitio web.
De forma individual, las herramientas de terceros establecidas son seguras y conllevan un riesgo mínimo. Pero los sitios web modernos tienen decenas de scripts de terceros. Un informe de Web Almanac encontró que la mediana de dominios de terceros en un sitio web es de 23. Y esos scripts de terceros cargan a su vez más scripts (scripts de cuarta parte) para ayudarles con el procesamiento de datos.
Un chatbot (script de terceros) podría cargar una herramienta de análisis de documentos para ayudar a los clientes con sus tickets de soporte analizando sus PDFs. Nunca autorizaste directamente esa herramienta de análisis de documentos, pero se sirve en tu sitio (y accede a información sensible).
Puede que empieces a ver el problema: tu sitio web termina con decenas de scripts que pueden inyectar código sin que nadie los supervise.
Qué hacen los atacantes con los datos obtenidos por e-skimming
¿Cuál es el peligro real? En el escenario óptimo para el atacante: crean un script que les permite ver lo que los usuarios introducen en el formulario de pago. Ya está. Ahora ven información de identificación personal, además del número de tarjeta, la fecha de caducidad y el código CVC.
Si logran copiar y exfiltrar eso a su propio servidor, el botín está asegurado. Pueden vender esa información en la dark web o usar los datos de la tarjeta ellos mismos para cometer fraude.
Cómo pueden prevenir el e-skimming los comerciantes en línea
1. Monitoriza los scripts de terceros: ¿a qué datos acceden y adónde los envían?
La monitorización de scripts en tiempo real es esencial. Las herramientas que observan los scripts de terceros y su comportamiento hacen saltar una alarma cuando se detecta actividad sospechosa. Por ejemplo, si un script de analítica de repente comienza a leer datos de formularios y a enviarlos a un servidor en Rusia, es posible que estés ante un ataque del lado del cliente.
La plataforma de cside monitoriza los scripts de terceros para ver a qué datos tienen acceso y te alerta de inmediato si ese acceso cambia.
2. Limita qué scripts se ejecutan en las páginas de pago
Para los comerciantes, el primer paso es saber qué scripts se ejecutan en las páginas de pago. Como medida de precaución, asegúrate de que solo se ejecuten allí los scripts necesarios. Todo lo que no sea estrictamente necesario para el pago o la prevención del fraude: elimínalo.
3. Usa cside para la gobernanza de scripts de terceros
Muchos sitios web permiten por defecto que los scripts de terceros pasen directamente al sitio en producción. Los equipos de marketing y los desarrolladores quieren actualizaciones rápidas para mejorar la funcionalidad. Incluso las empresas que sí revisan cada script los aprueban una vez y rara vez vuelven a revisarlos.
Puede parecer un trabajo manual enorme revisar cada script que se añade, pero una herramienta como cside rastrea automáticamente cada nuevo script añadido y ofrece un resumen escrito por IA y una puntuación de riesgo para que puedas aprobarlo rápidamente. Todos los scripts se mantienen en un "inventario en vivo" que los equipos de cumplimiento de privacidad o de seguridad pueden gestionar fácilmente.
4. Implementa controles de seguridad del navegador: CSP y SRI
Los ataques de e-skimming ocurren en el navegador, por lo que podemos usar allí una capa de defensa. CSP y SRI proporcionan justamente eso. Es cierto que no lo resuelven todo, pero sí generan más visibilidad.
Un CSP estricto determina qué fuentes pueden cargar scripts y a qué endpoints pueden acceder. El contenido del script en sí no se verifica, pero los flujos de datos no deseados se detectan y pueden bloquearse. Empieza con Content-Security-Policy-Report-Only para comprobar que todo sigue funcionando correctamente.
SRI añade un hash a los archivos: así es como compruebas si un script fue modificado en el origen o durante la transferencia. Esto dificulta mucho más la propagación de código malicioso mediante una actualización o un proveedor comprometido. Esto funciona sobre todo con scripts estáticos. Pero los scripts de terceros que se actualizan automáticamente rompen la verificación del hash.
Por qué la seguridad web tradicional no detecta el e-skimming
El malware no se ejecuta en el servidor del comerciante. Se ejecuta en el navegador del cliente con los mismos derechos y privilegios que el propio código del comerciante.
JavaScript se acepta y ejecuta en el DOM. Las herramientas de seguridad web tradicionales a menudo no tienen visibilidad sobre esto. Incluso las herramientas de defensa del lado del cliente como Content Security Policy solo analizan el origen de cada script. Si una fuente de confianza está sirviendo código malicioso, las políticas de seguridad de contenido no detectarán ni bloquearán ese ataque.
Qué exige PCI DSS 4.0.1 para prevenir el e-skimming
PCI DSS 4.0.1 introdujo dos requisitos que abordan directamente el e-skimming, ambos obligatorios desde el 31 de marzo de 2025:
Requisito 6.4.3: inventario y autorización de scripts en las páginas de pago. Cada script cargado en una página de pago debe estar documentado en un inventario, autorizado con una justificación de negocio, y su integridad debe estar protegida. Los comerciantes deben poder confirmar que no se ejecuta ningún script no autorizado en el proceso de pago. Las revisiones manuales fallan en la práctica: los scripts suelen ser añadidos por equipos de marketing a través de gestores de etiquetas y nunca son revisados por seguridad.
Requisito 11.6.1: mecanismo de detección de manipulaciones en las páginas de pago. Los comerciantes deben implementar un mecanismo que detecte cambios no autorizados en los encabezados HTTP y en el contenido de las páginas de pago. El mecanismo debe alertar sobre los cambios y debe evaluar la página al menos una vez cada siete días (o según lo defina un análisis de riesgo dirigido). Un script de terceros comprometido que modifica el comportamiento del formulario cumple la definición de "cambio no autorizado".
En conjunto, estos requisitos significan que las revisiones manuales de scripts y las auditorías periódicas ya no son suficientes. La monitorización automatizada y continua del lado del cliente (el tipo que ofrece cside) es lo que PCI DSS 4.0.1 fue redactado para exigir.
¿Cómo es en la práctica el cumplimiento de 6.4.3 y 11.6.1?
El cumplimiento requiere tres elementos funcionando de forma continua en cada página de pago:
- Un inventario de scripts en vivo que registre cada script de primera y de tercera parte, su dominio de origen y su justificación de negocio.
- Verificación de integridad que confirme que cada script no ha sido modificado desde que fue autorizado.
- Detección de manipulaciones que alerte dentro del período de evaluación requerido cada vez que se detecte un cambio no autorizado en el contenido de la página o en los encabezados.
Las hojas de cálculo manuales y las revisiones mensuales no pueden cumplir estos requisitos a escala. Las herramientas automatizadas que monitorizan la ejecución real del navegador (observando lo que los scripts realmente hacen, no solo lo que dice su código fuente) son el camino práctico hacia el cumplimiento.
| Requisito PCI DSS 4.0.1 | Qué exige | Fecha efectiva |
|---|---|---|
| 6.4.3 | Inventario, autorización e integridad de los scripts en las páginas de pago | 31 de marzo de 2025 |
| 11.6.1 | Mecanismo de detección de manipulaciones con alertas ante cambios en las páginas de pago | 31 de marzo de 2025 |
Lecturas relacionadas:
