PS PrestaShop Iniciante

DataFirefly Skimming Guard: anti-skimming e integridade dos ficheiros

Instalar e configurar a deteção de skimming, a monitorização dos ficheiros e a verificação do núcleo PrestaShop.

Atualizado Versão do módulo 1.2.1

Apresentação

O DataFirefly Skimming Guard vigia o código servido aos clientes da sua loja PrestaShop 8 ou 9: os ficheiros, a base de dados, o HTML enviado nas páginas de pagamento e o que o navegador faz no checkout. Deteta os scripts injetados que copiam números de cartão (ataques do tipo Magecart), os ficheiros alterados ou acrescentados e os ficheiros do núcleo PrestaShop que diferem da versão oficial. Complementa o DataFirefly Admin Shield, que protege o acesso ao back office.

Instalação

  1. No back office, abra Módulos > Gestor de módulos > Carregar um módulo e envie dfskimguard-1.2.1.zip.
  2. Abra o módulo. Também está disponível em Parâmetros avançados > Skimming Guard.
  3. Clique em Analisar agora. A primeira análise regista a referência dos seus ficheiros: uma impressão SHA-256 por ficheiro e uma cópia dos ficheiros do tema, das vistas dos módulos e dos pontos de entrada.
  4. Configure a tarefa agendada (ver abaixo).
  5. Envie um alerta de teste a partir da visão geral para confirmar a receção.
Uma referência de 16.000 ficheiros cria-se em menos de um minuto num servidor comum. Num alojamento limitado a 30 segundos por pedido, a análise divide-se sozinha em passos curtos.

Tarefa agendada

As análises correm em segundo plano, nunca durante a visita de um cliente. Três opções:

  • URL cron: copie o URL do bloco Tarefa agendada e chame-o a cada 15 minutos a partir do gestor cron do seu alojamento. O URL contém um token secreto.
  • Linha de comandos: com acesso SSH, execute php modules/dfskimguard/cli.php. A opção --full faz uma análise completa de uma só vez, sem limite de tempo.
  • Módulo cronjobs do PrestaShop: se o usar, a tarefa corre de hora a hora.

Cada execução inicia ou retoma a análise dos ficheiros, analisa a base de dados de hora a hora, verifica o núcleo PrestaShop uma vez por semana e o conteúdo dos scripts de terceiros uma vez por dia.

Visão geral

A faixa no topo de cada separador mostra uma pontuação de segurança de 0 a 100 e uma frase que resume a situação, com atalhos para o que falta tratar. A visão geral lista dois grupos de controlos, primeiro os que falham:

  • Configuração da proteção: referência recente, tarefa agendada ativa, destinatários dos alertas, fim da aprendizagem, bloqueio de dados de cartão, Content Security Policy, verificação do núcleo, justificação dos scripts de pagamento.
  • Reforço da loja: modo de depuração, pasta de instalação, nome da pasta admin, ficheiros perigosos acessíveis pela web (cópias SQL ou ZIP, phpinfo, adminer, .git, .env, eval-stdin.php do PHPUnit), SSL em todas as páginas, versão do PHP, permissões dos ficheiros de configuração.

Cada controlo que falha indica como corrigi-lo.

Proteção do checkout

Inspeção do HTML servido

No carrinho, no checkout e nas páginas de pagamento dos módulos, o módulo lê o HTML gerado pelo PrestaShop. Regista cada script externo, iframe, destino de formulário e domínio citado num script inline, e aplica assinaturas de código ofuscado (eval(atob(...)), new Function, cadeias fromCharCode, carregadores de scripts, deteção das ferramentas de programador). Por defeito, cada página é inspecionada no máximo uma vez a cada 5 minutos. Ajuste o intervalo nas definições ou vigie todas as páginas da loja.

Sentinela do navegador

Um script de 5,5 KB é injetado primeiro no <head> das páginas vigiadas. Assinala os domínios desconhecidos contactados pela página e, nas páginas de pagamento, deteta um número de cartão válido enviado para um domínio não aprovado, mesmo codificado em base64. O número nunca é transmitido ao servidor. Para filtrar as extensões do navegador, um domínio desconhecido só alerta depois de 3 visitantes distintos (ajustável); uma tentativa de envio de cartão alerta logo à primeira.

Bloqueio de dados de cartão

Opção Bloquear dados de cartão enviados para domínios desconhecidos: o pedido é cancelado quando contém um número de cartão e se dirige a um domínio não aprovado. Ative-a quando terminar o período de aprendizagem e os seus fornecedores de pagamento estiverem aprovados.

Content Security Policy

O módulo pode enviar nas páginas vigiadas uma CSP construída a partir dos domínios aprovados. Comece por Apenas relatório e passe para Aplicar quando não surgir nenhum domínio inesperado.

No modo Aplicar, qualquer domínio não aprovado é bloqueado, incluindo um novo fornecedor de pagamento. Aprove-o antes de ativar.

Período de aprendizagem

Durante as 48 horas seguintes à instalação, os scripts e domínios de terceiros de baixo risco são aprovados sem alerta. Os suspeitos alertam na mesma. Reinicie a aprendizagem após uma mudança de tema ou de meio de pagamento com Aprender durante 48 horas.

Domínios de confiança

Uma lista integrada cobre os fornecedores mais comuns (Stripe, PayPal, Braintree, Adyen, Mollie, Klarna, Checkout.com, Worldpay, PayPlug, Stancer, Lyra, PayZen, Systempay, Monetico, Alma, Scalapay, SumUp, Redsys, HiPay, Apple Pay, Google Pay, reCAPTCHA, hCaptcha, Turnstile, Google Analytics, Tag Manager, Meta). Acrescente os seus domínios nas definições, um por linha; os subdomínios estão incluídos.

Separador Scripts e domínios

O separador lista cada elemento visto nas suas páginas com o tipo, o domínio, a página, a pontuação de risco e o número de passagens. Três ações:

  • Aprovar: o elemento e o seu domínio entram na lista de confiança (sentinela e CSP). Para um script das páginas de pagamento, uma janela pede a justificação.
  • Malicioso: a sentinela bloqueia o domínio e a CSP exclui-o. Se voltar a aparecer, é enviado um alerta crítico.
  • Eliminar: retira o elemento do inventário.

Integridade dos ficheiros

O que é vigiado

Extensões por defeito: php, phtml, php5, php7, phar, inc, js, mjs, tpl, twig, html, htm, htaccess, ini, svg, ico. Caminhos excluídos por defeito: var, cache, img, upload, download, .git, node_modules, caches do tema e cópias da pasta admin. O token {admin} é substituído pelo nome da sua pasta de administração.

Um ficheiro é considerado inalterado se o tamanho, a data de modificação e a data de alteração do inode não mudaram. A data de alteração do inode não se falsifica com touch. A cada 7 dias (ajustável) são recalculadas todas as impressões.

Assinaturas

Cada ficheiro novo ou alterado passa pelas assinaturas: web shells conhecidos, eval sobre dados descodificados ou do pedido, comandos de sistema a partir do pedido, PHP escondido numa imagem ou num .ico, include de um ficheiro multimédia, auto_prepend_file acrescentado em .htaccess ou .user.ini, ficheiros multimédia executados como PHP, campos do cartão lidos e enviados pela rede. Um ficheiro com risco 70 ou mais gera um alerta crítico imediato; as outras alterações são agrupadas num resumo por análise.

Separador Ficheiros

  • Ver as alterações: diff linha a linha entre a versão aprovada e o ficheiro atual. Num JS minificado numa só linha, só é mostrado o fragmento inserido.
  • Restaurar a versão aprovada: repõe a cópia de referência. A versão alterada fica em var/dfskimguard/quarantine como prova.
  • Aprovar: aceita o ficheiro atual como nova referência. A seleção múltipla e Aprovar todas as alterações servem depois de uma atualização.
  • Quarentena: retira da loja um novo ficheiro suspeito. Pode ser restaurado.

Janela de atualização

Antes de atualizar um módulo ou o tema, clique em Estou a atualizar a minha loja (2 h). Durante duas horas, os ficheiros alterados sem código suspeito passam a ser a nova referência sem alerta. Um ficheiro de alto risco alerta na mesma.

Verificação do núcleo PrestaShop

O separador Núcleo PrestaShop descarrega do GitHub a fonte oficial da sua versão e compara os ficheiros PHP, TPL e Twig de classes, controllers, src, config e os ficheiros PHP da pasta admin. Os finais de linha e as definições que o build da release e o modo de depuração reescrevem em config/defines.inc.php são ignorados. O módulo assinala também os ficheiros PHP inesperados em classes, controllers e src.

Para cada ficheiro alterado: Comparar com o oficial e depois Restaurar a versão oficial. Um ficheiro inesperado pode ir para quarentena. A verificação repete-se automaticamente todas as semanas.

O servidor tem de conseguir aceder a codeload.github.com. Se as ligações de saída estiverem bloqueadas, a verificação mostra uma mensagem de erro e o resto do módulo funciona normalmente.

Análise da base de dados

De hora a hora, o módulo procura etiquetas script, handlers onerror ou onload, URL javascript: e código ofuscado na configuração, nas páginas CMS, nas descrições de produtos, categorias, marcas e fornecedores e nos blocos de texto personalizados. Um script para um domínio desconhecido ou marcado aumenta o risco.

PCI DSS 6.4.3 e 11.6.1

Para cada script autorizado nas páginas de pagamento, o módulo regista a justificação, o funcionário que o autorizou e a data. O botão Justificar completa um script já aprovado. O módulo vigia ainda:

  • o conteúdo dos scripts de terceiros das páginas de pagamento, descarregados e analisados todos os dias: um domínio aprovado que começa a servir código malicioso gera um alerta crítico;
  • os cabeçalhos de segurança das páginas de pagamento definidos pelo PrestaShop e pelos seus módulos (CSP, HSTS, X-Frame-Options, Permissions-Policy). Os cabeçalhos acrescentados pelo servidor web não são visíveis a partir do PHP.

O botão Relatório PCI DSS abre um relatório imprimível: inventário justificado, mecanismos de deteção ativos com a última execução e eventos dos últimos 90 dias. Exportar em CSV fornece o inventário em bruto.

O relatório serve de apoio a uma avaliação PCI DSS. Não certifica a conformidade: o seu adquirente ou avaliador continua a ser a referência.

Alertas

  • Email: um ou vários endereços, gravidade mínima ajustável (informação, aviso, crítico).
  • Webhook: URL HTTPS que recebe um JSON com um campo text compatível com o Slack, utilizável com o Teams ou um serviço próprio.
  • Sem duplicados: o mesmo alerta não é reenviado durante 60 minutos, e são enviados no máximo 20 alertas por hora (ajustável).
  • Faixa no back office: enquanto um alerta crítico não for lido, aparece uma faixa vermelha no topo do back office.
  • Relatório semanal: pontuação, alertas da semana, elementos pendentes e pontos a corrigir.

Perguntas frequentes

Recebo alertas depois de atualizar um módulo

Aprove as alterações no separador Ficheiros ou use a janela de atualização da próxima vez.

Aparece um domínio desconhecido que não reconheço

Pode vir de uma extensão do navegador de um visitante. Enquanto não for visto por 3 visitantes distintos, não alerta. Se for um serviço que utiliza, aprove-o; caso contrário, marque-o como malicioso.

Onde ficam guardadas as cópias e a quarentena?

As cópias de referência ficam comprimidas na base de dados. A quarentena e o arquivo oficial do PrestaShop estão em var/dfskimguard, protegido por um .htaccess. O módulo não analisa esta pasta.

Como recomeço do zero?

A ligação Repor a referência apaga a referência dos ficheiros; a análise seguinte cria uma nova. Os ficheiros em quarentena continuam listados e podem ser restaurados.

Esta página foi útil?

Ainda com dúvidas? Contacte o suporte