Mais e mais organizações têm criado seus aplicativos voltados para o público usando componentes e/ou scripts de terceiros devido à agilidade que eles oferecem no processo de desenvolvimento. Ao mesmo tempo, vimos um número crescente de ataques aos usuários desses aplicativos.
Nos bastidores, isso ocorre porque, com o tempo, alguns códigos de aplicativos web agora são carregados no navegador do usuário em vez de no lado do servidor. Devido a essa mudança, os usuários agora estão expostos a esses componentes de terceiros e as organizações que os empregam não têm controle direto sobre suas medidas de segurança. Esse relacionamento entre scripts de terceiros, proprietários de aplicativos e usuários está sendo explorado para lançar ataques à cadeia de suprimentos no dispositivo do usuário.
Neste artigo, vamos explorar essas novas vulnerabilidades e como as organizações podem abordá-las para proteger seus usuários.
Vários ataques de alto perfil direcionados ao lado do cliente de aplicativos causaram danos substanciais às organizações, começando por volta de 2018. Um dos casos mais notáveis foi um ataque a clientes da British Airways, no qual o invasor não só exfiltrou os detalhes do cartão de pagamento, mas também os nomes e endereços de 500 mil clientes. O invasor roubou as informações comprometendo-as usando JavaScript.
As organizações que processam pagamentos de clientes estão sujeitas aos requisitos de conformidade com o Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS) que são projetados para proteger e defender os dados de contas de cartões de pagamento.
Muitas vezes, como no caso da British Airways, esses ataques são realizados sem o conhecimento do proprietário do site. Para resolver isso, a versão mais recente da conformidade com o PCI DSS reconhece que a ameaça emergente de ataques do lado do cliente requer proteção ativa para proteger os titulares de cartões de pagamento contra o roubo das informações de seus cartões. O Padrão de Segurança de Dados (DSS) do PCI 4.0 apresenta muitos novos requisitos que todos os comerciantes que aceitam pagamentos com cartão devem atender em comparação com a versão anterior do PCI, mas hoje vamos nos concentrar em dois novos requisitos relacionados à segurança do lado do cliente.
Esses dois novos requisitos, 6.4.3 e 11.6.1, podem ser resumidos da seguinte forma:
O requisito6.4.3 exige que os comerciantes rastreiem e façam o inventário adequado dos scripts (por exemplo, JavaScripts) usados nas páginas de pagamento, bem como justifiquem por que eles são necessários e se seu código se comporta conforme o esperado.
Para atender ao requisito 6.4.3, um cabeçalho de Política de Segurança de Conteúdo (CSP) pode ser implantado. As CSPs são uma forma de modelo de segurança positiva que pode ser definido para permitir que JavaScripts selecionados sejam executados nas páginas de pagamento e negar por padrão quaisquer JavaScripts não permitidos explicitamente. Um monitor de página em constante execução pode ajudar a gerar um cabeçalho CSP e verificar continuamente o conteúdo desses scripts em busca de quaisquer ameaças maliciosas.
O requisito 11.6.1 refere-se a alertar os proprietários de sites sobre alterações nos scripts (por exemplo, JavaScripts) usados nas páginas de pagamento conforme mencionado acima e nos cabeçalhos HTTP usados para proteger esses scripts, como o cabeçalho CSP. Dependendo de como esse cabeçalho CSP é implantado, o proxy reverso ou provedores de CDN podem detectar alterações e notificar o proprietário do site de acordo. Uma combinação dessas soluções ajuda a atender ao requisito 11.6.1.
Ao atender a esses dois requisitos, os proprietários de sites podem proteger os dados das contas de cartão de pagamento de seus usuários contra o roubo por agentes de ameaças, preservando a confiança de seus usuários e reduzindo o risco.
As dependências de JavaScript de terceiros, ou ataques à cadeia de suprimentos, não são o único vetor de ataque do lado do cliente. Algumas dessas dependências de terceiros também podem recorrer às suas próprias dependências, que às vezes são chamadas de dependências de quarto nível, estas também podem estar comprometidas.
O setor tomou medidas para se proteger contra os ataques à cadeia de suprimentos, tanto quanto possível, nos últimos anos, e há uma conscientização mais geral sobre o risco da cadeia de suprimentos do que havia há cinco anos. Mas também há outros riscos do lado do cliente, aos quais prestamos menos atenção, que abrem uma superfície de ataque mais ampla.
Um risco está no ambiente do usuário, no navegador utilizado e no sistema operacional no qual o navegador é executado. Quando um usuário visita um site, as extensões do navegador ou qualquer outro software pode injetar JavaScripts diretamente no site, alterando as páginas web. Embora nem todos os JavaScripts injetados sejam maliciosos, seu efeito varia desde a injeção de anúncios até o possível roubo de informações confidenciais.
Outro exemplo é cross-site scripting (XSS), em que um agente malicioso injeta um código em um site legítimo que será executado quando a vítima carregar o site. Do ponto de vista de proteção do lado do cliente, essas injeções bem-sucedidas podem se parecer com JavaScripts fornecidos diretamente pela parte primária ou o próprio site onde a confiança é assumida por padrão.
Essa lista não é completa. Para atingir um nível de proteção abrangente, uma solução de segurança do lado do cliente deve ser capaz de monitorar todos os scripts igualmente, independentemente de sua fonte, ajudando o proprietário do site a tomar decisões informadas.
Se você é um comerciante que aceita pagamentos com cartão, tem até 31 de março de 2025 para implementar sua abordagem de proteção do ambiente do lado do cliente para o PCI DSS v4.0. A solução de segurança da Cloudflare do lado do cliente, o Page Shield, pode ajudar a facilitar o processo de atendimento a esses requisitos novos e futuros.
Além das proteções das páginas de pagamento, o Page Shield da Cloudflare também monitora continuamente todo o seu site, verificando cada script em relação a um modelo de aprendizado de máquina interno, construído e treinado especializado em classificar ataques Magecart, protegendo seus usuários, não importa como e onde eles estejam interagindo com seu site .
Este artigo é parte de uma série sobre as tendências e os assuntos mais recentes que influenciam os tomadores de decisões de tecnologia hoje em dia.
Saiba mais sobre como abordar estrategicamente todos os requisitos do PCI no artigo técnico Uma abordagem estratégica para manter a conformidade com o PCI DSS 4.0 .
Após ler este artigo, você entenderá:
Os principais vetores de ataque direcionados ao ambiente do lado do cliente
Os dois novos requisitos de conformidade com o PCI
Como proteger ambientes do lado do cliente e proteger seus clientes
Uma abordagem estratégica para manter a conformidade com o PCI DSS 4.0
Simplifique a conformidade dos dados com controles combináveis
Page Shield: mantenha o comércio eletrônico e a empresa protegidos contra o Magecart