Web Skimming: Come Rubano i Dati delle Carte di Credito dal Vostro E-Commerce

Da qualche parte in questo momento, un piccolo negozio e-commerce sta processando ordini normalmente. La pagina di checkout funziona, i pagamenti vanno a buon fine, i clienti ricevono i loro prodotti. Tutto sembra a posto. Ma su ogni ordine, poche righe di JavaScript iniettato stanno silenziosamente copiando il numero della carta di credito, la data di scadenza, il CVV e il nome del titolare e inviandoli a un server controllato da criminali.

Questo e il web skimming. Chiamato anche attacchi Magecart (dal consorzio di gruppi criminali che ha pionierato la tecnica), formjacking o skimming digitale delle carte. E l'equivalente online dei dispositivi skimmer fisici che i criminali attaccano agli sportelli ATM. Solo che e invisibile, scala a milioni di transazioni e la maggior parte delle vittime non sa che sta accadendo finche la banca non chiama.

Come Funziona il Web Skimming

Il concetto fondamentale e semplice: iniettare codice JavaScript in una pagina di checkout che cattura i dati del form di pagamento e li invia a un server controllato dall'attaccante. L'implementazione varia, ma le tecniche principali sono:

Keylogging

Lo script iniettato attacca event listener ai campi del form di pagamento. Ogni battitura viene catturata e registrata. Quando il form viene inviato (o a intervalli regolari), i dati catturati vengono inviati al server di raccolta dell'attaccante.

Nella realta, gli script di skimming sono pesantemente offuscati per evitare il rilevamento. Usano nomi di variabili codificati, stringhe divise, costruzione dinamica di funzioni e altre tecniche per rendere il codice illeggibile.

Form Grabbing

Invece di catturare le singole battiture, lo script intercetta l'evento di invio del form. Quando il cliente clicca "Paga" o "Invia Ordine," lo script prende tutti i valori dei campi prima o contemporaneamente all'invio legittimo. Il pagamento del cliente va a buon fine normalmente, ma i dati della carta sono stati copiati e inviati all'attaccante.

Iniezione di Iframe

L'attaccante sostituisce il form di pagamento legittimo con uno falso renderizzato in un iframe. Il form falso appare identico a quello reale (stesso stile, stessi campi, stesso pulsante). Il cliente inserisce i dettagli della carta nel form dell'attaccante, che cattura i dati e poi reindirizza al form di pagamento reale o mostra un falso messaggio di errore chiedendo di reinserire i dettagli.

Attacchi Overlay

Simili all'iniezione di iframe, ma invece di sostituire il form di pagamento, l'attaccante sovrappone un form invisibile o trasparente sopra quello legittimo. Il cliente pensa di digitare nel form reale, ma il suo input va prima all'overlay dell'attaccante.

Come gli Attaccanti Inseriscono il Loro Codice nella Pagina di Checkout

1. Compromissione Diretta del Sito

L'attaccante sfrutta una vulnerabilita nella piattaforma e-commerce (CMS non aggiornato, plugin vulnerabile, credenziali admin deboli) e modifica direttamente il template della pagina di checkout.

2. Compromissione di Script di Terze Parti

Molte pagine di checkout caricano script da servizi di terze parti: analytics, A/B testing, widget chat, tracking pubblicitario, piattaforme di recensioni. Se l'attaccante compromette qualsiasi di questi servizi, il loro codice di skimming gira su ogni sito che carica lo script compromesso.

Per un'analisi approfondita dei rischi degli script di terze parti, vedete il nostro articolo sui rischi del JavaScript di terze parti.

3. Iniezione Lato Server

In alcuni casi, l'attaccante modifica il codice lato server per iniettare lo script di skimming dinamicamente nella risposta HTML. E piu difficile da rilevare perche il codice malevolo non esiste nei file statici.

Casi Reali

British Airways (2018)

Gli attaccanti hanno compromesso un file JavaScript sul sito di British Airways e iniettato uno script di skimming che catturava i dettagli delle carte di pagamento inseriti nelle pagine di prenotazione e pagamento. L'attacco e durato circa due settimane e ha colpito circa 380.000 transazioni.

British Airways e stata multata per 20 milioni di sterline dall'ICO del Regno Unito ai sensi del GDPR.

Ticketmaster (2018)

Ticketmaster caricava un chatbot di supporto clienti da un fornitore terzo chiamato Inbenta. Gli attaccanti hanno compromesso i server di Inbenta e modificato il file JavaScript che Ticketmaster caricava sulle sue pagine di pagamento. Il codice di skimming ha catturato dettagli di pagamento per diversi mesi.

Questo caso evidenzia il rischio della supply chain: i server di Ticketmaster non sono mai stati direttamente compromessi.

Piccoli Siti E-Commerce

La stragrande maggioranza degli attacchi di web skimming colpisce piccoli e medi siti e-commerce. Questi siti hanno meno probabilita di avere monitoraggio di sicurezza e spesso girano software non aggiornato.

Un piccolo negozio online in Ticino che processa 50 ordini al giorno e un bersaglio valido. Se lo skimmer gira per tre mesi, sono circa 4.500 numeri di carta rubati, ciascuno del valore di CHF 10-50 sul mercato nero. Sono CHF 45.000-225.000 di valore per l'attaccante, da un singolo piccolo negozio.

Requisiti di Conformita PCI DSS

Se processate, conservate o trasmettete dati di carte di credito, dovete conformarvi al Payment Card Industry Data Security Standard (PCI DSS).

PCI DSS 4.0 e Sicurezza Lato Client

• Requisito 6.4.3: Tutti gli script delle pagine di pagamento che vengono caricati ed eseguiti nel browser del consumatore devono essere gestiti. Dovete mantenere un inventario di tutti gli script, giustificare ciascuno e implementare controlli di integrita.
• Requisito 11.6.1: Un meccanismo di rilevamento di modifiche e manomissioni deve essere implementato sulle pagine di pagamento per avvisare il personale di modifiche non autorizzate agli header HTTP e al contenuto degli script.

Questi requisiti sono diventati obbligatori a marzo 2025.

Come Rilevare il Web Skimming

1. Reportistica Content Security Policy

Implementate una CSP con reportistica. La CSP dice al browser quali domini possono caricare script e inviare dati. Quando uno skimmer tenta di inviare dati rubati a un dominio non autorizzato, la CSP lo blocca e invia un report.

2. Subresource Integrity (SRI)

Aggiungete hash di integrita a tutti gli script esterni caricati sulle pagine di pagamento. Se uno script viene modificato, l'hash non corrispondera e il browser rifiutera di eseguirlo.

3. Audit Regolare degli Script

Periodicamente verificate tutti gli script che girano sulla vostra pagina di checkout. Aprite gli strumenti sviluppatore, controllate ogni script che si carica. Ci sono script da domini che non riconoscete?

4. Monitoraggio dell'Integrita dei File

Monitorate i file del sito per modifiche non autorizzate. Qualsiasi modifica ai template delle pagine di checkout deve attivare un avviso.

5. Servizi di Scansione Esterni

Diverse aziende di sicurezza offrono servizi che scansionano regolarmente le vostre pagine di pagamento dall'esterno, simulando un utente reale.

Difesa: Content Security Policy

La CSP e la difesa singola piu efficace contro il web skimming. Una CSP configurata correttamente puo impedire agli script di skimming di esfiltrare i dati rubati, anche se lo script viene iniettato con successo nella pagina.

Per una pagina di pagamento, volete una CSP restrittiva:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://vostro-provider-pagamento.com;
  connect-src 'self' https://api.vostro-provider-pagamento.com;
  frame-src 'self' https://vostro-provider-pagamento.com;
  style-src 'self';
  img-src 'self' data:;
  font-src 'self';
  object-src 'none';
  form-action 'self' https://vostro-provider-pagamento.com;

Anche se un attaccante inietta uno script di skimming, non puo inviare i dati rubati da nessuna parte perche la CSP blocca le connessioni in uscita verso domini non autorizzati.

Difesa: Usare l'Elaborazione dei Pagamenti Lato Server

La difesa architettonica piu efficace e non far mai passare i dati delle carte di credito attraverso il frontend del vostro sito. Provider di pagamento come Stripe, Adyen e PayPal offrono pagine di pagamento ospitate o tokenizzazione che processa i dati delle carte interamente sull'infrastruttura del provider.

Con una pagina di pagamento ospitata, il cliente inserisce i dettagli della carta sul dominio del provider di pagamento, non sul vostro. Anche se il vostro sito e completamente compromesso, l'attaccante non puo fare skimming dei dati delle carte perche non appaiono mai sulle vostre pagine.

Perche i Siti E-Commerce Svizzeri Sono Bersagli

• Valori medi delle transazioni piu alti: I consumatori svizzeri spendono piu per transazione rispetto alla maggior parte dei paesi europei.
• Consapevolezza di sicurezza inferiore: Molti siti e-commerce svizzeri, specialmente quelli piu piccoli, non implementano CSP, SRI o audit di sicurezza regolari.
• Piattaforme non aggiornate: Troviamo regolarmente siti e-commerce svizzeri che girano versioni non aggiornate di Magento, WooCommerce o PrestaShop.
• Fattore fiducia: I domini svizzeri portano fiducia. I dati delle carte rubati da siti e-commerce svizzeri spuntano prezzi piu alti sui mercati dark perche le carte hanno piu probabilita di essere carte premium con limiti piu alti.

Responsabilita Finanziaria e Legale

Finanziaria

• Multe PCI DSS: I circuiti di carte possono imporre multe da $5.000 a $100.000 al mese per non conformita.
• Costi di indagine forense: Dovete assumere un PCI Forensic Investigator. Costo tipico: CHF 20.000-100.000.
• Costi di riemissione delle carte: Potreste essere responsabili del costo di riemissione delle carte compromesse.
• Perdita dell'elaborazione dei pagamenti: La vostra banca potrebbe terminare il vostro conto merchant.

Legale

• GDPR / nLPD: I dati delle carte di credito sono dati personali. Una violazione attiva gli obblighi di notifica sia ai sensi del GDPR che della nLPD svizzera.
• Responsabilita civile: I clienti colpiti possono fare causa per danni.
• Danno reputazionale: La notizia di una violazione dei dati di pagamento puo danneggiare permanentemente la fiducia dei clienti.

Cosa Fare Ora

1. Auditate la vostra pagina di checkout. Aprite gli strumenti sviluppatore e verificate ogni script caricato.
2. Implementate la Content Security Policy sulle pagine di pagamento.
3. Aggiungete hash SRI a tutti gli script esterni sulle pagine di pagamento.
4. Considerate pagine di pagamento ospitate o tokenizzazione per rimuovere completamente i dati delle carte dal vostro sito.
5. Aggiornate la piattaforma e-commerce e tutti i plugin.
6. Impostate il monitoraggio dell'integrita dei file per i file delle pagine di checkout.
7. Verificate i requisiti PCI DSS 4.0 per la sicurezza lato client.

Per uno sguardo completo sulle vulnerabilita delle applicazioni web, vedete la nostra guida sulla OWASP Top 10.

Se gestite un sito e-commerce e volete una valutazione professionale della sicurezza del vostro flusso di pagamento, contattate il nostro team. Siamo specializzati nell'aiutare le aziende svizzere a proteggere i loro negozi online e conformarsi ai requisiti PCI DSS.