Resumo: elegibilidade SAQ A e confirmação de ataques por scripts a todo o site
- Escopo de todo o site: A elegibilidade para o SAQ A pergunta agora se «o seu site» não é suscetível a ataques por scripts, e não apenas a página de pagamento. Como as SPAs e as PWAs mantêm os scripts ativos entre visualizações, uma tag carregada em qualquer página pode continuar ativa durante o checkout, pelo que um pixel de analytics na página inicial faz parte da sua história de elegibilidade SAQ A.
- Terceiros e quartos: As notas de aplicabilidade do PCI DSS 4.0.1 6.4.3 abrangem scripts do ambiente da entidade e de terceiros e quartas partes, motivo pelo qual um iframe hospedado, por si só, não o isenta. A cside deteta, monitoriza e mitiga riscos baseados em scripts, satisfazendo automaticamente os requisitos 6.4.3 e 11.6.1.
- As suas duas opções: Se conseguir provar que todo o seu site está livre de superfície de ataque baseada em scripts, o SAQ A está tecnicamente disponível. Caso contrário, tem de cumprir diretamente os requisitos 6.4.3 e 11.6.1, e a cside trata dessa conformidade enquanto continua a lançar integrações de terceiros.
Sem tempo? Veja o cside PCI Shield. Cobre tudo o que se segue numa única implementação.
O PCI SSC publicou um FAQ sobre a elegibilidade para o SAQ A para empresas, relativo a scripts no seu site, remetendo para os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1.
Esta atualização gerou confusão entre avaliadores, os nossos clientes e potenciais clientes.
O SAQ A destina-se a comerciantes que subcontratam totalmente o processamento de pagamentos a prestadores de serviços terceiros validados pelo PCI DSS. Nenhum dado de titular de cartão deve ser processado, armazenado ou transmitido através dos sistemas do comerciante
Um equívoco comum é pensar que usar um iframe ou um redirecionamento é suficiente. Não é.
O requisito fundamental é que o comerciante não pode carregar scripts que interajam com a página de pagamento. Se existirem scripts do domínio do comerciante ou de terceiros, o SAQ A não se aplica.
O papel dos scripts na conformidade com o SAQ A
- O formulário de pagamento tem de ser alojado e controlado inteiramente por um prestador em conformidade com o PCI.
- O comerciante não pode carregar scripts que modifiquem, monitorizem ou interajam de qualquer forma com o formulário de pagamento.
- Os únicos scripts permitidos são os geridos diretamente pelo prestador de pagamento validado.
Se a sua página de checkout incluir JavaScript, seja para analytics, melhorias de interface ou ferramentas de terceiros em geral, pode não se qualificar para o SAQ A. Mesmo que um script não toque nos campos de pagamento, pode ainda assim introduzir riscos, tais como:
- Ataques de form-jacking que capturam a informação introduzida pelo utilizador antes de esta chegar ao prestador de pagamento.
- Modificações não autorizadas do DOM que afetam o processo de pagamento.
- Ataques à cadeia de fornecimento que tiram partido de scripts de terceiros.
Uma frase gera debate
O comerciante confirmou que o seu site não é suscetível a ataques por scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante.
Isto foi acrescentado na atualização de janeiro relativa às empresas SAQ A.
Embora o PCI DSS se aplique a pagamentos e a páginas de pagamento, esta frase afirma claramente que todo o site não deve ser suscetível a ataques por scripts. Isto faz sentido. Se, por exemplo, um link que conduz a uma página de pagamento não estiver protegido ou monitorizado, uma injeção maliciosa de JavaScript de terceiros pode redirecionar o link e mesmo assim comprometer o utilizador.
Como isso deve ser feito não é claro, o que tem gerado confusão.
O PCI SSC remete para a versão mais recente da lista PCI DSS SAQ A para a lista completa de critérios de elegibilidade, mas esta não revela qualquer informação especificamente relacionada com a citação acima.
Na lista SAQ A, esta citação menciona diretamente scripts a monitorizar e/ou proteger:
No requisito 6.4.3 (página 7):
Todos os scripts da página de pagamento que são carregados e executados no navegador do consumidor são geridos da seguinte forma: é implementado um método para confirmar que cada script está autorizado. É implementado um método para garantir a integridade de cada script. É mantido um inventário de todos os scripts com justificação por escrito da razão pela qual cada um é necessário.
Nesta secção, mencionam-se apenas os scripts da página de pagamento. No entanto, nas notas de aplicabilidade abaixo, afirma-se:
Este requisito aplica-se a todos os scripts carregados a partir do ambiente da entidade e a scripts carregados por terceiros e quartas partes.
O «ambiente da entidade» esbate as fronteiras e abre a porta a que "o seu site" seja interpretado como um todo, tal como usado na frase que originou este debate.
Como os sites carregam scripts de forma dinâmica, um script de qualquer página pode persistir até ao checkout, podendo interferir nos pagamentos. Scripts de terceiros, mesmo que não relacionados ou presentes em páginas carregadas antes das páginas de pagamento, podem introduzir vulnerabilidades.
Em Single Page Apps (SPAs), os scripts persistem entre visualizações, o que significa que um script carregado em qualquer página pode continuar ativo durante o checkout. Da mesma forma, em Progressive Web Apps (PWAs), os scripts são executados de forma contínua à medida que os utilizadores navegam, o que aumenta o risco de interações não intencionais com o fluxo de pagamento.
No requisito 11.6.1 (página 16), notas de aplicabilidade:
A intenção deste requisito não é que uma entidade instale software nos sistemas ou navegadores dos seus consumidores, mas sim que a entidade utilize técnicas como as descritas em Exemplos na coluna de Orientação do PCI DSS (dos Requisitos e Procedimentos de Teste do PCI DSS) para prevenir e detetar atividades inesperadas de scripts.
Este caminho leva-nos a esses exemplos, encontrados na lista SAQ A, na página vi. Na secção "Não Aplicável", afirma-se:
O requisito não se aplica ao ambiente do comerciante. (Ver "Orientação para Requisitos Não Aplicáveis" abaixo para exemplos.) Todas as respostas nesta coluna requerem uma explicação de suporte no Anexo D deste SAQ.
Apenas um exemplo é encontrado em "Orientação para Requisitos Não Aplicáveis":
Os requisitos para proteger todos os suportes com dados de titulares de cartão (Requisitos 9.4.1 - 9.4.6) só se aplicam se o comerciante armazenar suportes em papel com dados de titulares de cartão; se não forem armazenados suportes em papel, o comerciante pode selecionar Não Aplicável para esses requisitos.
O "Anexo D" refere-se apenas a uma área onde a empresa que solicita o estatuto SAQ A, ou os avaliadores que avaliam essas empresas, podem registar as suas conclusões sobre este assunto.
Como estar em conformidade?
Para além de todos os outros requisitos do SAQ A, as empresas precisam de provar que o seu site está protegido contra ataques não autorizados baseados em scripts. Como provam isso ainda está em aberto. Na cside, criámos uma ferramenta que faz exatamente isso e permite às empresas cumprir os requisitos 6.4.3 e 11.6.1. Dependendo da configuração do site, no entanto, existem outras formas, desde que cumpram os restantes requisitos necessários para serem elegíveis para o SAQ A.
Precisa de cumprir os requisitos 6.4.3 e 11.6.1?
Se for elegível para o SAQ A, está tecnicamente isento dos requisitos 6.4.3 e 11.6.1.
No entanto, a elegibilidade para o SAQ A exige que confirme que todo o seu site não é suscetível a ataques baseados em scripts que possam comprometer o seu sistema de e-commerce. Embora o PCI SSC não defina explicitamente como validar isto, significa que deve garantir que:
- Não estão a ser executados scripts não autorizados no seu site.
- O seu processo de checkout está protegido contra manipulações (por exemplo, sequestro de redirecionamentos).
- Monitoriza e protege todas as integrações de terceiros.
Se não for elegível para o SAQ A, tem de cumprir os requisitos 6.4.3 e 11.6.1, uma vez que o seu ambiente se enquadra numa categoria de conformidade superior, onde são exigidos controlos de segurança adicionais.
E tudo isto aplica-se a todo o site, tal como estabelece a frase: "O comerciante confirmou que o seu site não é suscetível a ataques por scripts que possam afetar o(s) sistema(s) de e-commerce do comerciante."
Exemplos de não qualificação (SAQ A não permitido)
- Checkout construído à medida com chamadas diretas à API de um processador (exige SAQ D).
- Uma página de checkout que inclua scripts não protegidos que afetem os campos de pagamento.
- Utilizar campos alojados por terceiros, mas modificá-los via JavaScript.
- Não confirmar que o site não é suscetível a ataques por scripts que possam afetar os sistemas de e-commerce do comerciante.
Conclusão
O SAQ A oferece um caminho simplificado de conformidade para comerciantes que conseguem subcontratar totalmente o processamento de pagamentos, mas os esclarecimentos mais recentes deixam uma coisa clara: as responsabilidades de segurança não terminam na página de pagamento.
Embora os requisitos 6.4.3 e 11.6.1 não se apliquem a comerciantes SAQ A, garantir que todo o site está protegido contra ataques baseados em scripts é agora um requisito.
Isto significa que os comerciantes têm de adotar medidas de segurança proativas, não apenas para manter a conformidade, mas também para prevenir ameaças que possam comprometer o seu ecossistema de e-commerce. CSP, SRI e a monitorização da integridade dos scripts tendem a tornar-se expectativas de base, e não salvaguardas opcionais.
Com a cside, fica automaticamente em conformidade com os requisitos 6.4.3 e 11.6.1.
Ajudamos os comerciantes a detetar, monitorizar e mitigar riscos baseados em scripts. Se não tiver a certeza sobre a sua conformidade, podemos ajudá-lo a cumprir os requisitos e manter-se seguro.
Contacte-nos para proteger o seu ambiente client-side e manter a conformidade com o SAQ A com confiança.
