Por qué el inventario de scripts no detecta el QR cambiado

Una tienda de artículos deportivos en Curitiba, Brasil, pasó su evaluación de PCI DSS en agosto con el inventario de scripts de la página de pago completo: cada archivo listado, justificado y con la integridad verificada. En septiembre, una clienta pagó R$ 412 por Pix (el sistema de pagos instantáneos de Brasil), el pedido quedó en “esperando pago” y el dinero nunca llegó. El informe de esa semana no mostró script nuevo, cambio no autorizado ni alerta. Todo en verde. El QR había sido cambiado igual.

Para qué se creó el inventario

Los requisitos 6.4.3 y 11.6.1 de PCI DSS existen por un problema concreto: scripts cargados en la página de pago que capturan los datos de la tarjeta de crédito o de la tarjeta de débito que el cliente escribe. El 6.4.3 pide que cada script esté autorizado, justificado y con la integridad protegida. El 11.6.1 pide un mecanismo que detecte cambios no autorizados en los encabezados de seguridad y en el contenido de la página, al menos cada semana.

Las herramientas construidas para esos requisitos listan lo que carga la página, avisan cuando aparece un script nuevo y detectan cuando cambia un archivo conocido. La pregunta que responden es “¿qué corre en esta página?”.

Un QR cambiado plantea otra pregunta: “¿lo que ve el cliente coincide con lo que emitió la tienda?”. La lista de scripts responde solo a la primera.

Tres escenas

Escena 1: Pix

La tienda genera el cobro en su proveedor de pagos y recibe un QR dinámico y un código para copiar y pegar. En el navegador del cliente, una extensión instalada hace meses (un “buscador de cupones” de una tienda de extensiones) reconoce el patrón del código Pix y reemplaza la clave y el nombre del receptor, manteniendo el importe. El cliente escanea, ve R$ 412 y un nombre de empresa razonable en la app del banco, y confirma.

Lo que ve el inventario: los scripts de siempre, con las firmas de siempre. La extensión corre en el navegador del cliente, fuera de cualquier lista que la tienda mantenga.

Lo que no ve el inventario: que el texto para copiar y pegar y la imagen del QR cambiaron después de cargar la página.

Escena 2: el boleto

Un plugin de envíos, autorizado en el inventario desde hace un año, recibe una actualización desde la cuenta comprometida del desarrollador. La nueva versión hace todo lo que hacía antes y una cosa más: cuando aparece la página del boleto (la boleta bancaria brasileña, que se paga escribiendo o escaneando una línea numérica), reescribe la línea numérica y el código de barras con los de un boleto emitido a otro beneficiario, mismo importe y mismo vencimiento.

Lo que ve el inventario: un script autorizado que cambió de versión, un evento rutinario que muchos equipos aprueban sin leer el código.

Lo que no ve el inventario: que la línea numérica en pantalla ya no es la que emitió la tienda. Para la herramienta, esa línea es contenido, un dato más, y los datos cambian con cada pedido.

Escena 3: UPI y PromptPay

Una tienda en India muestra el QR de UPI con el identificador de pago del comercio. Una tienda en Tailandia muestra el QR de PromptPay con el número del comerciante. En ambas, el cambio viene del tema de la plataforma, presente en la lista de scripts desde el primer día: un fragmento discreto reemplaza la imagen del QR por otra generada al momento, con el identificador de una cuenta de paso.

Lo que ve el inventario: el tema, autorizado desde la instalación, sin cambios recientes (el fragmento siempre estuvo ahí, inactivo).

Lo que no ve el inventario: dos QR distintos para el mismo cobro, uno en el servidor y otro en pantalla.

Lo que tienen en común

En ninguna de las tres escenas hay un script “nuevo” que detectar. El ataque usa algo ya autorizado (un plugin, un tema), algo que la tienda nunca controló (una extensión del cliente) o un cambio en contenido que la herramienta trata como dato y no como código.

Y el resultado es un pago válido para el sistema financiero. En septiembre de 2026, Procon-SP, defensa del consumidor de São Paulo, publicó una alerta sobre esto: QR y códigos Pix alterados en páginas de tiendas legítimas, con el importe correcto y sin señal visual en pantalla, días después de que Kaspersky describiera una campaña que alcanzó al menos 90 tiendas en línea brasileñas. El consejo al consumidor fue revisar el nombre y el número fiscal del receptor en la app del banco. Correcto, e insuficiente: el cliente no conoce ese número, y el estafador elige nombres plausibles.

Qué tiene que hacer la verificación

Si el cambio ocurre después de cargar la página, en el navegador del cliente, la comprobación tiene que ocurrir ahí, comparando dos cosas: lo que la tienda emitió y lo que la pantalla muestra.

Vale para cada medio de pago con destino visible:

• En Pix, la clave, el nombre del receptor y el importe del QR y del código para copiar y pegar.
• En el boleto, la línea numérica y el código de barras.
• En UPI, el identificador de pago del comercio; en PromptPay, el número del comerciante.
• En billeteras de stablecoins, la dirección de destino y la red.
• En tarjeta de crédito y en tarjeta de débito, el formulario que recibe los datos y el destino al que se envían.

Sin el lado “emitido”, la verificación solo puede decir que algo cambió, sin saber si es legítimo. Sin el lado “mostrado”, revisa un servidor que estuvo bien todo el tiempo.

Cómo lo hace Proteside

El inventario de scripts se mantiene, porque PCI DSS lo pide y resuelve el problema para el que fue creado. Es el primer paso. Los demás son:

1. Registrar lo emitido. Cuando la tienda o el proveedor genera el cobro, Proteside recibe el QR, la clave, la línea numérica o la dirección, y guarda el registro vinculado al pedido.
2. Comprobar en el navegador de quien paga. Un script ligero en la página de pago lee lo que está en pantalla (el QR, el texto para copiar y pegar, la línea numérica, la dirección) y lo compara con el registro del paso 1, en cada pantalla, de cada cliente, en cada pedido.
3. Bloquear antes de la confirmación. Si lo que aparece no coincide con lo emitido, el cliente ve un aviso en lugar del QR y el botón de copiar no entrega el código cambiado.
4. Registrar el intento. Cada divergencia se vuelve un evento con fecha, pedido, medio de pago, valor esperado y encontrado. Es evidencia para el equipo de seguridad y para el evaluador de PCI DSS, junto al inventario.

En el informe semanal, el inventario dice “ningún script no autorizado”. La comprobación dice “tres intentos de cambio de QR bloqueados”. La primera frase era cierta en la tienda de Curitiba. La segunda habría salvado la venta de R$ 412.

Para ver lo que cada tipo de herramienta de seguridad de la página de pago hace y no hace, con base en información pública fechada, consulte la página de comparativa.