Por que o inventário de scripts não detecta o QR trocado

Uma loja de material esportivo em Curitiba passou pela auditoria de PCI DSS em agosto. O inventário de scripts da página de pagamento estava completo: cada arquivo listado, justificado e com a integridade conferida. Em setembro, uma cliente pagou R$ 412 por Pix, o pedido ficou em “aguardando pagamento” e o dinheiro nunca chegou. O relatório daquela semana não registrou script novo, alteração não autorizada ou alerta. Tudo verde. O QR tinha sido trocado mesmo assim.

Para que o inventário foi criado

Os requisitos 6.4.3 e 11.6.1 do PCI DSS existem por causa de um problema específico: scripts carregados na página de pagamento que capturam os dados do cartão de crédito ou do cartão de débito digitados pelo cliente. O 6.4.3 pede que cada script seja autorizado, justificado e tenha a integridade garantida. O 11.6.1 pede um mecanismo que detecte alterações não autorizadas nos cabeçalhos de segurança e no conteúdo da página, com verificação ao menos semanal.

As ferramentas construídas para esses requisitos fazem o que prometem: inventariam o que a página carrega, avisam quando um script novo aparece e detectam quando um arquivo conhecido muda. A pergunta que elas respondem é “o que está rodando nesta página?”.

Um QR trocado faz outra pergunta: “o que aparece na tela corresponde ao que a loja emitiu?”. A lista de scripts responde à primeira e fica em silêncio na segunda.

Três cenas

Cena 1: o Pix

A loja gera a cobrança no provedor de pagamento e recebe um QR dinâmico e o código copia e cola. No navegador do cliente, uma extensão instalada meses atrás (um “buscador de cupons” baixado de uma loja de extensões) reconhece o padrão do código Pix e substitui a chave e o nome do recebedor, mantendo o valor. O cliente escaneia, vê R$ 412 e um nome de empresa razoável no aplicativo do banco, e confirma.

O que o inventário vê: os mesmos scripts de sempre, com as mesmas assinaturas de integridade. A extensão roda no navegador do cliente, fora do alcance de qualquer lista que a loja mantenha.

O que o inventário não vê: que o texto do copia e cola e a imagem do QR mudaram depois de a página carregar.

Cena 2: o boleto

Um plugin de frete, autorizado e justificado no inventário há um ano, recebe uma atualização pela conta comprometida do desenvolvedor. A nova versão faz tudo o que fazia antes e mais uma coisa: quando a página do boleto aparece, reescreve a linha digitável e o código de barras com os de um boleto emitido por outro beneficiário, no mesmo valor e com o mesmo vencimento.

O que o inventário vê: um script autorizado que mudou de versão, um evento rotineiro que muitas equipes aprovam sem ler o código.

O que o inventário não vê: que a linha digitável na tela já não é a que a loja emitiu. Para a ferramenta, a linha digitável é conteúdo, um dado qualquer da página, e dados mudam a cada pedido.

Cena 3: UPI e PromptPay

Uma loja na Índia mostra o QR de UPI com o identificador de pagamento do lojista. Uma loja na Tailândia mostra o QR de PromptPay com o número do comerciante. Nas duas, a troca vem do tema da plataforma, comprado em um marketplace e presente na lista de scripts desde o primeiro dia. Um trecho discreto do tema substitui a imagem do QR por outra gerada na hora, com o identificador de uma conta de passagem.

O que o inventário vê: o tema, autorizado desde a instalação, sem alteração recente de arquivo (o trecho sempre esteve lá, inativo).

O que o inventário não vê: dois QRs diferentes para a mesma cobrança, um no servidor e outro na tela.

O ponto em comum

Nas três cenas não existe um script “novo” para detectar. O ataque usa algo já autorizado (um plugin, um tema), algo que a loja nunca controlou (uma extensão do cliente) ou uma alteração em conteúdo que a ferramenta trata como dado, e não como código.

E o resultado é um pagamento válido para o sistema financeiro. Em setembro de 2026, o Procon-SP divulgou um alerta sobre isso: QR e copia e cola do Pix alterados em páginas de lojas legítimas, com valor correto e sem sinal visual na tela, dias depois de a Kaspersky descrever uma campanha que atingiu pelo menos 90 lojas virtuais brasileiras. A recomendação ao consumidor foi conferir nome e CNPJ do recebedor no aplicativo do banco. É um conselho correto e insuficiente: o cliente não sabe o CNPJ da loja, e o golpista escolhe nomes plausíveis.

O que a verificação precisa fazer

Se a troca acontece depois de a página carregar, no navegador do cliente, a conferência precisa acontecer lá também. E precisa comparar duas coisas: o que a loja emitiu e o que a tela está mostrando.

Vale para cada meio de pagamento com destino visível:

• No Pix, a chave, o nome do recebedor e o valor contidos no QR e no copia e cola.
• No boleto, a linha digitável e o código de barras.
• No UPI, o identificador de pagamento do lojista; no PromptPay, o número do comerciante.
• Em carteiras de stablecoins, o endereço de destino e a rede.
• No cartão de crédito e no cartão de débito, o formulário que recebe os dados e o destino para onde eles são enviados.

Sem o lado “emitido”, a verificação só consegue dizer que algo mudou, sem saber se a mudança é legítima. Sem o lado “exibido”, ela confere um servidor que estava certo o tempo todo.

Como o Proteside faz

O inventário de scripts continua, porque o PCI DSS pede e porque ele resolve o problema para o qual foi criado. É o primeiro passo. Os outros são:

1. Registrar o emitido. Quando a loja ou o provedor gera a cobrança, o Proteside recebe o QR, a chave, a linha digitável ou o endereço, e guarda o registro atrelado ao pedido.
2. Conferir no navegador de quem paga. Um script leve na página de pagamento lê o que está na tela (o QR, o texto do copia e cola, a linha digitável, o endereço) e compara com o registro do passo 1, em cada tela, de cada cliente, em cada pedido.
3. Bloquear antes da confirmação. Se o que aparece não corresponde ao que foi emitido, o cliente vê um aviso no lugar do QR, e o botão de copiar não entrega o código trocado. O pagamento não sai.
4. Registrar a tentativa. Cada divergência vira um evento com data, pedido, meio de pagamento, valor esperado e valor encontrado. É evidência para a equipe de segurança e para o auditor do PCI DSS, ao lado do inventário.

No relatório da semana, o inventário diz “nenhum script não autorizado”. A conferência diz “três tentativas de troca de QR bloqueadas”. A primeira frase era verdadeira na loja de Curitiba. A segunda teria salvado a venda de R$ 412.

Para saber o que cada tipo de ferramenta de segurança da página de pagamento faz e não faz, com base em informações públicas e datadas, veja a página de comparativo.