Uno skimmer è un piccolo script che ruba i dati delle carte di pagamento mentre il cliente li inserisce nel modulo del checkout. Il negozio continua a funzionare, gli ordini arrivano, i pagamenti vanno a buon fine: l’unico segnale, spesso settimane dopo, sono le segnalazioni dei clienti che trovano addebiti sconosciuti. Per un e-commerce su WooCommerce è una delle infezioni più gravi, per il danno ai clienti e per le conseguenze con il fornitore dei pagamenti.
Come funziona uno skimmer
Lo script viene aggiunto alle pagine del negozio e resta inattivo finché il visitatore non arriva al checkout. Lì si aggancia ai campi del modulo o all’invio dell’ordine, legge numero della carta, scadenza, codice di sicurezza e dati di fatturazione, e li invia a un server controllato dall’attacco. L’invio avviene in modi poco appariscenti: una richiesta verso un dominio che imita un servizio di statistiche o una libreria nota, un’immagine invisibile con i dati nell’indirizzo, una connessione WebSocket.
Molti gateway di pagamento mostrano i campi della carta dentro un iframe del fornitore, che uno script della pagina non può leggere. È una protezione importante, ma non assoluta: alcuni skimmer nascondono l’iframe e mostrano al suo posto un modulo falso, identico nell’aspetto, oppure aggiungono un passaggio fittizio che chiede di nuovo i dati.
Dove si nasconde
Lo skimmer può trovarsi in molti posti diversi, e quasi mai in uno solo:
- nei file del tema o di un plugin, spesso in fondo a un file JavaScript già esistente;
- nel database, dentro le impostazioni di un plugin che permette di aggiungere script personalizzati, in un widget o in un’opzione dedicata;
- in un plugin must-use che lo stampa solo nelle pagine del checkout;
- in una risorsa esterna caricata dal sito, se il fornitore di quella risorsa è stato compromesso.
Il codice è quasi sempre offuscato e caricato in modo condizionale: solo nelle pagine del carrello e del pagamento, solo per i visitatori non collegati, a volte solo da alcuni paesi.
Come individuarlo
Il controllo più diretto è guardare il checkout come lo vede un cliente: in una finestra di navigazione privata, senza essere collegati, con un prodotto nel carrello, si apre il pannello degli strumenti per sviluppatori del browser e si esamina l’elenco delle richieste di rete. Ogni dominio contattato dalla pagina di pagamento deve avere una spiegazione: il gateway, gli strumenti di statistica scelti dal negozio, le librerie note. Un dominio sconosciuto che riceve dati quando si compila il modulo è un segnale d’allarme.
Una Content-Security-Policy in modalità di sola segnalazione aiuta a rendere questo controllo continuo, perché il browser dei clienti segnala ogni script o destinazione non prevista:
Content-Security-Policy-Report-Only: script-src 'self' https://js.esempio-gateway.com;
connect-src 'self' https://api.esempio-gateway.com; report-uri /csp-reportLa versione 4.0 dello standard PCI DSS chiede espressamente ai negozi di tenere un inventario autorizzato degli script delle pagine di pagamento e di rilevarne le modifiche non autorizzate: controlli come questo servono anche a quello.
Cosa fare se lo trovi
Prima di rimuoverlo, conviene salvarne una copia e annotare il dominio di destinazione: sono informazioni utili per l’analisi e per il fornitore dei pagamenti, che va informato. Poi la pulizia deve andare oltre lo script visibile: trovare come è stato inserito, controllare tutte le sue copie nei file e nel database, eliminare la persistenza e cambiare tutte le credenziali, comprese le chiavi API del gateway. Il nostro caso di studio sull’e-commerce reinfettato ogni notte mostra come uno skimmer rimosso possa tornare in poche ore, se non si cerca anche a livello di sistema.
