El PCI SSC actualiza el SAQ A para PCI DSS 4.0.1 – Lo que necesitas saber
El 30 de enero de 2025, el PCI SSC (Payment Card Industry Security Standards Council) publicó una actualización sobre el Cuestionario de Autoevaluación A (SAQ A) para PCI DSS (Payment Card Industry Data Security Standard) v4.0.1.
El comunicado indica que, debido a los comentarios de las partes interesadas, los requisitos 6.4.3 y 11.6.1 han sido eliminados del SAQ A. En su lugar, para que los comerciantes puedan acogerse al SAQ A:
"deben confirmar que su sitio no es susceptible a ataques de scripts que puedan afectar los sistemas de comercio electrónico del comerciante".
Este cuestionario aplica a los comerciantes que externalizan completamente el procesamiento de pagos a proveedores externos y no gestionan ni almacenan datos de pago por sí mismos.
Sin embargo, la introducción del nuevo requisito de autoatestación ha generado preocupación, ya que muchas empresas carecen de la experiencia necesaria para evaluar con precisión su exposición a ataques del lado del cliente. Estos cambios crean nuevos desafíos de cumplimiento, especialmente en lo que respecta a los riesgos de seguridad del lado del cliente, dejando a los comerciantes con dudas sobre su elegibilidad y responsabilidades bajo el SAQ A.
Como empresa de seguridad del lado del cliente, ayudamos a nuestros clientes a cumplir con ambos requisitos, y en esta publicación buscamos aclarar las implicaciones de la actualización.
Nuevas responsabilidades para los comerciantes del SAQ A
El PCI SSC ha desarrollado estos Cuestionarios de Autoevaluación (SAQs) para revisar las obligaciones de cumplimiento de los comerciantes. Los comerciantes son responsables de evaluar si cumplen con los requisitos descritos en el cuestionario.
El SAQ A, diseñado para los comerciantes con menor nivel de riesgo, los exime de ciertos requisitos de PCI DSS dado que no almacenan datos del titular de la tarjeta (CHD).
Con esta revisión, los requisitos 6.4.3 y 11.6.1 ya no aplican a los comerciantes del SAQ A.
Sin embargo, un nuevo requisito del SAQ A es que los comerciantes deben autoatestarse indicando que "su sitio no es susceptible a ataques de scripts que puedan afectar los sistemas de comercio electrónico del comerciante".
No obstante, muchos comerciantes carecen de la experiencia técnica necesaria para evaluar con precisión si son vulnerables a ataques del lado del cliente.
Dado que el 98,9% de los sitios web utilizan actualmente JavaScript del lado del cliente, para muchos comerciantes este nuevo requisito podría hacer que ya no sean elegibles para el SAQ A.
Necesidad de mayor claridad
El PCI SSC ofrece una variedad de Cuestionarios de Autoevaluación. Sin embargo, el documento "SAQ Instructions and Guidelines" del SAQ aún no ha sido actualizado para abordar estos cambios.
Dado el cambio significativo en el alcance, consideramos que una actualización es necesaria para garantizar que los comerciantes comprendan plenamente sus obligaciones de cumplimiento.
Qué es el SAQ A y cómo aplicarlo
Según el PCI SSC:
"Los comerciantes del SAQ A pueden ser comerciantes de comercio electrónico o de pedidos por correo/teléfono (tarjeta no presente), y no almacenan, procesan ni transmiten ningún dato del titular de la tarjeta en formato electrónico en sus sistemas o instalaciones."
Nótese que los criterios de elegibilidad actualizados para el SAQ A han sido modificados a: "comerciantes con funciones de datos de cuenta completamente externalizadas a terceros validados y conformes con PCI DSS, donde el comerciante conserva únicamente informes en papel o recibos con datos de cuenta."
Y ahora también exige al comerciante: "debe confirmar que su sitio no es susceptible a ataques de scripts que puedan afectar los sistemas de comercio electrónico del comerciante."
Si un comerciante depende de la página web de un proveedor externo para procesar pagos, los comerciantes no tienen control sobre si ocurre un ataque de script del lado del cliente en la página de pago del tercero. La monitorización es responsabilidad del procesador de pagos.
En cuanto al segundo grupo, las declaraciones sobre iframes son vagas y generan una narrativa falsa. Al utilizar un iframe, es prácticamente imposible eliminar por completo el riesgo de ataques del lado del cliente.
Para confirmar que el sitio de un comerciante no es susceptible a ataques del lado del cliente, exploremos cuándo ocurren estos ataques o qué se considera un ataque del lado del cliente.
La documentación del PCI SSC dejó de utilizar el término "skimming" por ser vago y sujeto a interpretación, y en su lugar emplea un término más técnico: 'ataques del lado del cliente' o 'ataques de scripts'.
Definimos los 'ataques del lado del cliente' o 'ataques de scripts' como cualquier método que un actor malicioso utiliza para capturar la información de la tarjeta de pago de un usuario directamente desde su navegador.
Cómo ocurren los ataques del lado del cliente
Existen 3 categorías de páginas de pago digital:
- Páginas de pago con redirección: al momento del pago, el visitante es redirigido al dominio separado de un proveedor de pagos para ingresar los datos de su tarjeta. Una vez completada la transacción, es enviado de vuelta al sitio del comerciante.
- Formulario de pago embebido: los datos de pago se recopilan a través de un iframe o widget, que incorpora un 'mini navegador' de un tercero dentro del sitio web del comerciante para mostrar el formulario del proveedor de pagos.
- Formulario diseñado y gestionado por el comerciante: el formulario de pago es diseñado y gestionado por el comerciante y transmite los datos de pago al procesador de pagos mediante API.
Cada categoría tiene sus propias implicaciones de seguridad, y comprender dónde y qué riesgos del lado del cliente aplican es esencial para el cumplimiento.
Riesgos de seguridad en páginas de redirección
Las páginas de redirección pueden parecer seguras, pero los comerciantes no tienen control sobre la página de pago. Si se inyecta un script malicioso, los atacantes pueden secuestrar el proceso de redirección, enviando a los clientes a una página de pago fraudulenta que parece idéntica a la real, robando sus datos de pago en el proceso. Incluso cuando se utiliza un proveedor externo de confianza para el pago, los riesgos del lado del cliente persisten. Los scripts maliciosos pueden modificar las funciones de clic, alterando el flujo de pago sin ser detectados. Utilizar un proveedor de pagos externo no elimina el riesgo de ataques del lado del cliente; en cambio, expone los sitios de los comerciantes a una variante ligeramente diferente de estos ataques.
Demo de ataque: cómo se puede manipular una página de pago
Imagina que estás comprando en línea y haces clic en el botón 'pagar ahora' que aparece a continuación.
.pay-button:active { background-color: #166534; }
Pay NowAl ver esa página, ¿notarías algo sospechoso?
Esta página tardó 5 minutos en crearse. Aunque en esa página de demostración no puedes ingresar tus datos de pago reales, con dos minutos más de trabajo podría capturar cualquier dato que introduzcas en ese campo de pago y utilizarlo para pagar al comerciante real. Eso significa que recibirías tu confirmación de pedido y todo parecería normal, mientras que al mismo tiempo se estaría robando la información de tu tarjeta de crédito.
Los atacantes incluso pueden insertar dinámicamente el logotipo del comerciante, haciendo que la página falsa parezca idéntica al sitio original. Y para hacer el ataque más sigiloso, pueden redirigir solo un cierto porcentaje de los clientes finales, en determinados momentos del día, en ciertas partes del mundo, o incluso evitando las direcciones IP del comerciante, lo que facilita que el ataque pase desapercibido durante mucho tiempo.
Al secuestrar la pulsación del botón que redirige al usuario a la página de pago, el procesador de pagos no habría podido prevenir el ataque. El comerciante era la única parte en este ejemplo que podría haber tomado medidas para prevenirlo.
Riesgos de seguridad en formularios de pago embebidos
Si tu negocio pertenece a la categoría 2, es decir, embebe un iframe en tu sitio web para mostrar el formulario de un proveedor de pagos externo, tu proceso de pago sigue siendo vulnerable a ataques del lado del cliente.
Un script malicioso puede interceptar fácilmente los datos del titular de la tarjeta de varias formas:
- Renderizando otro iframe encima del iframe real del proveedor de pagos.
- Ocultando el iframe real y reemplazándolo con un campo de entrada falso.
- Y otros métodos de ataque para capturar información sensible sin ser detectado.
Cualquier JavaScript malicioso en el sitio web de un comerciante tendría control total sobre la página y podría ejecutar estos ataques. La única forma de eliminar completamente este riesgo sería eliminar todo el JavaScript de la página de pago o implementar cabeceras CSP muy estrictas y directivas SRI—lo cual rara vez es viable, ya que la mayoría de los proveedores de pago (y herramientas críticas comunes como chatbots, analítica web, informes de errores, etc.) requieren JavaScript dinámico del lado del cliente para funcionar correctamente.
Mantener estos controles mientras se garantiza el correcto funcionamiento en producción es un desafío significativo, especialmente cuando se utilizan frameworks y plataformas como React, Vue, Magento, Drupal, WooCommerce, etc. Lograr este nivel de seguridad de forma manual sin adquirir una solución dedicada es prácticamente imposible sin un esfuerzo enorme con impacto disruptivo.
Riesgos de seguridad en formularios diseñados y gestionados por el comerciante
Si tu negocio pertenece a la categoría 3, donde has construido tu propio componente de pago, tu proceso de pago es aún más vulnerable. Estos formularios de pago gestionados por el comerciante conllevan los mismos riesgos de secuestro que los iframes embebidos—y más—ya que otros scripts que se ejecutan en el sitio pueden registrar mediante keylogging los datos de pago.
¿Y cómo se inyectan los ataques del lado del cliente?
Frameworks web modernos
Los frameworks modernos de aplicaciones web de una sola página, como React, se han convertido en el estándar. Estos frameworks generan "aplicaciones web de una sola página" porque dependen de JavaScript del lado del cliente para actualizar dinámicamente la página web, permitiendo una carga más rápida y una navegación fluida entre páginas.
Sin embargo, el propósito central de estos frameworks es que no recargan la página. Como resultado, los scripts añadidos a una parte específica del sitio pueden ejecutarse en cualquier página, a menos que se fuerce una recarga completa antes de navegar. Esto introduce riesgos de seguridad, porque los scripts maliciosos pueden permanecer activos cuando el usuario navega a páginas donde esos scripts no estaban destinados a ejecutarse.
Como consecuencia, el enfoque de la especificación original en "scripts en la página de pago" se vuelve ineficaz para las aplicaciones de una sola página, el enfoque más popular en el desarrollo web durante muchos años.
Además, los desarrolladores de stacks modernos dependen de dependencias de código abierto de NPM. Esto tiene mucho sentido, ya que los sitios web realizan funciones similares y reescribir todo desde cero sería como reinventar la rueda. Usar bibliotecas preconstruidas acelera significativamente el desarrollo web.
Lo que muchos no saben es que los scripts de NPM pueden inyectar fácilmente payloads obtenidos del lado del cliente. Las herramientas de seguridad centradas en amenazas de la cadena de suministro de NPM tienen dificultades para detectar estas inyecciones de forma eficaz ya que carecen de visibilidad sobre la actividad del lado del cliente, especialmente el 100% del tiempo y en tiempo real.
Esta excelente publicación viral en Medium de 2018 explica este método de una manera bastante entretenida.
Herramientas de terceros
Otro método de inyección común es el secuestro de un script/herramienta de terceros que fue añadido al sitio web. Estas pueden ser herramientas de analítica, publicidad, pruebas A/B, widgets, scripts de seguimiento de redes sociales… Estos scripts suelen tener un árbol de dependencias con muchas herramientas de código abierto embebidas en su interior.
El ataque de polyfill de junio de 2024 fue un ejemplo destacado de este método de ataque utilizado en la práctica. En realidad no es tan difícil de ejecutar. Los atacantes pueden secuestrar un bucket de S3, tomar el control de un dominio caducado embebido en sitios web, reclamar una URL de S3 abandonada o unirse a un proyecto de código abierto e inyectar silenciosamente alguna dependencia de terceros… las opciones son infinitas.
Inyecciones a través de plataformas heredadas
Incluso si utilizas una plataforma de comercio heredada, a menudo basada en PHP, se ha demostrado con el tiempo que estas son muy susceptibles a inyecciones del lado del cliente a través de CVEs comunes.
El nombre "Magecart", un término heredado para los ataques del lado del cliente, se originó a partir de inyecciones del lado del cliente en Magento para exfiltrar datos de titulares de tarjetas. Sin embargo, esta amenaza va más allá de Magento. Solo en enero de 2025 hemos detectado más de 15.000 sitios web afectados por nuevos ataques del lado del cliente en WordPress, lo que pone de relieve el creciente riesgo en todas las plataformas.
En este contexto, es importante reconocer que JavaScript es utilizado como lenguaje de programación del lado del cliente por el 98,9% de todos los sitios web, convirtiéndolo en un objetivo principal para la explotación.
Por lo tanto, sin seguridad del lado del cliente, no hay forma de descartar con certeza un ataque ni de afirmar inmunidad ante uno.
Monitorización del lado del cliente en tiempo real para la seguridad web
La forma más eficaz de proteger tu sitio web y mantener el cumplimiento de PCI DSS es monitorizar todo el entorno del lado del cliente mediante una herramienta de monitorización activa y en tiempo real. Este enfoque va más allá de los métodos tradicionales, como un rastreador puntual, la revisión manual de scripts en una página de pago o la verificación del código front-end en busca de URLs maliciosas conocidas.
Solo mediante la monitorización continua puedes afirmar con confianza que tu "sitio no es susceptible a ataques de scripts que puedan afectar los sistemas de comercio electrónico del comerciante".
Los scripts del lado del cliente son dinámicos y pueden renderizarse de forma condicional. Un actor malicioso podría inyectar un payload malicioso que se activa en condiciones específicas, como activarse solo el 1% de las veces, en un momento concreto o únicamente para clientes de una región específica.
Debido a estas técnicas evasivas y sigilosas, un enfoque basado en escáneres está lejos de ser ideal para este vector, ya que deja demasiados puntos ciegos… pero en algunos casos es lo único que se puede hacer, por lo que lo ofrecemos como solución de último recurso.
¿Calificas para el SAQ A? - Diagrama
Según nuestra interpretación, el cuestionario a continuación debería ayudarte a entender si calificas para el SAQ A:
Aunque la redacción vaga deja margen para la interpretación, lo que dificulta determinar el cumplimiento con claridad. Debido a la falta de claridad, sospechamos que calificar para el SAQ A con certeza es un desafío, especialmente dado lo cerca que están estos cambios de la fecha límite de cumplimiento del 31 de marzo de 2025.
En la práctica, la mayoría de los comerciantes tendrían dificultades para responder con confianza "sí" a la pregunta:
"El comerciante ha confirmado que su sitio no es susceptible a ataques de scripts que puedan afectar los sistemas de comercio electrónico del comerciante."
Un posible resultado podría ser que algunos comerciantes se apresuren a adoptar una configuración de página de pago de terceros, asumiendo que mejora la seguridad y los califica para el SAQ A. Sin embargo, esto no elimina el riesgo de robo de tarjetas de crédito si los scripts de su sitio web están comprometidos, como se explicó con el método de secuestro de botones.
Otro resultado probable podría ser que las empresas simplemente soliciten el SAQ A, confiando en la autoevaluación después de todo, y esperando lo mejor sin abordar los riesgos.
El creciente riesgo de los ataques del lado del cliente
Considerando el panorama actual de ataques y la creciente complejidad de los navegadores modernos, las empresas se encuentran en un punto de inflexión.
Como empresa de ciberseguridad, siempre abogamos por el enfoque más seguro, uno que proteja activamente tanto a los clientes como a las empresas.
Los ataques del lado del cliente están en aumento. Más de 600.000 sitios web se vieron afectados en 2024 y solo en enero de 2025 hemos detectado más de 15.000 sitios web recién comprometidos.
Tu responsabilidad: monitorización continua
La mejor manera de garantizar el cumplimiento de PCI DSS es monitorizar todo tu entorno del lado del cliente en tiempo real. Es tu responsabilidad anticiparte a estas amenazas y proteger a tus clientes.
Para cualquier aclaración o consulta, contáctanos hoy mismo.
