Resumen: elegibilidad del SAQ A de enero de 2025 y autoatestación de scripts
- La trampa de la atestación: Eliminar 6.4.3 y 11.6.1 del SAQ A no facilitó las cosas. Los sustituyó por una autoatestación de que «tu sitio no es susceptible a ataques desde scripts», y la mayoría de los comercios carecen de la experiencia técnica para evaluar con precisión si son susceptibles a ataques del lado del cliente.
- Escala del ataque: JavaScript es usado por el 98,9% de todos los sitios web, y en enero de 2025 cside detectó más de 15.000 sitios recién afectados en un solo mes, con más de 600.000 sitios impactados en 2024. Las comprobaciones basadas en escáner pasan por alto ataques sigilosos que solo se activan el 1% de las veces o en una región concreta.
- Defender el sí: Si confías en una redirección o un iframe y crees que estás a salvo, los secuestros de botones y los formularios falsos superpuestos siguen funcionando. Si quieres responder la atestación con certeza, la monitorización continua del lado del cliente como cside es la única forma de defender el «sí».
¿Poco tiempo? Consulta cside PCI Shield. Cubre todo lo de abajo en un solo despliegue.
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 del Cuestionario de Autoevaluación A (SAQ A) para PCI DSS (Payment Card Industry Data Security Standard) v4.0.1.
El comunicado indica que, según los comentarios de las partes interesadas, los requisitos 6.4.3 y 11.6.1 han sido eliminados del SAQ A. En su lugar, los comerciantes deben confirmar:
«debe 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 por completo el procesamiento de pagos a proveedores externos y que no gestionan ni almacenan datos de pago por sí mismos.
Sin embargo, el 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 en torno 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 este artículo explicamos qué significa la actualización en la práctica.
Nuevas responsabilidades para los comerciantes del SAQ A
El PCI SSC ha desarrollado estos Cuestionarios de Autoevaluación (SAQ) 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 menos vulnerables, 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 autoatestar 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 susceptibles 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 dejen de ser elegibles para el SAQ A.
Necesidad de mayor claridad
El PCI SSC ofrece una variedad de Cuestionarios de Autoevaluación. Aun así, el documento «SAQ Instructions and Guidelines» todavía no se ha actualizado para reflejar estos cambios.
Dado el cambio significativo de alcance, creemos que es necesaria una actualización para garantizar que los comerciantes comprendan plenamente sus obligaciones de cumplimiento.
Qué es el SAQ A y cómo aplicarlo
Como lo expresa 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."
Ten en cuenta que los criterios de elegibilidad actualizados para el SAQ A han cambiado a: "comerciantes con las 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 los pagos, no tiene ningún 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 usar un iframe, es casi 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 usar el término «skimming» por ser vago y estar sujeto a interpretación, y en su lugar utiliza el término más técnico de «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 digitales:
- Páginas de pago con redirección: en el checkout, el visitante es redirigido al dominio independiente de un proveedor de pagos para introducir los datos de su tarjeta. Una vez completada la transacción, es enviado de vuelta al sitio del comerciante.
- Un 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.
- Un 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 entender dónde y qué riesgos del lado del cliente aplican es esencial para el cumplimiento.
Riesgos de seguridad en las 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 y enviar 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. Usar 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 ejecución ligeramente distinta 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» de abajo.
.pay-button:active { background-color: #166534; }
Pay NowAl ver esa página, ¿pensarías que algo estaba mal?
Esta página tardó 5 minutos en crearse. Aunque no puedes introducir realmente tus datos de pago en esa página de demostración, con dos minutos más de trabajo podría capturar cualquier dato que introdujeras en ese campo de pago y usarlo para pagarle al comerciante real. Eso significa que recibirías la confirmación de tu pedido y todo parecería ir como se espera, mientras al mismo tiempo se roba la información de la tarjeta de crédito.
Los atacantes pueden incluso insertar dinámicamente el logotipo del comerciante, haciendo que la página falsa parezca idéntica al sitio original. Para que el ataque sea más sigiloso, pueden redirigir solo a un cierto porcentaje de los visitantes, limitarlo a determinadas horas del día o regiones, o evitar las direcciones IP propias del comerciante, dejando 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 evitarlo.
Riesgos de seguridad en los formularios de pago embebidos
Si tu negocio se encuentra en la categoría 2, es decir, si embebes 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 muy 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 sustituyéndolo por un campo de entrada falso.
Otras técnicas pueden capturar información sensible de forma igual de invisible.
Lectura relacionada: nuestra guía de cumplimiento de PCI DSS 6.4.3 y 11.6.1 · cómo cumplir con PCI DSS 6.4.3
Cualquier JavaScript malicioso en el sitio web de un comerciante tendría vía libre sobre la página y podría ejecutar estos ataques. La única forma de eliminar por completo este riesgo sería quitar todo el JavaScript de la página de pago o implementar cabeceras CSP muy estrictas y directivas SRI, algo que rara vez es viable, ya que la mayoría de los proveedores de pago (y herramientas críticas habituales como chatbots, analítica web, informes de errores, etc.) requieren JavaScript dinámico del lado del cliente para funcionar correctamente.
Mantener estos controles mientras la producción sigue funcionando correctamente es un desafío considerable, especialmente con frameworks y plataformas como React, Vue, Magento, Drupal y WooCommerce. Lograr este nivel de seguridad de forma manual, sin una solución dedicada, es casi imposible sin un esfuerzo enorme y frágil.
Riesgos de seguridad en los formularios diseñados y gestionados por el comerciante
Si tu negocio se encuentra en la categoría 3, donde has creado 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 los datos de pago mediante keylogging.
¿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, lo que permite una carga más rápida y una navegación fluida entre páginas.
Sin embargo, el objetivo 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 no estaban destinados a ejecutarse.
Como consecuencia, el enfoque de la especificación original en «scripts en la página de pago» resulta 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.
Los scripts de NPM pueden inyectar fácilmente payloads obtenidos del lado del cliente. Las herramientas de seguridad centradas en las amenazas de la cadena de suministro de NPM tienen dificultades para detectar estas inyecciones con eficacia, ya que carecen de visibilidad sobre la actividad del lado del cliente, especialmente en tiempo real y de forma continua.
Esta publicación viral en Medium de 2018 explica este método de una forma entretenida.
Herramientas de terceros
Otro método de inyección habitual es secuestrar un script o herramienta de terceros añadido al sitio web. Pueden ser herramientas de analítica, publicidad, pruebas A/B, widgets o scripts de seguimiento de redes sociales. Estos scripts suelen tener un árbol de dependencias con muchas herramientas de código abierto integradas en su interior.
El ataque de polyfill de junio de 2024 fue un ejemplo destacado de este método de ataque utilizado en el mundo real. 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 una 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 son muy susceptibles a inyecciones del lado del cliente a través de CVE 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 utilizadas para robar datos del titular de la tarjeta. Esta amenaza ahora va más allá de Magento: solo en enero de 2025 detectamos más de 15.000 sitios web de WordPress afectados por nuevos ataques del lado del cliente.
JavaScript se utiliza como lenguaje de programación del lado del cliente en el 98,9% de todos los sitios web, lo que lo convierte en un objetivo prioritario para su explotación.
Por lo tanto, sin seguridad del lado del cliente, no hay forma de descartar con confianza un ataque ni de afirmar inmunidad ante él.
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 con una herramienta activa y en tiempo real. Este enfoque va más allá de los métodos tradicionales, como los rastreadores puntuales, la revisión manual de scripts en una página de pago o la comprobación del código front-end en busca de URL 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 active en condiciones específicas, como activarse solo el 1% de las veces, en un momento concreto del día 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. Aun así, en algunos casos es lo único que se puede hacer, por lo que ofrecemos uno 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 esa 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 es que algunos comerciantes se apresuren a adoptar una configuración de página de pago de terceros, asumiendo que esto mejora la seguridad y los califica para el SAQ A. Aun así, esto no elimina el riesgo de robo de tarjetas de crédito si los scripts de su sitio web están comprometidos, tal como se explicó con el método de secuestro de botones.
Otro resultado probable es que las empresas simplemente soliciten el SAQ A, confiando después de todo en la autoevaluación, y esperando lo mejor sin abordar los riesgos.
El aumento de los riesgos de ataques del lado del cliente
Los ataques del lado del cliente están aumentando al ritmo de la creciente complejidad de los navegadores modernos.
Como empresa de seguridad del lado del cliente, recomendamos el enfoque más protector disponible, uno que salvaguarde tanto a los clientes como a los comerciantes.
Los ataques del lado del cliente van en aumento. Más de 600.000 sitios web se vieron afectados en 2024, y solo en enero de 2025 detectamos más de 15.000 sitios web recién afectados.
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.
