Scripts de terceros y riesgo de la página de pago

Una página de pago no la arma solo la tienda. Además de su propio código carga scripts de terceros: la pasarela, la medición de visitas, el chat de ayuda, el simulador de cuotas. Todos corren en el navegador del cliente con el mismo acceso a la página que el código propio, y si el formulario de la tarjeta está en esa página, cualquiera de ellos puede leer lo que el cliente escribe. Si un tercero es comprometido y su script cambia, el robo ocurre en el navegador del cliente: los servidores de la tienda no ven nada raro, porque los datos nunca pasan por ellos camino del adversario.

PCI DSS v4.0 respondió con dos requisitos, obligatorios desde el 31 de marzo de 2025. El 6.4.3 pide gestionar cada script de la página de pago que se ejecuta en el navegador: un método que confirme que está autorizado, otro que asegure su integridad y un inventario con la justificación escrita de por qué hace falta. El 11.6.1 pide un mecanismo de detección de cambios y manipulación que avise al personal cuando cambien sin autorización las cabeceras HTTP o el contenido de la página de pago tal como la recibe el navegador del cliente.

Abre la consola y ejecuta SELECT * FROM inventario_autorizado y SELECT * FROM scripts_observados. El inventario es lo que la tienda cree que carga; el monitor registra lo que de verdad llegó al navegador de prueba. La diferencia entre las dos listas es el primer hallazgo.

No todo lo que falta en el inventario es malicioso: a veces un área instala algo por su cuenta. Pero un script sin autorizar en la página de pago es un incumplimiento aunque sea inofensivo, y se registra como tal.

Ejecuta SELECT * FROM cambios_aprobados. Un script autorizado también es riesgo si cambia: la integridad se comprueba contra una huella aprobada, y cada versión nueva necesita su aprobación. Si la huella observada coincide con la del inventario o con un cambio aprobado, el script es el que se autorizó; si no coincide con ninguna, alguien lo cambió por fuera del proceso.

Después ejecuta SELECT * FROM conexiones_del_navegador y SELECT * FROM boletin_tipacoque: un script cambiado que, además, envía datos a un destino nuevo justo cuando el cliente pulsa Pagar ya no es un descuido de versión.

El monitor carga la página con un navegador de prueba y datos de tarjeta de prueba, y registra a qué destinos se conecta cada script. Un script de medición de visitas habla con su propio servidor; uno que, al pulsar Pagar, envía el contenido del formulario a un dominio distinto está sacando los datos. Si ese dominio aparece además en el boletín del grupo de intercambio, el hallazgo propio y el ajeno se confirman mutuamente.

Ejecuta SELECT * FROM historial_de_huellas y SELECT * FROM pagos_por_franja. El monitor revisa la página una vez al día; la alerta dice cuándo se vio el cambio, no cuándo ocurrió. Como no se sabe en qué momento entre dos revisiones cambió el script, la ventana se cuenta desde la última revisión en que la huella era la buena hasta que se retiró el script. Contar desde la alerta subestima a los clientes que hay que proteger: son los pagos de esa ventana los que se cruzan con la pasarela y los bancos.