Resumo: o risco de proteger apenas as páginas de pagamento ao abrigo do PCI DSS
- Conformidade não é cobertura: O PCI DSS 4.0 só exige a monitorização de scripts nas páginas de pagamento, pelo que os fornecedores amostram alegremente 10% das sessões num punhado de URLs e chamam-lhe conformidade, deixando as páginas de início de sessão, KYC e conta expostas exatamente à mesma classe de scripts de terceiros.
- Cada página, cada sessão: Uma dependência alojada em CDN, comprometida, instalou quatro backdoors distintos em cerca de 1.000 sites em simultâneo; a cside posiciona-se entre o terceiro e o utilizador em todas as páginas, dá visibilidade total sobre scripts em 100% das sessões e frequentemente melhora o desempenho através de cache.
- Antes de aprovar: Antes da sua próxima aprovação do PCI DSS 6.4.3, decida se o XSS em páginas fora do pagamento, o sequestro de sessão de utilizadores autenticados por MFA e os ataques à cadeia de fornecimento em scripts auxiliares se enquadram no âmbito do seu programa de segurança do site.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
O PCI DSS 4.0 chegou. Até março de 2025, exige que os portais de pagamento tenham uma forma de autorizar cada script nas páginas de pagamento. Os sites precisam de manter um inventário de todos os scripts (pelo menos nesses portais de pagamento) e garantir a sua integridade. É agora necessário detetar e responder a modificações não autorizadas nas páginas de pagamento, incluindo alterações nos cabeçalhos HTTP e no conteúdo das páginas. As organizações devem verificar estas configurações pelo menos uma vez a cada sete dias ou conforme determinado pela sua análise de risco.
Leia aqui os requisitos completos.
Outra linha importante: o PCI DSS 4.0 incentiva agora a passagem de auditorias anuais para uma monitorização contínua da segurança, o que implica revisões e atualizações regulares dos componentes de sistema e do software.
Finalmente!
Neste momento, apenas os portais de pagamento são obrigados a ter um sistema para controlar o JavaScript de terceiros. É por isso que muitos dos nossos concorrentes (leia aqui o que pensamos deles) limitam os seus serviços a apenas algumas páginas. Alguns até fazem amostragem de sessões, protegendo apenas 10% das sessões.
Mas isso é um convite a problemas.
Porque deve proteger todas as páginas
Continua a existir risco de violação de dados se não proteger todas as páginas.
Agentes maliciosos podem usar scripts comprometidos noutras partes do seu site para sequestrar sessões de utilizadores. Isto poderia permitir-lhes fazer-se passar por utilizadores legítimos e realizar ações não autorizadas, potencialmente até contornando algumas formas de autenticação de dois fatores. Isso poderia, em última instância, contornar a proteção de scripts de terceiros nos portais de pagamento.
Outra área que ficaria exposta ao risco são as vulnerabilidades de cross-site scripting (XSS). Estas permitem que os atacantes injetem scripts maliciosos em páginas web visualizadas por outros utilizadores. Se apenas o portal de pagamento estiver protegido, outras páginas podem ser exploradas para executar ataques XSS, afetando na mesma os dados e a privacidade dos utilizadores.
Os ataques à cadeia de fornecimento também não ficam totalmente bloqueados. Os scripts de terceiros são um vetor comum para este tipo de ataques. Se os atacantes comprometerem um fornecedor ou um script utilizado em todo o seu site, concentrar as proteções apenas no portal de pagamento não impedirá a exploração através de outras integrações de terceiros. Um único script alojado em CDN, em cdn.csyndication[.]com, foi usado para instalar quatro backdoors distintos em 1.000 sites em simultâneo: uma única dependência comprometida, quatro pontos de entrada para o atacante.
As vulnerabilidades de Execução Remota de Código (RCE) e de Injeção de Comandos são riscos significativos que reforçam ainda mais a necessidade de proteger todas as páginas, e não apenas áreas críticas como os portais de pagamento. O RCE permite que os atacantes executem código arbitrário no seu servidor, podendo levar ao comprometimento total do sistema. Isto pode ocorrer através do tratamento inseguro de entradas de utilizador, como a avaliação de código carregado por utilizadores ou injetado através de campos de formulário.
As vulnerabilidades de Injeção de Comandos surgem quando entradas de utilizador inseguras são executadas como comandos de sistema, sobretudo através de entradas JavaScript incorretamente sanitizadas. Isto pode permitir que os atacantes manipulem ações do servidor ou acedam a bases de dados backend, levando a alterações de dados não autorizadas ou a roubo de dados.
Por fim, a engenharia social e o phishing são uma ameaça real. Os atacantes podem modificar conteúdo ou redirecionar utilizadores para sites maliciosos, induzindo-os a fornecer informações sensíveis.
Outras vulnerabilidades
Mesmo que os seus portais de pagamento estejam protegidos e a proteção funcione, as restantes páginas continuam a correr o risco de ser violadas.
Se isso acontecer, continua a correr o risco de perder a confiança dos utilizadores e pode enfrentar implicações legais ou regulatórias, sobretudo no que respeita a leis de proteção de dados como o RGPD ou o CCPA. Os prejuízos em coimas daí resultantes, ou os danos reputacionais, são difíceis de quantificar. Mas existem.
Por isso, faça-o bem, desde já
Tal como as regras do PCI DSS 4.0, também nós incentivamos qualquer proprietário de site a adotar a monitorização contínua da segurança. E esperamos ter demonstrado que fazê-lo em todas as páginas é a melhor forma de o conseguir.
O plano gratuito da cside torna o seu site compatível com o PCI DSS no que respeita a scripts de terceiros, e funciona em todas as páginas. A nossa abordagem é, no entanto, diferente da concorrência. O nosso script reescreve as origens de outros scripts no seu site para os proxyar através da cside e realiza algumas deteções do lado do browser. Isto coloca a cside no fluxo do pedido entre o utilizador e o script de terceiros sem latência adicional, e em alguns casos até melhora o desempenho através do cache de scripts estáticos.
Isto dá visibilidade total sobre os scripts servidos, em 100% das sessões e em todas as páginas, protegendo tanto a si como aos seus utilizadores.
Se quiser saber mais sobre como a nossa abordagem se diferencia, veja aqui.
