Resumo: Elegibilidade da autoatestação de scripts do SAQ A de janeiro de 2025
- A cilada da atestação: Remover as secções 6.4.3 e 11.6.1 do SAQ A não tornou a vida mais fácil. Substituiu-as por uma autoatestação de que "o seu site não é suscetível a ataques por scripts", e a maioria dos comerciantes não possui a experiência técnica necessária para avaliar com precisão se está exposta a ataques do lado do cliente.
- Escala dos ataques: O JavaScript é utilizado por 98,9% de todos os sites e, em janeiro de 2025, a cside detetou mais de 15 000 sites recentemente afetados num único mês, com mais de 600 000 sites atingidos em 2024. As verificações baseadas em scanners não detetam ataques furtivos que só se ativam 1% das vezes ou apenas numa região.
- Defender o sim: Se confia num redirecionamento ou num iframe e pensa estar protegido, os sequestros de botões e os formulários falsos sobrepostos continuam a funcionar. Se quer responder à atestação com certeza, a monitorização contínua do lado do cliente, como a da cside, é a única forma de defender o "sim".
Sem tempo? Veja o cside PCI Shield. Cobre tudo o que se segue numa única implementação.
O PCI SSC atualiza o SAQ A para o PCI DSS 4.0.1 - O que precisa de saber
Em 30 de janeiro de 2025, o PCI SSC (Payment Card Industry Security Standards Council) publicou uma atualização ao Questionário de Autoavaliação A (SAQ A) para o PCI DSS (Payment Card Industry Data Security Standard) v4.0.1.
O comunicado refere que, com base no feedback das partes interessadas, os requisitos 6.4.3 e 11.6.1 foram agora removidos do SAQ A. Em vez disso, os comerciantes devem confirmar:
"devem confirmar que o seu site não é suscetível a ataques de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante."
Este questionário aplica-se a comerciantes que terceirizam totalmente o processamento de pagamentos para fornecedores externos e que não manipulam nem armazenam dados de pagamento por conta própria.
No entanto, o novo requisito de autoatestação levantou preocupações, uma vez que muitas empresas não possuem a experiência necessária para avaliar com precisão a sua exposição a ataques do lado do cliente. Estas alterações criam novos desafios de conformidade relacionados com riscos de segurança do lado do cliente, deixando os comerciantes incertos quanto à sua elegibilidade e responsabilidades ao abrigo do SAQ A.
Como empresa especializada em segurança do lado do cliente, ajudamos os nossos clientes a cumprir ambos os requisitos, e este artigo explica o que a atualização significa na prática.
Novas responsabilidades para os comerciantes do SAQ A
O PCI SSC desenvolveu estes Questionários de Autoavaliação (SAQs) para rever as obrigações de conformidade dos comerciantes. Os comerciantes são responsáveis por avaliar se cumprem os requisitos descritos no questionário.
O SAQ A, concebido para os comerciantes menos vulneráveis, isenta-os 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.
No entanto, um novo requisito do SAQ A é que os comerciantes devem autoatestar que "o seu site não é suscetível a ataques de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante".
Contudo, muitos comerciantes não possuem a experiência técnica necessária para avaliar com precisão se estão suscetíveis a ataques do lado do cliente.
Dado que 98,9% dos sites utilizam atualmente JavaScript do lado do cliente, para muitos comerciantes este novo requisito pode significar que deixam de ser elegíveis para o SAQ A.
Necessidade de mais clareza
O PCI SSC disponibiliza uma variedade de Questionários de Autoavaliação. Ainda assim, o documento "SAQ Instructions and Guidelines" ainda não foi atualizado para refletir estas alterações.
Dada a alteração significativa no âmbito, consideramos necessária uma atualização para garantir que os comerciantes compreendem plenamente as suas obrigações de conformidade.
O que é um SAQ A e como se candidatar
Como o PCI SSC o define:
"Os comerciantes do SAQ A podem ser comerciantes de e-commerce ou de encomendas por correio/telefone (sem apresentação do cartão), e não armazenam, processam ou transmitem quaisquer dados do titular do cartão em formato eletrónico nos seus sistemas ou instalações."
Note-se que os critérios de elegibilidade atualizados para o SAQ A foram alterados para: "comerciantes com funções de dados da conta totalmente terceirizadas a terceiros validados e em conformidade com o PCI DSS, onde o comerciante retém apenas relatórios em papel ou recibos com dados da conta."
E agora também exige que o comerciante: "confirme que o seu site não é 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 fornecedor externo para processar pagamentos, os comerciantes não têm controlo sobre se ocorre um ataque de script do lado do cliente na página de pagamento do terceiro. A monitorização é da responsabilidade do processador de pagamentos.
Relativamente ao segundo grupo, as declarações sobre iframes são vagas e criam uma narrativa enganadora. Ao utilizar um iframe, é praticamente impossível eliminar por completo o risco de ataques do lado do cliente.
Para confirmar que o site de um comerciante não é suscetível a ataques do lado do cliente, vamos explorar quando ocorrem esses ataques e o que é considerado um ataque do lado do cliente.
A documentação do PCI SSC deixou de utilizar o termo "skimming", por ser vago e aberto a interpretações, passando a usar o termo mais técnico "ataques do lado do cliente" ou "ataques de scripts".
Definimos "ataques do 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 utilizador diretamente a partir do seu navegador.
Como ocorrem os ataques do lado do cliente
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 fornecedor de pagamentos para introduzir os dados do seu cartão de pagamento. Depois de a transação ser concluída, é reenviado para o site do comerciante.
- Formulário de pagamento incorporado: os dados de pagamento são recolhidos através de um iframe ou widget, incorporando um 'mini navegador' de terceiros dentro do site do comerciante para apresentar o formulário do fornecedor de pagamentos.
- Formulário concebido e gerido pelo comerciante: o formulário de pagamento é concebido e gerido pelo comerciante e transmite os dados de pagamento ao processador via API.
Cada categoria tem as suas próprias implicações de segurança, e compreender onde e que riscos do lado do cliente se aplicam é essencial para a conformidade.
Riscos de segurança nas páginas de redirecionamento
As páginas de redirecionamento podem parecer seguras, mas os comerciantes não têm controlo 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 idêntica à real, roubando os seus dados de pagamento no processo. Mesmo ao utilizar um fornecedor terceiro de confiança para o pagamento, os riscos do lado do cliente permanecem. Scripts maliciosos podem alterar funções de clique, modificando o fluxo de checkout sem serem detetados. Utilizar um fornecedor de pagamentos terceiro não elimina o risco de ataques do lado do cliente; em vez disso, 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 está a fazer compras online e clica no botão "pagar agora" abaixo.
.pay-button:active { background-color: #166534; }
Pagar AgoraAo ver essa página, pensaria que algo estava errado?
Esta página demorou 5 minutos a criar. Embora não seja possível introduzir realmente os seus dados de pagamento nesta página de demonstração, com mais dois minutos de trabalho eu poderia capturar quaisquer dados que introduzisse nesse campo de pagamento e usá-los para pagar ao comerciante real. Isso significa que receberia a confirmação da sua encomenda e tudo correria como esperado, enquanto, ao mesmo tempo, as informações do cartão de crédito seriam roubadas.
Os atacantes podem até inserir dinamicamente o logótipo do comerciante, fazendo com que a página falsa pareça idêntica ao site original. Para tornar o ataque ainda mais furtivo, podem redirecionar apenas uma determinada percentagem de visitantes, limitá-lo a determinadas horas do dia ou regiões, ou evitar os endereços IP do próprio comerciante, permitindo que o ataque passe despercebido durante muito tempo.
Ao sequestrar o clique no botão que redireciona o utilizador para a página de pagamento, o processador de pagamentos não poderia ter evitado o ataque. O comerciante foi a única parte, neste exemplo, que poderia ter tomado medidas para o impedir.
Riscos de segurança nos formulários de pagamento incorporados
Se o seu negócio se enquadra na categoria 2, ou seja, incorpora um iframe no seu site para apresentar o formulário de um fornecedor de pagamentos terceiro, o seu processo de checkout continua vulnerável a ataques do lado do cliente.
Um script malicioso pode intercetar muito facilmente os dados do titular do cartão de várias formas:
- Renderizar outro iframe sobre o iframe real do fornecedor de pagamentos.
- Ocultar o iframe real e substituí-lo por um campo de introdução falso.
Outras técnicas conseguem capturar informações sensíveis de forma igualmente invisível.
Leitura relacionada: o nosso guia de conformidade com o PCI DSS 6.4.3 e 11.6.1 · como cumprir o PCI DSS 6.4.3
Qualquer JavaScript malicioso no site de um comerciante teria controlo total sobre a página e poderia executar estes ataques. A única forma de eliminar totalmente este 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, uma vez que a maioria dos fornecedores de pagamento (e ferramentas críticas comuns como chatbots, análises de sites, relatórios de erros, etc.) necessita de JavaScript dinâmico do lado do cliente para funcionar corretamente.
Manter estes controlos e, ao mesmo tempo, garantir que a produção continua a funcionar corretamente é um desafio significativo, especialmente com frameworks e plataformas como React, Vue, Magento, Drupal e WooCommerce. Alcançar este nível de segurança manualmente, sem uma solução dedicada, é praticamente impossível sem um esforço enorme e frágil.
Riscos de segurança nos formulários concebidos e geridos pelos comerciantes
Se o seu negócio se enquadra na categoria 3, em que criou o seu próprio componente de pagamento, o seu processo de checkout é ainda mais vulnerável. Estes formulários de pagamento geridos pelo comerciante apresentam os mesmos riscos de sequestro que os iframes incorporados, e ainda mais, uma vez que outros scripts em execução no site podem registar as teclas premidas (keylogging) para capturar os dados de pagamento.
E como são injetados os ataques do lado do cliente?
Frameworks web modernas
As frameworks modernas de aplicações web de página única, como o React, tornaram-se o padrão. Estas frameworks geram "webapps de página única" porque dependem de JavaScript do lado do cliente para atualizar dinamicamente a página, permitindo um carregamento mais rápido e uma navegação fluida entre páginas.
No entanto, todo o propósito destas frameworks é não recarregar a página. Como resultado, os scripts adicionados a uma parte específica do site podem executar-se em qualquer página, a menos que seja acionada uma atualização completa antes da navegação. Isto introduz riscos de segurança, porque os scripts maliciosos podem permanecer ativos quando o utilizador 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 durante muitos anos.
Além disso, os programadores de stacks modernas dependem de dependências open source do NPM. Isso faz todo o sentido, uma vez que os sites desempenham funções semelhantes e reescrever tudo de raiz seria como reinventar a roda. A utilização de bibliotecas pré-construídas acelera significativamente o desenvolvimento web.
Os scripts NPM podem facilmente injetar payloads obtidos do lado do cliente. As ferramentas de segurança focadas em ameaças à cadeia de fornecimento do NPM têm dificuldade em detetar estas injeções de forma eficaz, uma vez que não têm visibilidade sobre a atividade do lado do cliente, especialmente em tempo real e a toda a hora.
Este post viral no Medium de 2018 explica este método de forma divertida.
Ferramentas de terceiros
Outro método comum de injeção é o sequestro de um script ou ferramenta de terceiros adicionado ao site. Podem ser ferramentas de análise, publicidade, testes A/B, widgets ou scripts de monitorização de redes sociais. Estes scripts têm frequentemente uma árvore de dependências com muitas ferramentas open source incorporadas.
O ataque ao polyfill de junho de 2024 foi um exemplo importante deste método de ataque a ser utilizado na prática. Não é assim tão difícil de concretizar. Os atacantes podem sequestrar um bucket S3, apoderar-se de um domínio expirado incorporado em sites, reivindicar um URL S3 abandonado ou juntar-se a um projeto open source e injetar discretamente uma dependência de terceiros. As opções são infinitas.
Injeções através de plataformas legadas
Mesmo que utilize uma plataforma de comércio legada, frequentemente baseada em PHP, ficou provado ao longo do tempo que estas são altamente suscetíveis a injeções do lado do cliente através de CVEs comuns.
O nome "Magecart", um termo legado para ataques do lado do cliente, teve origem em injeções do lado do cliente no Magento, utilizadas para roubar dados dos titulares de cartão. Esta ameaça estende-se agora para além do Magento: só em janeiro de 2025, detetámos mais de 15 000 sites em WordPress afetados por novos ataques do lado do cliente.
O JavaScript é utilizado como linguagem de programação do lado do cliente em 98,9% de todos os sites, o que o torna um alvo privilegiado para exploração.
Por conseguinte, sem segurança do lado do cliente, não há forma de descartar com confiança um ataque ou de afirmar imunidade a ele.
Monitorização do lado do cliente em tempo real para a segurança de sites
A forma mais eficaz de proteger o seu site e manter a conformidade com o PCI DSS é monitorizar todo o ambiente do lado do cliente com uma ferramenta ativa e em tempo real. Esta abordagem vai além dos métodos tradicionais, como crawlers pontuais, revisões manuais de scripts numa página de pagamento ou a verificação do código front-end em busca de URLs maliciosos conhecidos.
Só através de uma monitorização contínua se pode afirmar com confiança que o seu "site não é suscetível a ataques de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante".
Os scripts do lado do cliente são dinâmicos e podem ser renderizados condicionalmente. Um agente malicioso pode injetar um payload malicioso que se ativa em condições específicas, como acionar-se apenas 1% das vezes, numa determinada hora do dia, ou apenas para clientes de uma região específica.
Devido a estas técnicas evasivas e furtivas, uma abordagem baseada em scanners está longe de ser ideal para este vetor, uma vez que deixa demasiados pontos cegos. Em alguns casos, no entanto, é tudo o que se pode fazer, por isso oferecemos um como solução de último recurso.
Qualifica-se para o SAQ A - Gráfico
Com base na nossa interpretação, o questionário abaixo deve ajudá-lo a perceber se se qualifica para o SAQ A:
Embora a redação vaga deixe margem para interpretação, o que torna difícil determinar a conformidade com clareza. Devido a essa falta de clareza, suspeitamos que qualificar-se para o SAQ A com certeza seja um desafio, especialmente dada a proximidade destas alterações com o prazo de conformidade de 31 de março de 2025.
Na prática, a maioria dos comerciantes teria dificuldade em responder com confiança "sim" à pergunta:
"O comerciante confirmou que o seu site não é suscetível a ataques de scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante."
Um resultado possível é que alguns comerciantes se apressem a adotar uma configuração de página de pagamento de terceiros, presumindo que isso melhora a segurança e os qualifica para o SAQ A. Ainda assim, isso não elimina o risco de roubo do cartão de crédito se os scripts do seu site forem comprometidos, como explicado com o método de sequestro de botões.
Outro resultado provável é que as empresas simplesmente se candidatem ao SAQ A, confiando afinal na autoavaliação, e esperando pelo melhor sem resolver os riscos.
Riscos crescentes dos ataques do lado do cliente
Os ataques do lado do cliente estão a aumentar a par da crescente complexidade dos navegadores modernos.
Como empresa de segurança do lado do cliente, recomendamos a abordagem mais protetora disponível, uma que salvaguarda tanto os clientes como os comerciantes.
Os ataques do lado do cliente estão a aumentar. Mais de 600 000 sites foram afetados em 2024 e, só em janeiro de 2025, detetámos mais de 15 000 sites recentemente afetados.
A sua responsabilidade: monitorização contínua
A melhor forma de garantir a conformidade com o PCI DSS é monitorizar todo o seu ambiente do lado do cliente em tempo real. É da sua responsabilidade manter-se à frente destas ameaças e proteger os seus clientes.
Para quaisquer esclarecimentos ou dúvidas, contacte-nos hoje mesmo.
