PCI DSS v4.0 y la protección contra scripts dañinos

La última versión de PCI DSS v4.0 acaba de salir y es realmente increíble ver que una de las amenazas más notorias que enfrentamos en línea, cuando se trata de datos de tarjetas de pago, ahora se está abordando directamente. Magecart ha causado estragos en algunas marcas realmente grandes y organizaciones bien conocidas en los últimos años y ha causado daños por valor de millones de dólares. ¿Quizás este es el principio del fin para ellos?

Magecart

Magecart es un término colectivo para una serie de grupos de delincuentes informáticos que se enfocan en robar datos de tarjetas de pago de sitios web de comercio electrónico al encontrar una manera de inyectar su propio JavaScript hostil en la página.

Su JavaScript, a menudo conocido como "skimmer", lee los datos de la tarjeta de crédito/débito de la página y los envía a los atacantes, quienes luego cobrarán las transacciones fraudulentas en esas tarjetas. El ataque tiene tanto éxito porque no evita que se realice el pago genuino, sino que simplemente roba una copia de los datos de la tarjeta al mismo tiempo. Magecart ha causado daños por valor de millones de dólares a marcas que reconocería, como British Airways y Ticketmaster, además de imponerles a esas organizaciones algunas multas de protección de datos bastante fuertes por las violaciones de datos también. Las principales medidas de seguridad para Magecart y otros ataques similares como Cryptojacking, son CSP y SRI. 

PCI DSS v4.0

El PCI SSC es el PCI Security Standards Council es responsable de producir el PCI DSS, el estándar de seguridad de datos PCI. Si maneja datos de tarjetas de pago (PCD), debe cumplir con PCI DSS de alguna manera. 

La última versión de PCI DSS, v4.0 [PDF], acaba de llegar y han pasado más de 8 años desde la última actualización importante. En ese momento, Magecart y ataques similares han causado enormes problemas y pérdidas financieras para PCI y, como era de esperar, PCI SSC ha agregado algunos requisitos nuevos en PCI DSS destinados únicamente a neutralizar tales ataques en el futuro.

Protección de páginas de pago

El PCI DSS da la siguiente definición de una página de pago:

Una interfaz de usuario basada en la web que contiene uno o más elementos de formulario, destinados a capturar datos de la cuenta de un consumidor o enviar datos capturados. La página de pago se puede representar como:

• Un solo documento o instancia;
• Un documento o componente que se muestra en un marco dentro de una página de pago;
• Múltiples documentos o componentes, cada uno de los cuales contiene uno o más elementos de formulario contenidos en múltiples marcos dentro de una página de pago.

En el flujo típico de una transacción de comercio electrónico, se tiene la página de pago, que enumera todos los artículos que se desea comprar. Luego de la confirmación de la compra, se ingresa a la página de pago, donde se inserta el PCD y pagan los artículos. Una vez que el pago se procesa con éxito en la página de pago, se lo lleva a la página de confirmación de pago. Tiene sentido que los nuevos requisitos apunten solo a las páginas de pago, ya que esas son las páginas en las que un skimmer hostil tendría acceso al PCD para robar.

Requisito 6: desarrollar y mantener sistemas y software seguros

El primer requisito importante a tener en cuenta en PCI DSS 4.0 es uno que introduce algunos controles bastante estrictos sobre JavaScript en las páginas de pago.

6.4 Las aplicaciones web públicas están protegidas contra ataques.

Mirando el requisito 6.4.3, está bastante claro que el objetivo aquí es combatir Magecart y ataques similares, aunque no se llamen por su nombre. La guía asociada para esta sección brinda una explicación detallada de cómo se llevaría a cabo un ataque típico de skimming de Magecart y cómo estos nuevos requisitos pretenden combatirlo. Mirando los puntos principales en 6.4.3, tenemos las siguientes tres cosas que deben suceder:

• Se implementa un método para confirmar que cada script está autorizado.
• Se implementa un método para asegurar la integridad de cada script.
• Se mantiene un inventario de todos los scripts con justificación por escrito de por qué cada uno es necesario. 

El primer punto es, por supuesto, la Política de Seguridad de Contenido (CSP) y el segundo punto es la Integridad de los Subrecursos (SRI), pero el punto final implica algo bastante interesante. Para los scripts en la página de pago, debe tener una "justificación por escrito de por qué cada uno es necesario". No una justificación de por qué se desea o por qué está ahí, sino por qué es necesario. El PCI SSC también proporciona una definición clara de lo que significa exactamente "necesario":

"Necesario" para este requisito significa que el revisión de la entidad de cada script justifica y confirma por qué es necesario para la funcionalidad de la página de pago y para aceptar una transacción de pago.

Está bastante claro que JS en el pago debe ser necesario para aceptar una transacción de pago, y no para ningún otro propósito. Esto es realmente importante porque, históricamente, al investigar los ataques de Magecart y Cryptojacking, los sitios parecen tener una gran cantidad de JS en la página de pago porque era "requerido".

El JS en la página de pago que se usó en algunos de los ataques más notables fue "requerido" para rastrear al usuario a través del flujo de pago, proporcionando bots de chat o widgets, o simplemente estaba allí porque las etiquetas JS estaban presentes en todas las páginas durante todo el proceso de la aplicación y la página de pago no era la excepción. La página de pago solo necesita hacer una cosa y es aceptar el PCD del usuario para procesar una transacción, y ahora está muy claro que el único JS permitido en la página es el JS que se usa solo para ese propósito.

Un gran ejemplo de dónde esto habría detenido un ataque a gran escala fue el caso de Ticketmaster e Inbenta cubierto por RiskIQ. Inbenta proporcionó un chatbot que Ticketmaster cargaba en su sitio y, como veo muy a menudo, se usó Google Tag Manager para inyectar la etiqueta JS en cada página del sitio. Inbenta se vio comprometida y el JS se usó para realizar skimming en la PCD porque el chatbot se cargaba en la página de pago.

Imagine a un usuario navegando por todo su sitio, poniendo artículos en su cesta, yendo a la caja y finalmente llegando a la página de pago, solo para pensar "oh sí, me vendría bien iniciar un chat de atención al cliente ahora"... Ese JS simplemente no debería haber estado en la página de pago y si no hubiera estado allí, todo este ataque nunca habría ocurrido. Según las nuevas reglas, la presencia de este chatbot en la página de pago estaría prohibida.

Otro argumento común para colocar JS arbitrario en la página de pago es el seguimiento de conversiones, pero esto se soluciona muy fácilmente. Si rastrea al usuario hasta la página de pago, se debe omitir el seguimiento la página de confirmación de pago. Siempre hay una manera de resolver el problema sin tener montones de JS en la página de pago, y ahora, como industria, vamos a tener que aplicar esas soluciones.

Al final de 6.4.3, obtenemos algunos ejemplos de cómo podríamos lograr los requisitos establecidos anteriormente.

• Integridad de Subrecursos (SRI), que permite que la navegador del consumidor pueda validar que un script no ha sido manipulado.
• Usar CSP limita las ubicaciones en las que el navegador del consumidor puede cargar un script. Con CSP se puede controlar desde dónde se carga el contenido, como JS, pero también se puede controlar dónde se envían los datos con funciones como connect-src y form-action. En una página de pago es muy probable que solo haya una única ubicación a la que se deban enviar los datos de esa página, y puede asegurarse de que eso suceda con CSP. La otra es que puede controlar desde dónde se cargan los iframes y, de nuevo, es muy probable que al realizar el pago, solo se deba cargar un iframe desde un lugar, ¡y ese es su proveedor de servicios de pago!
• Usar script con gestores de etiquetas (Tag-Manager), que pueden evitar la ejecución de comandos maliciosos. Tal vez estas características lleguen con el tiempo con ¿GTM?

Conclusión

Las páginas de pago solo deben cargar JS requerido para procesar pagos. Las páginas de pago deben restringir lo que carga JS, por ejemplo, con CSP. Las páginas de pago deben comprobar la integridad de JS, por ejemplo, con SRI. Las páginas de pago deben monitorearse en busca de cambios, por ejemplo, con informes CSP. 

Fuente: Scott Helme

Suscríbete a nuestro Boletín