Atenção, varejistas on-line e fornecedores de comércio eletrônico: quando se trata de proteger dados do lado do cliente e pagamentos on-line contra skimming digital e ataques Magecart, há uma nova autoridade na área.
Em março de 2022, o Conselho de Padrões de Segurança da Indústria de Cartões de Pagamento (PCI) lançou uma versão revisada de seu Padrão de Segurança de Dados, PCI DSS v4.0, que define os requisitos mínimos de segurança que os comerciantes devem cumprir ao armazenar, processar e transmitir dados de titulares de cartões. Os requisitos revisados incluem diversas melhorias para garantir transações on-line seguras e proteger consumidores, empresas e emissores de cartões durante transações comerciais on-line.
Os novos requisitos enfatizam a necessidade de monitorar e gerenciar bibliotecas JavaScript de terceiros executadas no navegador e incorporadas a sites de comércio eletrônico para oferecer funcionalidades prontas para uso, como iFrames de processamento de pagamentos, chatbots, publicidade, botões de compartilhamento em redes sociais e scripts de rastreamento. Embora essas bibliotecas JavaScript ajudem as empresas a acelerar o desenvolvimento de sites, elas também criam um amplo vetor de ameaças para os cibercriminosos, pois esses scripts podem ser facilmente comprometidos por meio de ataques de skimming digital e Magecart para roubar credenciais, dados de cartões de crédito e outras informações de identificação pessoal (PII).
Embora essas violações sejam claramente prejudiciais aos consumidores vítimas de fraude, elas também afetam negativamente sua empresa, pois podem resultar em violações de conformidade, perda de receita, queda no preço das ações, avaliações negativas nas redes sociais e danos ao valor da marca.
Embora a conformidade com os novos requisitos do PCI DSS 4.0 só seja obrigatória a partir de 2025, não espere! Os tipos de ataque que esses requisitos visam combater já estão acontecendo. Este é o momento de proteger a reputação da sua empresa e seus clientes contra ataques e fraudes, implementando as proteções reforçadas o mais rápido possível.
Quais são os perigos dos ataques do lado do cliente?
Há pouco tempo, as aplicações web comerciais eram desenvolvidas como um bloco monolítico de código, disponibilizado por um servidor web local. No entanto, as aplicações web modernas de hoje são muito diferentes e, muitas vezes, são desenvolvidas por meio da combinação de bibliotecas JavaScript de terceiros, com grande parte do processamento ocorrendo no lado do cliente, no navegador do usuário. Estima-se que entre 70% e 80% de uma página web típica seja composta por bibliotecas de terceiros, e alguns desses scripts contêm código de outro conjunto de scripts de terceiros. Essa longa cadeia de dependências de código faz com que as empresas tenham pouca visibilidade ou controle sobre o código que realmente está sendo executado em seus sites.
Os agentes de ameaças sabem que, devido à abrangência e à escala dessas dependências de enésimos terceiros, as organizações têm dificuldade para gerenciar, monitorar e proteger adequadamente o código executado em seus ambientes e não conseguem sequer detectar quando ele foi alterado ou explorado. Essa falta de visibilidade abre uma brecha para que cibercriminosos injetem scripts maliciosos em páginas legítimas ou no código de aplicações web e realizem ataques para interceptar, manipular e sequestrar sessões de usuários. Assim, eles conseguem capturar dados pessoais e informações de pagamento, assumir o controle de sites e desfigurá-los, exibir conteúdo falso, criar novos formulários ou alterar formulários legítimos — ações que podem preparar o terreno para fraudes e invasões de contas.
O que o PCI DSS v4.0 exige
A norma revisada identifica especificamente as melhorias na segurança da Web no lado do cliente como essenciais para qualquer empresa que aceite pagamentos on-line. A norma determina que todos os scripts das páginas de pagamento carregados e executados no navegador do consumidor sejam gerenciados de forma abrangente. Especificamente, o novo requisito 6.4.3 exige que os fornecedores de comércio eletrônico implementem:
- Um método para confirmar que cada script está autorizado
- Um método para garantir a integridade de cada script
- Um inventário de todos os scripts, com justificativa por escrito sobre a necessidade de cada um
O novo padrão exige que os comerciantes analisem suas políticas e seus procedimentos para verificar se há processos definidos para gerenciar todos os scripts das páginas de pagamento que são carregados e executados no navegador do consumidor. Eles também devem entrevistar os responsáveis e analisar os registros de inventário e as configurações do sistema para verificar se todos os scripts das páginas de pagamento que são carregados e executados no navegador do consumidor são gerenciados de acordo com todos os elementos especificados neste requisito.
Além disso, a seção 11.6 da norma revisada exige que alterações não autorizadas nas páginas de pagamento sejam detectadas e tratadas. Isso requer um mecanismo de detecção de alterações e adulterações que alerte a equipe sobre modificações não autorizadas nos cabeçalhos HTTP e no conteúdo das páginas de pagamento conforme recebidos pelo navegador do consumidor. As configurações devem ser examinadas pelo menos uma vez a cada sete dias ou na frequência definida na avaliação de análise de riscos da organização.
Atender a esses requisitos por meio de soluções manuais ou legadas é caro e exige muitos recursos. Como os scripts de formulários de pagamento são executados no lado do cliente, os comerciantes têm pouca visibilidade sobre seu comportamento, o que facilita que códigos maliciosos não sejam detectados. Além disso, os comerciantes têm pouco controle sobre códigos de terceiros, como as bibliotecas JavaScript dinâmicas que viabilizam recursos de páginas da web, como processadores de pagamento, formulários de consentimento de cookies, chatbots ou rastreadores de anúncios, pois esses códigos são atualizados e alterados com frequência, muitas vezes sem o conhecimento do comerciante.
As técnicas de detecção existentes, como a Integridade de Sub-recursos (SRI), que realiza verificações de integridade para garantir que os scripts não tenham sido adulterados, e a Política de Segurança de Conteúdo (CSP), que limita os locais de onde os navegadores podem carregar scripts e para onde podem enviar dados, já não são suficientes para proteger as aplicações web atuais, que estão em constante mudança.
Ajude sua empresa a entrar em conformidade com o PCI DSS v4.0 o quanto antes
Não há motivo para esperar até 2025 para cumprir os requisitos de segurança exigidos pelo PCI DSS v4.0. Tome medidas agora para proteger sua empresa contra ataques e seus clientes contra fraudes e invasões de contas.
F5 Distributed Cloud Client-Side Defense pode ajudar você imediatamente a atender aos novos requisitos do PCI DSS v4.0 e a se proteger contra Magecart, formjacking, skimming digital e ataques de coleta de PII, automatizando o monitoramento de páginas da Web em busca de códigos suspeitos, gerando alertas acionáveis e interrompendo imediatamente a exfiltração de dados com mitigação em um clique.
Para saber mais sobre como proteger a privacidade dos seus clientes e sua empresa contra violações de conformidade, preservando a confiança dos consumidores e a reputação da marca, leia esta visão geral da solução ou assista a esta demonstração do produto.
Sobre o autor
Publicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...