Messa in sicurezza di un e-commerce

Tutto quello che segue è stato rilevato dal pannello di amministrazione, non stimato. Il quadro: una versione di Joomla uscita dal supporto da anni, senza più aggiornamenti di sicurezza, appoggiata a una versione di PHP altrettanto vecchia. Il catalogo contava migliaia di pagine digitalizzate, ciascuna col suo file da scaricare dopo l'acquisto, per un archivio di scansioni di parecchi gigabyte. Le estensioni erano 406, molte di software house che avevano chiuso o abbandonato il prodotto.

C'era poi un dato che ha orientato ogni scelta successiva: in dieci anni il negozio aveva raccolto pochissimi ordini reali, e un giro d'affari minimo. Averlo davanti ha evitato soluzioni sproporzionate: qualunque strumento con un canone fisso costerebbe più di quanto il negozio produce.

Fra gli utenti registrati una buona parte non era gente vera. Le firme sono riconoscibili: indirizzi su domini usa-e-getta, nome e cognome scollegati dall'indirizzo, schemi di nomi generati a macchina, e in un caso un «nome» che era una frase pubblicitaria.

Prima di cancellare, un controllo incrociato: nessuno dei sospetti doveva comparire in nessuno degli ordini storici. Verificate tutte le pagine della lista ordini, 16 account sono stati eliminati. Lasciati stare, invece, gli utenti con nomi strani ma legittimi — quelli in cui il numero in coda era l'anno di nascita.

Poi la zavorra: componenti mai usati, moduli di carrelli concorrenti installati e dimenticati, un vecchio negozio di prova con due prodotti finti del 2014, e due righe «fantasma» nel registro delle estensioni, con autore contraffatto e nessun file dietro. Le estensioni sono passate da 406 a 393, con verifica finale che non restasse nessun residuo.

Il componente più a rischio era un editor di testo fermo a una versione del 2018, nella fascia segnalata per una falla critica: quel difetto permette di far eseguire codice al server senza nemmeno una password, ed era già negli elenchi ufficiali delle vulnerabilità sfruttate attivamente.

Il rimedio è stato sostituire la versione commerciale scaduta con l'edizione gratuita mantenuta dello stesso prodotto, collegata al canale ufficiale di aggiornamento: da lì in avanti le correzioni arrivano da sole. È stato anche verificato che il sito non fosse già stato bucato: quel tipo di attacco lascia sempre una traccia riconoscibile nella configurazione, e quella traccia non c'era. Gli account con i privilegi massimi sono stati controllati uno per uno: tutti legittimi.

Il sintomo: due tabelle del database, quelle che tengono i carrelli della spesa, erano cresciute fino a oltre un milione e quattrocentomila righe. A fronte di una manciata di ordini reali in dieci anni.

La causa è emersa guardando il codice di una pagina prodotto. Il pulsante «aggiungi al carrello» non era un'azione protetta ma un semplice collegamento cliccabile: tra prodotti e varianti faceva migliaia di indirizzi diversi che qualsiasi programma automatico può seguire, e ogni volta che li segue il sito gli apre un carrello. Il file che dice ai motori di ricerca cosa non visitare avrebbe dovuto fermarli, ma conteneva una regola scritta al plurale mentre gli indirizzi veri erano al singolare: di fatto non escludeva niente. Fatto il conto — poche centinaia di visite automatiche al giorno per cinque anni — il numero tornava esatto.

La pulizia non è stata fatta con una cancellazione diretta: su un hosting condiviso, cancellare un milione e mezzo di righe significa bloccare il database e rischiare di interrompersi a metà. Si è usato un metodo più sicuro: costruire due tabelle nuove con dentro solo i carrelli degli ultimi sei mesi, poi scambiare i nomi in un colpo solo, lasciando le vecchie da parte come via di ritorno. Prima di toccare qualsiasi cosa, due controlli: che non ci fossero liste dei desideri da salvare, e che nessun'altra tabella collegasse gli ordini ai carrelli, così lo storico degli ordini restava intatto.

Le tabelle sono scese a poco più di 65.000 e 71.000 righe, con il catalogo pubblico verificato subito dopo. Per non rifare il lavoro fra due anni sono state aggiunte le regole giuste al file dei motori di ricerca.

Restava la domanda vera: aggiornare Joomla o cambiare del tutto? La risposta è stata cercata con dodici agenti di ricerca in parallelo, ciascuno su un pezzo del problema, più un passaggio di verifica critica incaricato di smontare le conclusioni degli altri.

L'esito è stato controcorrente: restare su Joomla e salire fino alla versione 6. Il passaggio a una piattaforma in abbonamento è stato scartato non per il canone, ma per un dettaglio concreto: ogni prodotto ha un file allegato, e lo strumento gratuito di quella piattaforma li carica uno alla volta. Con migliaia di file non si fa, e lo strumento a pagamento per il caricamento massivo sarebbe costato, da solo, più di quanto il negozio incassi in un anno.

Risultato: tabelle da oltre un milione di righe a poche decine di migliaia, 16 account falsi e 13 estensioni obsolete rimossi, la falla critica chiusa con un componente che ora si aggiorna da solo, e una scelta di piattaforma presa su numeri misurati.