El skimmer digital MirrorMask revela PCI DSS y los riesgos para el cliente
Pedro Fortuna, CTO y cofundador de Jscrambler
Para aquellos que no están familiarizados con el SAQ A, es el Cuestionario de autoevaluación A el que se puede utilizar para verificar el cumplimiento del comerciante con el Estándar de seguridad de datos de la industria de tarjetas de pago (PCI DSS) y está destinado a comerciantes que subcontratan completamente todo el procesamiento de datos de tarjetas de pago a un Proveedor de servicios de pago (PSP) verificado por PCI DSS. Para las empresas elegibles para SAQ A, proporciona un camino más rápido y sencillo hacia el cumplimiento de PCI DSS y al mismo tiempo les permite demostrar su compromiso con la seguridad. Considerándolo todo, esto puede parecer un camino ideal hacia el cumplimiento, pero no lo es.
Un ejemplo reciente involucra a Stripe, y más específicamente, a los comerciantes de Stripe que fueron atacados por un skimmer digital llamado MirrorMask. Los actores de amenazas inyectaron código malicioso que se apoderó del iframe de Stripe, lo que les permitió interceptar datos de formularios de pago y falsificar encabezados de seguridad antes de que llegaran al procesamiento seguro de Stripe.
A pesar de estas acciones, la página todavía se muestra normalmente y todas las transacciones de los clientes se procesan como se esperaba. Los comerciantes no saben que los datos de los titulares de tarjetas pueden ser robados silenciosamente cuando los clientes realizan el pago. MirrorMask fue informado por primera vez por Turaco Labs y posteriormente Nuestro propio equipo Jscrambler Confirmado Eso Al 2 de abril de 2025, 49 comerciantes fueron afectados.
Me gustaría señalar aquí que Stripe es sólo un ejemplo. Este método de ataque también es posible contra el iframe de pago de cualquier otro proveedor de servicios. De cualquier manera, la lección es la misma: incluso si la PSP cumple totalmente con PCI DSS, SAQ A por sí solo no puede garantizar la protección.
Puntos ciegos en SAQ A
Cuando se introdujo por primera vez el SAQ A en 2008, simplificó el cumplimiento para los comerciantes cuyas funciones de datos de titulares de tarjetas estaban completamente subcontratadas a un tercero verificado, y el comerciante conservaba únicamente informes o recibos en papel que contenían datos de titulares de tarjetas. Pero muchas cosas han cambiado desde entonces. Los sitios web modernos ahora dependen de docenas de scripts de terceros para impulsar todo, desde análisis y chatbots hasta administradores de etiquetas y píxeles de marketing. En cada caso, se ejecutan del lado del cliente.
Hoy, nos enteramos por los comerciantes de Stripe afectados que los atacantes están comprometiendo scripts y dependencias de terceros cargados en las páginas de pago de los comerciantes y, al inyectar código malicioso en estos componentes, pueden interceptar y robar datos confidenciales directamente desde los campos de pago antes de que lleguen al proveedor de servicios de pago (PSP).
A continuación se ofrece una mirada más profunda a cómo funciona este ataque en el caso de MirrorMask.
Una inmersión profunda en el ataque MirrorMask
En el comercio electrónico, el SAQ A supone que los comerciantes han subcontratado el riesgo a las pasarelas de pago y que las pasarelas de pago pueden proteger a los comerciantes de ataques de hurto.
El ataque de la “máscara del espejo” socava esta suposición.
El atacante comprometió el sitio web del comerciante para que el script de pago se cargara desde el servidor del atacante en lugar del servidor de Stripe. Cuando el cliente de un comerciante ingresa datos de la tarjeta de pago, esos datos se envían primero al servidor del atacante. El atacante obtuvo una copia del pago antes de reenviarlo a Stripe, y Stripe no pudo detectar que el actor de la amenaza había interceptado la transacción.
La creciente brecha entre cumplimiento y seguridad
PCI DSS reconoce el riesgo de robo, pero el SAQ A no aborda completamente este riesgo. Algunos requisitos exigen que las empresas supervisen la integridad de la página web y el comportamiento de los scripts (específicamente, los requisitos 6.4.3 y 11.6.1), pero se eliminaron del SAQ A antes de que se volvieran obligatorios. Si hubieran estado en el lugar, el ataque podría haberse detectado y detenido.
Tome el control de la seguridad del cliente
Entonces la pregunta es: ¿adónde irán los comerciantes? MirrorMask y ataques similares proporcionan la respuesta. Dicho esto, la responsabilidad de la seguridad del pago no se limita al proveedor de servicios de pago. Los comerciantes deben asumir una responsabilidad activa asegurándose de que sus integraciones sean a prueba de manipulaciones y estén debidamente verificadas. Empiece por hacer las preguntas correctas:
- ¿Puede un iframe de pago integrado detectar la inyección de código no autorizado desde la página principal?
- ¿Cómo verificar su integridad en tiempo real?
- ¿Quién es responsable si se filtra el código del lado del cliente en la página de un comerciante?
Si bien la respuesta variará de un comerciante a otro, cada organización debe mantener fuertes controles técnicos para protegerse contra amenazas del lado del cliente como Magecart y e-skimming. Esto incluye monitoreo de scripts en todo el sitio, verificación de integridad y mecanismos de detección de manipulaciones.
La verificación y el seguimiento continuos son clave. Al verificar proactivamente la integridad de las páginas de pago y trabajar con expertos en cumplimiento, los comerciantes pueden fortalecer sus defensas, garantizar el cumplimiento continuo de PCI DSS v4.0 y mantener la elegibilidad según SAQ A.
El camino por delante
SAQ A ayuda a los comerciantes a simplificar el cumplimiento de PCI DSS. Pero las cosas han cambiado. Simplemente cumplir con las regulaciones o tomar un camino de baja resistencia hacia el cumplimiento no es una línea de defensa suficiente contra los ataques modernos. La seguridad debe ir más allá del papeleo e incluir la verificación en tiempo real por parte del comerciante, comprobando lo que el negocio decide permitir ejecutar en el navegador.
Para los comerciantes, esto significa combinar listas de verificación de cumplimiento con visibilidad y control continuos. Para PSP, esto significa diseñar campos flotantes/alojados de pago para detectar manipulaciones por parte del comerciante. Para el ecosistema, esto es un recordatorio de que la confianza no verificada sigue siendo una invitación abierta a los atacantes.
Sobre el autor
pedro fortuna Se desempeña como cofundador y director de tecnología, responsable de la innovación tecnológica, la estrategia de productos y la investigación y el desarrollo. codificador. Pedro tiene más de 20 años de experiencia en ingeniería de software y seguridad, liderando el desarrollo de productos innovadores desde el concepto hasta el mercado.
Pedro es miembro de la Junta Directiva de PCI SSC y es un Asesor de Seguridad Interna (ISA) certificado. También es un orador habitual en conferencias internacionales de seguridad, inventor, coautor de múltiples patentes de AppSec y participa en la comunidad local de seguridad de aplicaciones, codirigiendo el Capítulo OWASP Porto.
Pagos recientesPróxima noticia:
Decodificando el proyecto de ley de datos del Reino Unido: lo que significa para la confianza, la innovación y la ventaja competitiva
