PCI SSC atualiza o SAQ A para o PCI DSS 4.0.1 – O que você precisa saber
Em 30 de janeiro de 2025, o PCI SSC (Payment Card Industry Security Standards Council) publicou uma atualização sobre o Questionário de Autoavaliação A (SAQ A) para o PCI DSS (Payment Card Industry Data Security Standard) v4.0.1.
O comunicado informa que, em resposta ao feedback das partes interessadas, os requisitos 6.4.3 e 11.6.1 foram removidos do SAQ A. Em vez disso, para que os comerciantes se qualifiquem para o SAQ A:
"devem confirmar que seu site não está suscetível a ataques de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante".
Este questionário se aplica a comerciantes que terceirizam completamente o processamento de pagamentos para provedores externos e não manipulam nem armazenam dados de pagamento por conta própria.
No entanto, a introdução do novo requisito de autoatestação gerou preocupações, pois muitas empresas não têm expertise técnica para avaliar com precisão sua exposição a ataques no lado do cliente. Essas mudanças criam novos desafios de conformidade, especialmente em relação aos riscos de segurança no lado do cliente, deixando os comerciantes incertos sobre sua elegibilidade e responsabilidades no âmbito do SAQ A.
Como empresa especializada em segurança no lado do cliente, ajudamos nossos clientes a cumprir ambos os requisitos e, neste post, nosso objetivo é esclarecer as implicações dessa atualização.
Novas responsabilidades para comerciantes do SAQ A
O PCI SSC desenvolveu os Questionários de Autoavaliação (SAQs) para revisar as obrigações de conformidade dos comerciantes. Os comerciantes são responsáveis por avaliar se atendem aos requisitos descritos no questionário.
O SAQ A, projetado para os comerciantes com menor vulnerabilidade, os isenta de determinados requisitos do PCI DSS, dado que não armazenam Dados do Titular do Cartão (CHD).
Com esta revisão, os requisitos 6.4.3 e 11.6.1 deixam de se aplicar aos comerciantes do SAQ A.
Porém, um novo requisito do SAQ A é que os comerciantes devem autoatestar que "seu site não está suscetível a ataques de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante".
No entanto, muitos comerciantes não possuem expertise técnica para avaliar com precisão se estão suscetíveis a ataques no lado do cliente.
Considerando que 98,9% dos sites atualmente utilizam JavaScript no lado do cliente, esse novo requisito pode fazer com que muitos comerciantes deixem de ser elegíveis para o SAQ A.
Necessidade de mais clareza
O PCI SSC oferece uma variedade de Questionários de Autoavaliação. Ainda assim, o documento "SAQ Instructions and Guidelines" ainda não foi atualizado para contemplar essas mudanças.
Dada a significativa mudança de escopo, acreditamos que uma atualização é necessária para garantir que os comerciantes compreendam plenamente suas obrigações de conformidade.
O que é o SAQ A e como se candidatar
Conforme definido pelo PCI SSC:
"Os comerciantes do SAQ A podem ser de e-commerce ou de pedidos por correio/telefone (sem presença do cartão), e não armazenam, processam nem transmitem nenhum dado do titular do cartão em formato eletrônico em seus sistemas ou instalações."
Vale destacar que os critérios de elegibilidade atualizados para o SAQ A foram alterados para: "comerciantes com funções de dados de conta completamente terceirizadas para terceiros validados e em conformidade com o PCI DSS, onde o comerciante retém apenas relatórios em papel ou recibos com dados de conta."
E agora também exige que o comerciante: "confirme que seu site não está suscetível a ataques de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante."
Se um comerciante depende da página web de um provedor externo para processar pagamentos, ele não tem controle sobre a ocorrência de um ataque de script no lado do cliente na página de pagamento do terceiro. O monitoramento é responsabilidade do processador de pagamentos.
Em relação ao segundo grupo, as declarações sobre iframes são vagas e criam uma narrativa equivocada. Ao utilizar um iframe, é praticamente impossível eliminar completamente o risco de ataques no lado do cliente.
Para confirmar que o site de um comerciante não está suscetível a ataques no lado do cliente, vamos explorar quando esses ataques ocorrem e o que é considerado um ataque no lado do cliente.
A documentação do PCI SSC deixou de usar o termo "skimming" por ser vago e sujeito a interpretações, adotando em seu lugar um termo mais técnico: 'ataques no lado do cliente' ou 'ataques de scripts'.
Definimos 'ataques no lado do cliente' ou 'ataques de scripts' como qualquer método utilizado por um agente malicioso para capturar as informações do cartão de pagamento de um usuário diretamente do seu navegador.
Como os ataques no lado do cliente ocorrem
Existem 3 categorias de páginas de pagamento digital:
- Páginas de pagamento por redirecionamento: no checkout, o visitante é redirecionado para um domínio separado do provedor de pagamentos para inserir os dados do cartão. Após a conclusão da transação, ele é enviado de volta ao site do comerciante.
- Formulário de pagamento incorporado: os dados de pagamento são coletados por meio de um iframe ou widget, incorporando um 'mini navegador' de terceiros dentro do site do comerciante para exibir o formulário do provedor de pagamentos.
- Formulário projetado e gerenciado pelo comerciante: o formulário de pagamento é projetado e gerenciado pelo próprio comerciante e transmite os dados de pagamento ao processador via API.
Cada categoria tem suas próprias implicações de segurança, e entender onde e quais riscos no lado do cliente se aplicam é essencial para a conformidade.
Riscos de segurança em páginas de redirecionamento
As páginas de redirecionamento podem parecer seguras, mas os comerciantes não têm controle sobre a página de pagamento. Se um script malicioso for injetado, os atacantes podem sequestrar o processo de redirecionamento, enviando os clientes para uma página de pagamento fraudulenta visualmente idêntica à original e roubando seus dados de pagamento no processo. Mesmo ao utilizar um provedor terceirizado confiável para o pagamento, os riscos no lado do cliente permanecem. Scripts maliciosos podem modificar funções de clique, alterando o fluxo de checkout sem ser detectados. Usar um provedor de pagamentos terceirizado não elimina o risco de ataques no lado do cliente — pelo contrário, expõe os sites dos comerciantes a uma execução ligeiramente diferente desses ataques.
Demonstração de ataque: como uma página de pagamento pode ser manipulada
Imagine que você está comprando online e clica no botão 'pagar agora' abaixo.
.pay-button:active { background-color: #166534; }
Pay NowAo ver essa página, você perceberia que algo estava errado?
Essa página levou 5 minutos para ser criada. Embora não seja possível inserir dados de pagamento reais nessa página de demonstração, com mais dois minutos de trabalho eu poderia capturar qualquer dado que você inserisse no campo de pagamento e usá-lo para pagar o comerciante original. Isso significa que você receberia a confirmação do pedido e tudo pareceria normal, enquanto as informações do cartão de crédito seriam roubadas simultaneamente.
Os atacantes podem até inserir dinamicamente o logotipo do comerciante, fazendo com que a página falsa pareça idêntica ao site original. E para tornar o ataque ainda mais furtivo, é possível redirecionar apenas uma determinada porcentagem dos clientes finais, em determinados horários, em certas regiões do mundo, ou até mesmo evitar os endereços IP do próprio comerciante — facilitando que o ataque passe despercebido por um longo período.
Ao sequestrar o clique no botão que redireciona o usuário para a página de pagamento, o processador de pagamentos não teria como prevenir o ataque. O comerciante era o único agente nesse exemplo que poderia ter tomado medidas para evitá-lo.
Riscos de segurança em formulários de pagamento incorporados
Se o seu negócio se enquadra na categoria 2, ou seja, você incorpora um iframe no seu site para exibir o formulário de um provedor de pagamentos terceirizado, seu processo de checkout continua vulnerável a ataques no lado do cliente.
Um script malicioso pode interceptar os dados do titular do cartão de diversas formas:
- Renderizando outro iframe sobre o iframe real do provedor de pagamentos.
- Ocultando o iframe real e substituindo-o por um campo de entrada falso.
- E vários outros métodos de ataque para capturar informações sensíveis sem ser detectado.
Qualquer JavaScript malicioso no site de um comerciante teria controle total sobre a página e poderia executar esses ataques. A única forma de eliminar completamente esse risco seria remover todo o JavaScript da página de checkout ou implementar cabeçalhos CSP extremamente rígidos e diretivas SRI — o que raramente é viável, pois a maioria dos provedores de pagamento (e ferramentas críticas comuns como chatbots, analytics, relatórios de erros etc.) requer JavaScript dinâmico no lado do cliente para funcionar corretamente.
Manter esses controles e ao mesmo tempo garantir o funcionamento adequado em produção é um desafio significativo, especialmente ao utilizar frameworks e plataformas como React, Vue, Magento, Drupal, WooCommerce etc. Alcançar esse nível de segurança manualmente sem adquirir uma solução dedicada é praticamente impossível sem um esforço enorme com impacto disruptivo.
Riscos de segurança em formulários projetados e gerenciados pelo comerciante
Se o seu negócio se enquadra na categoria 3, onde você desenvolveu seu próprio componente de pagamento, seu processo de checkout é ainda mais vulnerável. Esses formulários de pagamento gerenciados pelo comerciante carregam os mesmos riscos de sequestro dos iframes incorporados — e mais — pois outros scripts em execução no site podem registrar os dados de pagamento via keylogging.
E como os ataques no lado do cliente são injetados?
Frameworks web modernos
Os frameworks modernos de aplicações web de página única, como o React, tornaram-se o padrão do mercado. Esses frameworks geram "webapps de página única" porque dependem de JavaScript no lado do cliente para atualizar dinamicamente a página, proporcionando carregamento mais rápido e navegação fluida entre páginas.
No entanto, o princípio fundamental desses frameworks é que eles não recarregam a página. Como resultado, scripts adicionados a uma parte específica do site podem ser executados em qualquer página, a menos que um recarregamento completo seja acionado antes da navegação. Isso introduz riscos de segurança, pois scripts maliciosos podem permanecer ativos quando o usuário navega para páginas onde esses scripts não deveriam estar presentes.
Como consequência, o foco da especificação original em "scripts na página de pagamento" torna-se ineficaz para aplicações de página única — a abordagem mais popular de desenvolvimento web há muitos anos.
Além disso, desenvolvedores de stacks modernas dependem de dependências open source do NPM. Isso faz todo sentido, pois os sites executam funções semelhantes e reescrever tudo do zero seria como reinventar a roda. O uso de bibliotecas pré-construídas acelera significativamente o desenvolvimento web.
O que muitos não percebem é que scripts NPM podem facilmente injetar payloads carregados no lado do cliente. Ferramentas de segurança focadas em ameaças à cadeia de suprimentos do NPM têm dificuldade em detectar essas injeções de forma eficaz, pois não têm visibilidade da atividade no lado do cliente, especialmente 100% do tempo e em tempo real.
Este excelente post viral no Medium de 2018 explica esse método de forma bastante ilustrativa.
Ferramentas de terceiros
Outro método comum de injeção é o sequestro de um script/ferramenta de terceiros adicionado ao site. Essas ferramentas podem ser de analytics, anúncios, testes A/B, widgets, scripts de rastreamento de redes sociais… Esses scripts frequentemente possuem uma árvore de dependências com diversas ferramentas open source incorporadas.
O ataque ao polyfill de junho de 2024 foi um grande exemplo desse método de ataque sendo utilizado na prática. Na verdade, não é tão difícil de executar. Os atacantes podem sequestrar um bucket S3, assumir o controle de um domínio expirado incorporado em sites, reivindicar uma URL S3 abandonada ou ingressar em um projeto open source e injetar silenciosamente alguma dependência de terceiros… as possibilidades são infinitas.
Injeções por meio de plataformas legadas
Mesmo que você utilize uma plataforma de e-commerce legada, frequentemente baseada em PHP, ficou comprovado ao longo do tempo que essas plataformas são altamente suscetíveis a injeções no lado do cliente por meio de CVEs conhecidas.
O nome "Magecart", um termo legado para ataques no lado do cliente, originou-se de injeções no lado do cliente no Magento para exfiltrar dados de titulares de cartão. No entanto, essa ameaça vai além do Magento. Somente em janeiro de 2025, detectamos mais de 15.000 sites afetados por novos ataques no lado do cliente no WordPress, evidenciando o risco crescente em diversas plataformas.
Nesse contexto, é importante reconhecer que JavaScript é utilizado como linguagem de programação no lado do cliente por 98,9% de todos os sites, tornando-o um alvo prioritário para exploração.
Portanto, sem segurança no lado do cliente, não há como descartar com confiança um ataque ou afirmar imunidade a ele.
Monitoramento em tempo real no lado do cliente para segurança de sites
A forma mais eficaz de proteger seu site e manter a conformidade com o PCI DSS é monitorar todo o ambiente no lado do cliente com uma ferramenta de monitoramento ativo e em tempo real. Essa abordagem vai além dos métodos tradicionais, como um crawler pontual, revisão manual de scripts em uma página de pagamento ou verificação do código front-end em busca de URLs maliciosas conhecidas.
Somente por meio de monitoramento contínuo é possível afirmar com confiança que o seu "site não está suscetível a ataques de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante".
Scripts no lado do cliente são dinâmicos e podem ser renderizados condicionalmente. Um agente malicioso pode injetar um payload que se ativa em condições específicas, como disparar apenas 1% das vezes, em um horário específico ou apenas para clientes de uma determinada região.
Por causa dessas técnicas evasivas e furtivas, uma abordagem baseada em scanner está longe de ser ideal para esse vetor, pois deixa pontos cegos demais… mas em alguns casos é tudo o que se pode fazer, por isso oferecemos um como solução de último recurso.
Você se qualifica para o SAQ A? – Gráfico
Com base em nossa interpretação, o questionário abaixo deve ajudá-lo a entender se você se qualifica para o SAQ A:
Embora a redação vaga deixe margem para interpretação, tornando difícil determinar a conformidade com clareza. Devido à falta de clareza, suspeitamos que se qualificar para o SAQ A com certeza seja desafiador, especialmente considerando a proximidade dessas mudanças com o prazo de conformidade de 31 de março de 2025.
Na prática, a maioria dos comerciantes teria dificuldade em responder "sim" com confiança à seguinte pergunta:
"O comerciante confirmou que seu site não está suscetível a ataques de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante."
Um possível resultado é que alguns comerciantes se apressem em adotar uma configuração de página de pagamento de terceiros, presumindo que isso aumenta a segurança e os qualifica para o SAQ A. Ainda assim, isso não elimina o risco de roubo de dados de cartão de crédito se os scripts do site forem comprometidos, conforme explicado com o método de sequestro de botão.
Outro resultado provável é que empresas simplesmente se candidatem ao SAQ A, confiando na autoavaliação e esperando pelo melhor sem tratar os riscos.
Riscos crescentes de ataques no lado do cliente
Considerando o cenário atual de ataques e a crescente complexidade dos navegadores modernos, as empresas chegam a um ponto de inflexão.
Como empresa de cibersegurança, sempre defenderemos a abordagem mais segura, aquela que protege ativamente tanto os clientes quanto as empresas.
Os ataques no lado do cliente estão em ascensão. Mais de 600.000 sites foram afetados em 2024 e, somente em janeiro de 2025, detectamos mais de 15.000 sites recém-impactados.
Sua responsabilidade: monitoramento contínuo
A melhor forma de garantir a conformidade com o PCI DSS é monitorar todo o seu ambiente no lado do cliente em tempo real. É sua responsabilidade se antecipar a essas ameaças e proteger seus clientes.
Para esclarecimentos ou dúvidas, entre em contato conosco hoje mesmo.
