Nossa página de comparação mostra uma ótima visão geral das diferentes abordagens para alcançar segurança do lado do cliente e atender aos requisitos do PCI DSS (6.4.3 e 11.6.1).
Nossa solução (o proxy híbrido) supera outras abordagens em várias categorias. Vamos compará-la ao crawler que muitos concorrentes neste espaço usam. Os benefícios e as muitas deficiências que vêm com esta solução.
Neste artigo, vamos focar nas seções 6.4.3 e 11.6.1 do PCI DSS 4.0.1. Visite nossa página de comparação para obter os benefícios completos e desvantagens em um contexto de segurança completo.
"Um método é implementado para confirmar que cada script é autorizado"
6.4.3 Todos os scripts de página de pagamento que são carregados e executados no navegador do consumidor são gerenciados da seguinte forma:
Um método é implementado para confirmar que cada script é autorizado.
Um método é implementado para garantir a integridade de cada script.
Um inventário de todos os scripts é mantido com justificativa comercial ou técnica por escrito sobre por que cada um é necessário.
O requisito PCI 6.4.3 requer um mecanismo para impedir que scripts não autorizados sejam carregados.
Para remover qualquer confusão, a especificação PCI também afirma:
Código não autorizado não pode ser executado na página de pagamento conforme é renderizado no navegador do consumidor.
Para muitos GRCs, é um desafio alocar esforços de engenharia para requisitos de conformidade. Entender como os requisitos PCI de segurança do lado do cliente se traduzem em implementação prática é frequentemente onde as equipes ficam presas. Algumas soluções podem levá-lo a acreditar que você pode atender aos requisitos sem implementar nenhum código ou fazer quaisquer ajustes. Isso, no entanto, não está correto.
Este requisito pode ser alcançado de várias maneiras. Um comerciante pode implementar uma Content Security Policy. CSP, no entanto, é conhecida por ser difícil de gerenciar e manter, mas é uma solução válida para atender a este requisito.
Um comerciante pode optar por usar um agente do lado do cliente que bloqueia alguns comportamentos de JS. No entanto, isso não é uma solução mágica. Houve vários exemplos de ataques do lado do cliente que essencialmente impediram o agente de segurança de funcionar e desabilitaram total ou parcialmente sua funcionalidade, incluindo capacidade de bloqueio. Portanto, sempre teste a solução que você adquire com um script do lado do cliente escrito por você mesmo. Infelizmente, a maioria dos engenheiros JavaScript de nível médio não achará isso um grande desafio.
Ou, você pode usar um serviço de proxy como o cside para impedir que um script malicioso seja servido em primeiro lugar.
Esta linha específica dos requisitos do PCI DSS é facilmente negligenciada, mas remete à natureza do requisito: implementar padrões de segurança de cartão de pagamento para impedir que cartões de crédito sejam roubados na entrada.
Crawlers não 'veem' a carga útil real e não capturarão um ataque sério
Crawlers funcionam visitando seu site e indexando quais scripts são carregados. Detalhe importante, eles agem como um usuário, mas claramente não são um usuário humano real. Existem vários indicadores simples, vindo do endereço IP de um provedor de nuvem sendo um deles. Esta é uma falha fundamental de design, porque a entrega de JavaScript é dinâmica por design. É construída para servir diferentes versões de scripts com base no tempo, user-agent, localização, faixas de IP...
Atores mal-intencionados, é claro, aproveitam essa dinâmica para evitar detecção. É improvável que um crawler detecte o ataque real em primeira mão. Portanto, a inteligência de ameaças deve vir de outras fontes. É aqui que a maioria das soluções compra inteligência de feed de ameaças de provedores. Esses provedores, no entanto, tendem a chegar atrasados ao show. Quando o ataque Polyfill aconteceu, levou mais de 30 horas para qualquer fornecedor de ameaças sinalizá-lo, mesmo que tivesse ampla cobertura da imprensa. O domínio só foi sinalizado quando a Namecheap já havia derrubado o domínio. Provedores de feed de ameaças também não estão especificamente à procura de ataques do lado do cliente, às vezes eles os capturam, mas igualmente atores mal-intencionados sabem evitar seus pesquisadores. A maior parte de sua inteligência de ataque do lado do cliente se origina das redes sociais.
Estabelecemos que um crawler não pode garantir que a carga útil que ele busca é a que o usuário recebeu, mas vamos imaginar por um segundo que seja. A maioria dos scripts maliciosos são carregados como sub-requisições baseadas em gatilhos do usuário: cliques do usuário, rolagens, logins ou adição de algo ao carrinho.
Se um script malicioso for injetado devido a uma interação do usuário, o crawler não verá o script malicioso a menos que faça essa interação do usuário. Isso é praticamente impossível de fazer, pois cada página pode ter infinitas habilidades de interação. Exemplo: fazer apenas a busca ao script malicioso se uma série de botões for pressionada 5 vezes, rolada uma janela completa para baixo, o navegador não tiver ferramentas de desenvolvedor abertas... "Rastreamento sintético" afirma abordar isso, mas realmente não pode por razões técnicas óbvias.
Se você aplicar uma abordagem de análise de segurança estática a um problema dinâmico, você não aborda a preocupação de segurança.
Então todos os crawlers são inúteis?
Não. O conceito fundamental de um crawler é falho, mas se um fornecedor não espera ver a carga útil maliciosa em primeira mão através do crawler, mas é capaz de sinalizar o script pai através de outros métodos de detecção ativa fora do crawler, ele ainda pode abordar preocupações de segurança em um nível alto o suficiente (para alguns). Por exemplo: o crawler do cside usa a inteligência de script malicioso recebida através dos sites com proxy de outros clientes do cside. Como resultado, cargas úteis maliciosas são detectadas em outros sites e os objetos pai que injetaram esses scripts maliciosos são sinalizados, se o crawler recebeu a carga útil limpa, mas sabe que esse script está comprometido através de outros sites, isso levará a um alerta.
"Espere, mas vejo todos esses dados interessantes no painel deles?"
Isso é definitivamente um valor agregado. Crawlers podem dar a você uma compreensão de alguns dos comportamentos de alguns dos scripts em seu site, populando o painel, fornecendo insights interessantes. Mas qualquer script ruim saberá como não aparecer nesses painéis. Geralmente, as pessoas têm um viés por objetos brilhantes. Um painel brilhante com muitas informações interessantes nele leva as pessoas a pensar que as mesmas informações estarão disponíveis em um dia ruim. Isso, no entanto, não é o caso.
Por que considerar um crawler?
Segurança é tudo sobre camadas. Adicionar mais soluções para monitorar os mesmos problemas geralmente é uma coisa boa.
Eles são relativamente leves para implantar (geralmente) e fornecem um mapa básico de quais scripts estão presentes em seu site em um determinado momento. Para uma equipe de conformidade fazendo verificações periódicas ou auditorias que não são suscetíveis ao PCI DSS, isso é útil.
Eles também fornecem visibilidade sobre mudanças estáticas. Digamos que se uma nova URL de script aparecer repentinamente ou uma existente desaparecer. Nesse aspecto, é um passo acima do CSP, que não fornece nenhuma visibilidade de carga útil. Leia sobre as limitações dos CSPs aqui. Um crawler pode ajudá-lo a manter o inventário de scripts (parte de 6.4.3) e visualizar cabeçalhos de segurança quando rastreia (PCI 11.6.1), mas não pode impedir que scripts não autorizados sejam carregados. Você ainda precisaria pelo menos adicionar CSP ou um agente. Então, compre um crawler apenas se ele também fornecer um endpoint CSP ou um agente.
Um crawler sozinho não pode fornecer conformidade com o PCI DSS.
