PS PrestaShop Principiante

DataFirefly Skimming Guard: anti-skimming e integrità dei file

Installare e configurare il rilevamento dello skimming, il monitoraggio dei file e la verifica del core PrestaShop.

Aggiornato Versione del modulo 1.2.1

Presentazione

DataFirefly Skimming Guard sorveglia il codice servito ai clienti del tuo negozio PrestaShop 8 o 9: i file, il database, l’HTML inviato sulle pagine di pagamento e ciò che fa il browser al checkout. Rileva gli script iniettati che copiano i numeri di carta (attacchi di tipo Magecart), i file modificati o aggiunti e i file del core PrestaShop diversi dalla versione ufficiale. Completa DataFirefly Admin Shield, che protegge l’accesso al back office.

Installazione

  1. Nel back office, apri Moduli > Gestione moduli > Carica un modulo e invia dfskimguard-1.2.1.zip.
  2. Apri il modulo. È disponibile anche in Parametri avanzati > Skimming Guard.
  3. Clicca su Scansiona ora. La prima scansione registra il riferimento dei file: un’impronta SHA-256 per file e una copia dei file del tema, delle viste dei moduli e dei punti di ingresso.
  4. Configura l’attività pianificata (vedi sotto).
  5. Invia un avviso di prova dalla panoramica per verificare la ricezione.
Un riferimento di 16.000 file si crea in meno di un minuto su un server normale. Su un hosting limitato a 30 secondi per richiesta, la scansione si divide da sola in passi brevi.

Attività pianificata

Le scansioni girano in background, mai durante la visita di un cliente. Tre opzioni:

  • URL cron: copia l’URL del blocco Attività pianificata e richiamalo ogni 15 minuti dal gestore cron del tuo hosting. L’URL contiene un token segreto.
  • Riga di comando: con accesso SSH, esegui php modules/dfskimguard/cli.php. L’opzione --full esegue una scansione completa in una volta, senza limiti di tempo.
  • Modulo cronjobs di PrestaShop: se lo usi, l’attività gira ogni ora.

Ogni esecuzione avvia o riprende la scansione dei file, analizza il database ogni ora, verifica il core PrestaShop ogni settimana e il contenuto degli script di terze parti ogni giorno.

Panoramica

Il banner in alto su ogni scheda mostra un punteggio di sicurezza da 0 a 100 e una frase che riassume la situazione, con collegamenti a ciò che resta da fare. La panoramica elenca due gruppi di controlli, prima quelli non superati:

  • Configurazione della protezione: riferimento recente, attività pianificata attiva, destinatari degli avvisi, fine dell’apprendimento, blocco dei dati della carta, Content Security Policy, verifica del core, giustificazione degli script di pagamento.
  • Protezione del negozio: modalità debug, cartella di installazione, nome della cartella admin, file pericolosi accessibili dal web (backup SQL o ZIP, phpinfo, adminer, .git, .env, eval-stdin.php di PHPUnit), SSL su tutte le pagine, versione di PHP, permessi dei file di configurazione.

Ogni controllo non superato indica come correggerlo.

Protezione del checkout

Ispezione dell’HTML servito

Su carrello, checkout e pagine di pagamento dei moduli, il modulo legge l’HTML generato da PrestaShop. Registra ogni script esterno, iframe, destinazione di modulo e dominio citato in uno script inline, e applica firme di codice offuscato (eval(atob(...)), new Function, catene fromCharCode, caricatori di script, rilevamento degli strumenti per sviluppatori). Di default ogni pagina viene ispezionata al massimo una volta ogni 5 minuti. Regola l’intervallo nelle impostazioni, oppure sorveglia tutte le pagine del negozio.

Sentinella del browser

Uno script di 5,5 KB viene iniettato per primo nell’<head> delle pagine monitorate. Segnala i domini sconosciuti contattati dalla pagina e, sulle pagine di pagamento, individua un numero di carta valido inviato a un dominio non approvato, anche codificato in base64. Il numero non viene mai trasmesso al server. Per filtrare le estensioni del browser, un dominio sconosciuto avvisa solo dopo 3 visitatori distinti (regolabile); un tentativo di invio di una carta avvisa subito.

Blocco dei dati della carta

Opzione Blocca i dati della carta inviati a domini sconosciuti: la richiesta viene annullata quando contiene un numero di carta ed è diretta a un dominio non approvato. Attivala al termine del periodo di apprendimento, dopo aver approvato i fornitori di pagamento.

Content Security Policy

Il modulo può inviare una CSP costruita dai domini approvati sulle pagine monitorate. Inizia con Solo segnalazione e passa ad Applica quando non compaiono più domini inattesi.

In modalità Applica, ogni dominio non approvato viene bloccato, compreso un nuovo fornitore di pagamento. Approvalo prima di attivarla.

Periodo di apprendimento

Nelle 48 ore dopo l’installazione, gli script e i domini di terze parti a basso rischio sono approvati senza avvisi. Quelli sospetti avvisano comunque. Riavvia l’apprendimento dopo un cambio di tema o di metodo di pagamento con Apprendi per 48 ore.

Domini attendibili

Un elenco integrato copre i fornitori più diffusi (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). Aggiungi i tuoi domini nelle impostazioni, uno per riga; i sottodomini sono inclusi.

Scheda Script e domini

La scheda elenca ogni elemento visto sulle tue pagine con tipo, dominio, pagina, punteggio di rischio e numero di passaggi. Tre azioni:

  • Approva: l’elemento e il suo dominio entrano nell’elenco attendibile (sentinella e CSP). Per uno script delle pagine di pagamento, una finestra chiede la giustificazione.
  • Malevolo: la sentinella blocca il dominio e la CSP lo esclude. Se ricompare, parte un avviso critico.
  • Elimina: rimuove l’elemento dall’inventario.

Integrità dei file

Cosa viene sorvegliato

Estensioni di default: php, phtml, php5, php7, phar, inc, js, mjs, tpl, twig, html, htm, htaccess, ini, svg, ico. Percorsi esclusi di default: var, cache, img, upload, download, .git, node_modules, cache del tema e backup della cartella admin. Il token {admin} viene sostituito dal nome della tua cartella di amministrazione.

Un file è considerato invariato se dimensione, data di modifica e data di cambio inode non sono cambiate. La data di cambio inode non si falsifica con touch. Ogni 7 giorni (regolabile) vengono ricalcolate tutte le impronte.

Firme

Ogni file nuovo o modificato passa le firme: web shell note, eval su dati decodificati o della richiesta, comandi di sistema dai dati della richiesta, PHP nascosto in un’immagine o un .ico, include di un file multimediale, auto_prepend_file aggiunto in .htaccess o .user.ini, file multimediali eseguiti come PHP, campi della carta letti e inviati in rete. Un file con rischio 70 o superiore genera subito un avviso critico; le altre modifiche sono raccolte in un riepilogo per scansione.

Scheda File

  • Vedi le modifiche: diff riga per riga tra versione approvata e file attuale. In un JS minificato su una sola riga, viene mostrato solo il frammento inserito.
  • Ripristina la versione approvata: rimette la copia di riferimento. La versione modificata resta in var/dfskimguard/quarantine come prova.
  • Approva: accetta il file attuale come nuovo riferimento. La selezione multipla e Approva tutte le modifiche servono dopo un aggiornamento.
  • Quarantena: sposta fuori dal negozio un nuovo file sospetto. Si può ripristinare.

Finestra di aggiornamento

Prima di aggiornare un modulo o il tema, clicca su Sto aggiornando il negozio (2 h). Per due ore, i file modificati senza codice sospetto diventano il nuovo riferimento senza avvisi. Un file ad alto rischio avvisa comunque.

Verifica del core PrestaShop

La scheda Core PrestaShop scarica da GitHub il sorgente ufficiale della tua versione e confronta i file PHP, TPL e Twig di classes, controllers, src, config e i file PHP della cartella admin. I fine riga e le impostazioni che la build di release e la modalità debug riscrivono in config/defines.inc.php vengono ignorati. Il modulo segnala anche i file PHP inattesi in classes, controllers e src.

Per ogni file modificato: Confronta con l’originale, poi Ripristina la versione ufficiale. Un file inatteso può essere messo in quarantena. La verifica si ripete automaticamente ogni settimana.

Il server deve poter raggiungere codeload.github.com. Se le connessioni in uscita sono bloccate, la verifica mostra un messaggio di errore e il resto del modulo funziona normalmente.

Analisi del database

Ogni ora il modulo cerca tag script, gestori onerror o onload, URL javascript: e codice offuscato nella configurazione, nelle pagine CMS, nelle descrizioni di prodotti, categorie, marchi e fornitori e nei blocchi di testo personalizzati. Uno script verso un dominio sconosciuto o segnalato fa salire il rischio.

PCI DSS 6.4.3 e 11.6.1

Per ogni script autorizzato sulle pagine di pagamento, il modulo registra la giustificazione, il dipendente che lo ha autorizzato e la data. Il pulsante Giustifica completa uno script già approvato. Il modulo sorveglia inoltre:

  • il contenuto degli script di terze parti delle pagine di pagamento, scaricati e analizzati ogni giorno: un dominio approvato che inizia a servire codice malevolo genera un avviso critico;
  • le intestazioni di sicurezza delle pagine di pagamento impostate da PrestaShop e dai suoi moduli (CSP, HSTS, X-Frame-Options, Permissions-Policy). Le intestazioni aggiunte dal server web non sono visibili da PHP.

Il pulsante Report PCI DSS apre un report stampabile: inventario giustificato, meccanismi di rilevamento attivi con l’ultima esecuzione, eventi degli ultimi 90 giorni. Esporta in CSV fornisce l’inventario grezzo.

Il report supporta una valutazione PCI DSS. Non certifica la conformità: il riferimento resta il tuo acquirer o valutatore.

Avvisi

  • Email: uno o più indirizzi, gravità minima regolabile (info, avvertenza, critico).
  • Webhook: URL HTTPS che riceve un JSON con un campo text compatibile con Slack, utilizzabile con Teams o un servizio interno.
  • Senza duplicati: lo stesso avviso non viene rinviato per 60 minuti, e partono al massimo 20 avvisi all’ora (regolabile).
  • Banner nel back office: finché un avviso critico non è letto, un banner rosso compare in alto nel back office.
  • Report settimanale: punteggio, avvisi della settimana, elementi in attesa e punti da correggere.

Domande frequenti

Ricevo avvisi dopo l’aggiornamento di un modulo

Approva le modifiche nella scheda File, oppure usa la finestra di aggiornamento la prossima volta.

Compare un dominio sconosciuto che non riconosco

Può venire da un’estensione del browser di un visitatore. Finché non lo hanno visto 3 visitatori distinti, non avvisa. Se è un servizio che usi, approvalo; altrimenti segnalalo come malevolo.

Dove sono salvate le copie e la quarantena?

Le copie di riferimento sono compresse nel database. La quarantena e l’archivio ufficiale di PrestaShop sono in var/dfskimguard, protetto da un .htaccess. Il modulo non scansiona questa cartella.

Come ricomincio da zero?

Il link Reimposta il riferimento cancella il riferimento dei file; la scansione successiva ne crea uno nuovo. I file in quarantena restano elencati e ripristinabili.

Questa pagina ti è stata utile?

Ancora bloccato? Contatta l'assistenza