Os Qualified Security Assessors do PCI DSS já enfrentam a enorme tarefa de dominar mais de 397 páginas de conteúdo técnico denso. Para piorar, muitos comerciantes correm atrás da solução mais barata que os faça passar na avaliação, empurrando os limites do que é minimamente aceitável. Embora essas soluções pareçam marcar todas as caixas à primeira vista, muitas delas deixam os titulares de cartão completamente expostos a ataques client-side. Em alguns casos, essas soluções vivem na zona cinzenta de redações vagas, mas não atendem de fato aos padrões de conformidade.
Este guia ajuda os QSAs a identificar esses sinais de alerta. Escrevemos com base na nossa própria experiência trabalhando com assessores e nas avaliações de engenharia que realizamos ao desenvolver uma solução PCI para nossos clientes.
Checklist Resumido para QSAs:
Para atender aos requisitos 6.4.3 e 11.6.1, o comerciante deve ser capaz de demonstrar (seja por solução interna ou via fornecedor):
- Um mecanismo para controlar os scripts da página e a capacidade de bloqueá-los. CSP, SRI ou um script client-side podem fazer isso. Mas um crawler sozinho não consegue.
- O conteúdo dos scripts pode ser verificado em busca de indicadores de intenção maliciosa. Para isso ser possível, a solução deve ter a capacidade de exibir o conteúdo dos scripts. Sem capacidade de exibir o conteúdo do script = sem capacidade de verificar a integridade do script. Sem evidência = sem conformidade.
- Um inventário de todos os scripts (inline, first-party, third-party e dependências dos scripts) deve ser mantido com justificativa técnica ou de negócio.
- Os cabeçalhos de segurança das páginas de pagamento devem ser monitorados e exibidos pelo menos semanalmente.
- Um mecanismo deve estar em vigor para alertar sobre a remoção de qualquer medida de segurança client-side.
- O conteúdo dos scripts deve ser monitorado ativamente e alertas devem ser disparados em caso de alterações.
A solução de um comerciante falharia se:
- Não tiver um script client-side ou um CSP ou um SRI capaz de bloquear o carregamento de scripts (falha no atendimento do 6.4.3)
- For puramente um crawler sem nenhum nível de ajuste de código na página (falha no atendimento do 6.4.3)
- Verificar apenas as URLs dos scripts, mas não monitorar o conteúdo dos scripts (falha no 11.6.1)
- Não enviar alertas quando cabeçalhos de segurança forem removidos ou alterados (falha no 11.6.1)
- Não rastrear e exibir os cabeçalhos de segurança pelo menos semanalmente (falha no 11.6.1)
Por que esses requisitos existem:
Os requisitos 6.4.3 e 11.6.1 dizem respeito a ataques client-side — ataques que se executam no ambiente da aplicação no dispositivo do usuário, mas que ocorrem como resultado das suas dependências enquanto comerciante. Esse escopo foi adicionado no PCI DSS v4. As bandeiras de cartão sinalizaram que uma quantidade significativa de roubo de Dados do Titular do Cartão (CHD) acontece no lado do cliente, fora do campo de visão de outras medidas de segurança. Um Web Application Firewall não tem impacto sobre execuções client-side, especialmente as de terceiros. Por isso, esse aumento de escopo foi necessário. Muitos outros frameworks de conformidade estão seguindo o mesmo caminho, expandindo os requisitos relacionados à segurança da cadeia de suprimentos para incluir execuções client-side.
Os Requisitos do PCI se Aplicam a Single-page Applications (SPAs)?
A especificação do PCI DSS não diferenciou entre tecnologias de aplicações web de página única ou aplicações web renderizadas no servidor. Isso pode gerar confusão, pois alguns requisitos podem parecer inaplicáveis ou tecnicamente inviáveis sem monitorar toda a single-page application, mas as ações de segurança solicitadas se aplicam sim a single-page applications. Em muitos aspectos, as SPAs contribuíram significativamente para a necessidade de requisitos de segurança mais rígidos, ao aumentar a quantidade de código que é executado no lado do cliente.
Veja: Qual é a diferença entre aplicações web renderizadas no servidor e single-page applications
Escopo do 6.4.3 & 11.6.1:
A especificação do PCI afirma que "Este requisito se aplica a todos os scripts carregados do ambiente da entidade e scripts carregados de terceiros e quartos". Portanto, qualquer menção a 'script' inclui scripts da mesma origem (1st party), terceiros e sub-requisições desses terceiros.
Muitas ferramentas tradicionais não monitoram scripts client-side da mesma origem ou scripts injetados inline. Em outras palavras, essas ferramentas não monitoram scripts first-party nem os trechos de código inseridos diretamente na página (por exemplo, tags de analytics). Isso é um problema, pois ataques client-side frequentemente se originam por meio de scripts da mesma origem.
6.4.3:
O requisito estabelece:
"Todos os scripts da página de pagamento que são carregados e executados no navegador do consumidor são gerenciados da seguinte forma:"
1. "Um método é implementado para confirmar que cada script está autorizado."
Isso significa que qualquer script não autorizado deve ser impedido de ser servido. Existem apenas 2 formas de fazer isso:
- **Implementando CSP de scripts ou SRIs:**Certifique-se de que as Content Security Policies (CSP) sejam restritivas e estejam em modo de bloqueio. Por design, o CSP é um mecanismo para confiar em fontes, não nos scripts em si. São coisas fundamentalmente diferentes. Se uma fonte confiável for comprometida, scripts maliciosos podem passar sem nenhuma medida de segurança.
A Subresource Integrity (SRI) opera no nível do script e valida o payload real. No entanto, o SRI nem sempre é uma opção prática para scripts dinâmicos que mudam com frequência no lado do cliente.
- **Usando um script client-side:**Um script client-side que carrega antes de todos os outros scripts pode ajustar ou desmontar scripts. Ele pode impedir que scripts não autorizados sejam executados parcialmente ou por completo.
Se um comerciante não tiver CSP, SRI ou um script client-side na página para impedir o carregamento de scripts não autorizados, o requisito 6.4.3 não é atendido.
Importante: uma solução baseada apenas em crawler sem CSP não atende aos requisitos do PCI. Existem vários fornecedores no mercado oferecendo crawlers que não atendem a esse requisito.
2. "Um método é implementado para garantir a integridade de cada script."
Isso significa que cada script deve ser monitorado. No requisito 11.6.1, é explicado com mais detalhes que isso inclui o conteúdo dos scripts. Portanto, uma solução de segurança que atenda ao 6.4.3 e ao 11.6.1 deve ser capaz de exibir o conteúdo dos scripts que foram servidos ao usuário.
O local onde a solução é executada importa: Soluções que rodam externamente não podem garantir que o script que analisaram é o que de fato é servido aos usuários finais. Agentes maliciosos são conhecidos por identificar os endereços IP de provedores de nuvem usados por crawlers e excluir scripts maliciosos de serem servidos a eles. Portanto, não está claro se o requisito pode ser atendido por qualquer solução que não esteja presente na aplicação em tempo de execução. O CSP sozinho não consegue verificar a integridade do script, pois não inspeciona o conteúdo do script. O SRI, por outro lado, valida o conteúdo dos scripts por meio de um hash.
**URLs de scripts + Feeds de ameaças:**Algumas soluções alegam conformidade verificando URLs de scripts em feeds de ameaças, mas isso apenas verifica o nome do arquivo e não o conteúdo. Como o 11.6.1 exige especificamente o monitoramento do payload real do script, essas abordagens ficam aquém da conformidade. É o mesmo motivo pelo qual um antivírus não se limita a verificar nomes de arquivos — ele inspeciona o que está dentro.
Como regra geral: se uma solução não exibe o conteúdo dos scripts, ela não atende aos requisitos de monitoramento de integridade.
Teste de Validação: Para entender se uma solução consegue verificar a integridade dos scripts, recomenda-se executar um teste implementando um script 'malicioso' de exemplo em um ambiente de staging.
3. "Um inventário de todos os scripts é mantido com justificativa técnica ou de negócio por escrito sobre por que cada um é necessário."
Os comerciantes podem usar planilhas ou dashboards fornecidos por fornecedores para atender a esse requisito. IA é frequentemente usada para redigir as justificativas. Algumas soluções não oferecem isso nativamente; nesse caso, uma planilha pode ser utilizada. No entanto, é importante que essa planilha esteja atualizada. Uma exportação do dashboard do Google Tag Manager não é suficiente, pois a própria aplicação pode ter scripts client-side injetados fora do Google Tag Manager.
Inventários desatualizados ou incompletos: Recomenda-se que o QSA verifique a solução em questão para confirmar que todos os scripts estão no inventário e que ele está atualizado.
**Usando uma 'abordagem sem agente':**A documentação do PCI DSS v4 fornece orientações e sugere o uso de CSP, SRI ou um script proprietário ou sistema de gerenciamento de tags que possa impedir a execução de scripts maliciosos. Não há menção a uma ferramenta de observabilidade passiva como scanner, crawler ou agente. O requisito de impedir o carregamento de um script malicioso não pode ser atendido sem adicionar um script ou cabeçalho CSP a uma página web.
11.6.1
Um mecanismo de detecção de alterações e adulterações é implantado da seguinte forma:
1. "Para alertar o pessoal sobre modificações não autorizadas (incluindo indicadores de comprometimento, alterações, adições e exclusões) nos cabeçalhos HTTP com impacto na segurança e no conteúdo dos scripts das páginas de pagamento conforme recebidos pelo navegador do consumidor."
Este requisito diz respeito ao monitoramento de todos os cabeçalhos de segurança do lado do servidor que podem ser ajustados no período que antecede um ataque, bem como ao requisito de monitorar os payloads dos scripts.
O payload do script deve ser analisado e alertas devem ser enviados em tempo hábil em caso de comprometimento. Claro, um alerta sem indicadores do motivo pelo qual foi disparado é inútil; portanto, para ser acionável, o conteúdo dos scripts deve ser armazenado e exibido para fins forenses.
Exemplos de alterações que exigem alertas: "Código ou técnicas de skimming de e-commerce não podem ser adicionados às páginas de pagamento conforme recebidas pelo navegador do consumidor sem que um alerta seja gerado em tempo hábil. Medidas anti-skimming não podem ser removidas das páginas de pagamento sem que um alerta imediato seja gerado."
Também é necessário ter um mecanismo para monitorar qualquer adulteração à própria solução de segurança. Se ela for removida, isso deve resultar em um alerta.
Para atender a esses requisitos, a lista de cabeçalhos de segurança abaixo deve ser monitorada:
| Cabeçalho de Segurança | Descrição |
|---|---|
| Content Security Policy | Também conhecido como cabeçalho CSP. |
| Content Security Policy Report Only | O cabeçalho CSP em modo somente de relatório, sem bloqueio. |
| Report To | Endpoint de relatório seguindo a especificação legada. |
| Reporting Endpoints | Endpoint de relatório alternativo seguindo a especificação mais recente. |
| Strict Transport Security (HSTS) | Restringe o navegador a se conectar apenas via HTTPS. |
| X-Frame-Options | Permite definir se iframes podem ser injetados na página web. |
| Cross-Origin Resource Policy (CORP) | Permite que a página web defina quais recursos podem ser carregados e de onde. Relacionado ao CORS e à Same-Origin Policy. |
| Cross-Origin Opener Policy | Permite que a página web defina como o navegador deve interagir com diferentes contextos, como abas, iframes e janelas. |
| Cross-Origin Embedder Policy | Permite controlar quais componentes de origem cruzada o navegador pode carregar. |
| Permissions Policy | Permite definir quais APIs de dispositivo podem ser acessadas pelas aplicações web e suas dependências. |
| X-Content-Type-Options | Força o navegador a verificar rigorosamente os tipos de conteúdo. Caso contrário, navegadores poderiam permitir injeções maliciosas por meio de tipos de conteúdo não intencionais. Um método muito comum usado em execuções client-side e ataques do tipo MIME. |
| X-Permitted-Cross-Domain-Policies | É um cabeçalho de segurança mais legado que define de quais domínios o Flash Player e leitores de PDF tinham permissão para buscar conteúdo. |
| Referrer Policy | Curiosidade: há um erro de digitação na especificação HTTP para 'referer'. Este cabeçalho permite definir quanta informação é enviada pelo referrer, página anterior ou página pai. |
| X-XSS-Protection | É um cabeçalho de segurança legado para habilitar ou desabilitar os recursos nativos de detecção de XSS do navegador. |
2. "O mecanismo é configurado para avaliar os cabeçalhos HTTP recebidos e as páginas de pagamento"
Isso reforça os pontos mencionados acima sobre o monitoramento de todos os cabeçalhos HTTP com impacto na segurança na página de pagamento.
3. "As funções do mecanismo são executadas da seguinte forma: Pelo menos semanalmente OU Periodicamente (na frequência definida na análise de risco direcionada da entidade, realizada de acordo com todos os elementos especificados no Requisito 12.3.1)."
Esta seção indica que essas verificações devem ocorrer pelo menos semanalmente ou no prazo determinado pelo 12.3.1. A amostragem pode ser permitida no que diz respeito a cabeçalhos HTTP e conteúdo de scripts, mas pelo menos semanalmente esses devem ser revisados. Uma semana é muito tempo; recomenda-se orientar os comerciantes em direção a uma perspectiva de segurança mais proativa.
AOCs e ROCs para Fornecedores
Fornecedores que oferecem soluções de segurança para o 6.4.3 e o 11.6.1 não são TPSP no contexto de pagamentos (Third-Party Service Provider) e não exigem nenhum nível de SAQ, AOC ou ROC sobre seu próprio produto por parte de um QSA. Alguns fornecedores maiores possuem essas certificações para outras partes de seus negócios e, às vezes, listam suas ferramentas relacionadas ao PCI nesses relatórios. Isso não significa necessariamente que essas ferramentas foram testadas ou validadas. O comerciante ainda é o principal responsável por comprovar a conformidade com o PCI DSS. Alguns fornecedores pagam QSAs para revisar suas soluções e publicar whitepapers, mas mesmo isso não garante totalmente a conformidade para comerciantes individuais.
Aplicações web renderizadas no servidor vs. single-page applications:
Aplicações renderizadas no servidor tradicionais carregam uma nova página do servidor toda vez que você clica em um elemento. Por exemplo: um portal de internet banking onde cada clique (por exemplo, verificar saldo) recarrega uma página completamente nova dos servidores do banco.
Single-page applications (SPAs), por outro lado, carregam uma vez e dependem de JavaScript para atualizar o conteúdo dinamicamente. Por exemplo: um checkout de e-commerce construído em React onde a página nunca recarrega completamente; em vez disso, formulários, detalhes de produtos e campos de pagamento são atualizados dinamicamente no navegador. Houve um crescimento das single-page applications à medida que mais sites são construídos com frameworks de desenvolvimento web como React, Angular e Vue.
