Sicurezza dei pagamenti: PCI e frodi

Modulo 6: Gestione e sicurezza · Tempo di lettura: 11 minuti

Obiettivo della lezione: Al termine di questa lezione saprà spiegare perché un negozio non tratta mai direttamente i dati delle carte, che cosa significano PCI DSS e SAQ A per un piccolo negozio, come proteggere la pagina di pagamento e come riconoscere e limitare le frodi e il card testing.

Concetti chiave: PCI DSS, dati delle carte, fornitore di pagamento, reindirizzamento alla pagina di pagamento, modulo di pagamento incorporato (iframe), SAQ A, script sulla pagina di pagamento, e-skimming, https, HSTS, card testing, rate limiting, captcha, 3-D Secure, storno (chargeback), rischio di frode

I dati delle carte non devono entrare nel Suo negozio

Un numero di carta di credito, la data di scadenza e il codice di sicurezza valgono oro per i criminali. Chi li conserva o li trasmette rientra nel PCI DSS (Payment Card Industry Data Security Standard), lo standard di sicurezza dei circuiti di pagamento. La versione attuale è la v4.0.1. Per un'azienda che tratta direttamente i dati delle carte, si tratta di un insieme consistente di requisiti: separazione delle reti, registri, scansioni, test da parte di un soggetto accreditato.

Un piccolo negozio non vuole trovarsi in questa situazione, e non ne ha bisogno. La regola fissa: i dati delle carte non entrano mai nel Suo negozio. Il cliente li inserisce presso il Suo fornitore di pagamento (Mollie, Stripe, PayPal, WooPayments o un altro, lezione 4.4). Il negozio riceve poi solo l'esito: pagato o no, con un riferimento. Nessun numero di carta, nessun codice. Ciò significa anche:

• non creare mai un proprio campo del modulo per i numeri di carta, nemmeno "solo per un ordine telefonico";
• non accettare mai dati delle carte via email, chat o telefono per poi annotarli in una nota dell'ordine;
• non usare plugin che conservano i dati delle carte nel Suo database.

Reindirizzamento o modulo incorporato: SAQ A

I piccoli negozi dimostrano di rispettare il PCI DSS con un SAQ (Self-Assessment Questionnaire, un questionario di autovalutazione). A volte è il fornitore di pagamento a chiederlo. Il più leggero è il SAQ A, per i negozi che affidano completamente all'esterno il pagamento. In un negozio questo funziona in due modi:

1. Reindirizzamento. Dopo l'ordine il cliente va alla pagina di pagamento del fornitore e poi torna indietro. Il negozio non vede mai i dati delle carte, nemmeno la pagina in cui vengono inseriti.
2. Modulo incorporato. Il campo di pagamento si trova nella Sua pagina di pagamento, ma è un iframe (una porzione di pagina) del fornitore. I dati delle carte passano direttamente dal browser al fornitore.

Dal 31 marzo 2025 vale una nuova versione del SAQ A. Contiene una condizione che riguarda soprattutto il secondo modo: chi usa un modulo incorporato deve confermare che il proprio sito non è vulnerabile ad attacchi tramite script che possono colpire il sistema di pagamento. Il motivo è l'e-skimming: uno script malevolo sulla pagina di pagamento che legge ciò che il cliente digita, oppure sovrappone un falso campo di pagamento a quello vero. Chi reindirizza alla pagina del fornitore non rientra in questa condizione. Chieda al Suo fornitore di pagamento quale SAQ vale per la Sua integrazione: lo sa con precisione.

Ciò che deve fare in ogni caso:

• Mantenga la pagina di pagamento essenziale. In linea di principio ogni script su quella pagina può leggere i dati: widget di chat, tag manager, pixel pubblicitari, strumenti di test A/B. Sulla pagina di pagamento carichi solo ciò che serve per il pagamento. Un tag manager sulla pagina di pagamento è una porta attraverso cui chiunque abbia accesso a quell'account può aggiungere script.
• Pochi plugin, e aggiornati (lezione 6.2). La maggior parte dell'e-skimming su WordPress entra attraverso una falla in un plugin o una password di amministratore rubata.
• Una Content-Security-Policy (un'intestazione che indica da quali domini possono provenire gli script) limita i danni se qualcosa riesce comunque a entrare. È un lavoro per qualcuno in grado di testarla: una CSP sbagliata blocca il Suo pulsante di pagamento.

https e HSTS sulla pagina di pagamento

Che l'intero negozio funzioni tramite https è scontato (corso WordPress, lezione 3.1). Per la pagina di pagamento si aggiungono due cose:

• http deve reindirizzare subito a https, con un reindirizzamento permanente (301 o 308). Un cliente che digita http://shop.example.com/afrekenen/ non deve ricevere una pagina non cifrata.
• HSTS (HTTP Strict Transport Security) è un'intestazione con cui chiede al browser di aprire il Suo sito per un certo periodo solo tramite https. In questo modo impedisce che qualcuno su una rete wifi aperta intercetti la prima richiesta non cifrata. Un max-age di almeno 180 giorni è un minimo diffuso. Attivi HSTS solo quando tutto, compresi i sottodomini che include, funziona tramite https: un browser che ha visto HSTS rifiuta poi http. KB 6752 spiega come configurarlo.

Il contenuto misto (uno script o un foglio di stile tramite http su una pagina https) sulla pagina di pagamento è particolarmente pericoloso: è proprio un file del genere che può essere sostituito durante il percorso.

Card testing

Nel card testing i criminali usano il Suo negozio per provare numeri di carta rubati. Inviano automaticamente centinaia di piccoli ordini. Ogni pagamento riuscito dice loro che una carta funziona. Lei si ritrova con una pila di ordini non riusciti, costi per transazione, storni e, nel caso peggiore, un fornitore di pagamento che blocca il Suo account.

Come riconoscerlo: molti ordini in poco tempo, spesso dello stesso prodotto economico, con nomi diversi ma indirizzi uguali o strani, e molti ordini con stato Non riuscito.

Come limitarlo:

• Rate limiting (un limite al numero di richieste per unità di tempo). La Store API di WooCommerce, usata dai blocchi del carrello e del pagamento, ha un rate limiting integrato, ma è disattivato per impostazione predefinita. In WooCommerce > Impostazioni > Avanzate > Funzionalità può attivare "Rate limiting Checkout block and Store API" per l'invio degli ordini. Con del codice (un filtro) può impostare Lei il limite; il valore predefinito è 25 richieste ogni 10 secondi e contano solo gli ordini e le altre azioni di scrittura. Se il Suo negozio si trova dietro un proxy o una CDN, deve attivare il supporto per il proxy, altrimenti tutti i visitatori contano come uno solo.
• Un captcha o un ostacolo simile al momento del pagamento. WooCommerce stessa afferma che rate limiting e captcha funzionano meglio insieme: gli aggressori cambiano spesso indirizzo IP.
• Le impostazioni del Suo fornitore di pagamento. I fornitori hanno propri filtri antifrode e limiti. Li attivi e controlli che cosa segnalano.
• 3-D Secure (la conferma aggiuntiva nell'app della banca, parte dell'autenticazione forte del cliente nell'UE) rende la vita più difficile ai criminali e in caso di contestazione sposta spesso la responsabilità sulla banca del titolare della carta.

Altre frodi

Non tutte le frodi sono automatizzate. Segnali che, sommati, sono un motivo per attendere un attimo prima di spedire:

• indirizzo di fatturazione e di consegna in paesi diversi, oppure un indirizzo di consegna presso un servizio di inoltro;
• un primo ordine con soli prodotti costosi e facili da rivendere, con spedizione urgente;
• più tentativi con carte diverse;
• un cliente che dopo il pagamento chiede di spedire a un altro indirizzo.

Uno storno (chargeback) è l'annullamento di un pagamento con carta da parte della banca del cliente. Lei perde l'importo, spesso con dei costi, e il prodotto non c'è più. Conservi quindi la prova di spedizione e di consegna. Finora un pagamento iDEAL (Paesi Bassi) non poteva essere annullato in questo modo; come funziona con Wero glielo dirà il Suo fornitore di pagamento (lezione 4.4). In Italia i metodi di pagamento diffusi sono carte di pagamento, PayPal, Satispay, bonifico e contrassegno: chieda al Suo fornitore come funzionano le contestazioni per ciascuno.

Riepilogo

• I dati delle carte non entrano mai nel Suo negozio: né nei moduli, né nelle note, né nelle email. Li tratta il fornitore di pagamento.
• Il reindirizzamento alla pagina di pagamento o un campo incorporato del fornitore La mantiene nel questionario PCI più leggero (SAQ A); con un campo incorporato la Sua pagina di pagamento deve essere protetta dagli attacchi tramite script.
• Mantenga la pagina di pagamento essenziale, tramite https con un 301 da http e con HSTS di almeno 180 giorni.
• Il card testing si limita con il rate limiting (disattivato per impostazione predefinita), un captcha e i filtri del Suo fornitore.
• Faccia attenzione ai segnali di frode e conservi la prova di consegna contro gli storni. Per un negozio in Italia i metodi di pagamento diffusi sono carte di pagamento, PayPal, Satispay, bonifico e contrassegno.

Quiz

Esercizio

Esercizio A6.3: La Sua pagina di pagamento è sicura? Inserisca l'indirizzo del Suo negozio e l'indirizzo della Sua pagina di pagamento. Il programma verifica il certificato, richiede la pagina di pagamento tramite http (senza seguire il reindirizzamento) e tramite https (con il carrello vuoto, non viene ordinato nulla). Verde se il certificato è valido, http reindirizza a https con 301 o 308, l'intestazione Strict-Transport-Security ha un max-age di almeno 180 giorni, non c'è contenuto misto e al massimo cinque altri domini caricano script sulla pagina (il programma li mostra). Arancione in caso di HSTS assente o troppo breve, un reindirizzamento temporaneo (302 o 307), più di cinque domini di script o un tag manager, oppure un campo per il numero di carta nel proprio HTML anziché presso il fornitore. Rosso se https o il certificato non sono corretti, se http non reindirizza o se script o fogli di stile vengono caricati tramite http. Non conservi mai Lei stesso i dati delle carte. Questo controllo vede solo ciò che si trova sulla pagina senza carrello.

Domanda per Lei (non verificata): il Suo plugin di pagamento reindirizza al fornitore, oppure il campo di pagamento si trova nella Sua pagina? Quale SAQ vale secondo il Suo fornitore?

Una spunta verde significa che questo controllo ora è superato, non che il Suo negozio è sicuro.

Per saperne di più

I passaggi in un pannello valgono per WebOké; con altri fornitori il funzionamento è simile.

• Corso gratuito WordPress 3.1: Https e il certificato
• Intestazioni HSTS e di sicurezza per il Suo sito web
• Reindirizzare obbligatoriamente i visitatori su https
• Guida DirectAdmin 6.4: Reindirizzare sempre i visitatori a https
• Corso gratuito Sicuri online per imprenditori 4.2: Il Suo sito web: https, HSTS e header di sicurezza
• Aggiornamenti del SAQ A (PCI Security Standards Council, in inglese): https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
• Rate limiting per la Store API (developer.woocommerce.com, in inglese): https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/
• Card testing attacks and the Store API (developer.woocommerce.com, in inglese): https://developer.woocommerce.com/2024/12/18/card-testing-attacks-and-the-store-api/