Perché attaccano anche i siti piccoli

La frase che sentiamo più spesso, quando un sito viene compromesso, è sempre la stessa: «ma il mio sito ha poche visite, chi vuoi che si metta ad attaccarlo?». È una domanda del tutto ragionevole, e nasce da un'idea intuitiva di come funzionino gli attacchi informatici: qualcuno sceglie un bersaglio, studia, colpisce. Nella realtà del web, per la stragrande maggioranza dei casi, funziona in modo completamente diverso — e capire come funziona è il primo passo per difendersi con criterio invece che a sensazione.

In questo articolo mettiamo in fila tre cose: l'anatomia reale di un attacco automatizzato, il diverso profilo di rischio delle piattaforme che usiamo tutti i giorni (WordPress, PrestaShop, sviluppi custom) e — la parte che di solito manca — chi risponde di cosa, quando un sito è gestito da più fornitori.

Nessuno ha scelto il tuo sito

Gli attacchi di massa non partono da una lista di bersagli, partono da una lista di vulnerabilità. Il meccanismo è industriale e si svolge in cinque fasi.

1. Scoperta. Reti di macchine compromesse (botnet) scandagliano interi blocchi di indirizzi IP e leggono i Certificate Transparency log, i registri pubblici in cui finisce ogni certificato SSL emesso al mondo. Significa che nel momento esatto in cui attivi l'HTTPS su un dominio nuovo, quel dominio diventa pubblicamente noto e finisce nelle code di scansione, spesso nel giro di pochi minuti.

2. Riconoscimento. Il bot chiede al sito una manciata di file e risposte che rivelano cosa sta girando sotto: il meta tag generator, il percorso degli asset, i file readme, gli endpoint delle API, i nomi delle cartelle dei moduli. In pochi secondi sa che sei su WordPress 6.x con quei dodici plugin, o su PrestaShop 1.7 con quel tema e quei moduli, e con quale versione di PHP.

3. Confronto. Quell'impronta viene confrontata con un archivio di vulnerabilità note, aggiornato in tempo reale. Quando una falla viene resa pubblica, il codice per sfruttarla circola nelle ore successive: la finestra tra la pubblicazione della patch e il primo tentativo di sfruttamento di massa si misura in ore, non in mesi.

4. Sfruttamento. Se c'è corrispondenza, il tentativo parte da solo. Nessun essere umano coinvolto, nessuna valutazione sul valore del bersaglio. Il costo marginale di provarci sul tuo sito è vicino allo zero, quindi ci provano su tutti.

5. Persistenza. Questa è la fase che quasi nessuno vede, ed è la più importante. Ottenuto l'accesso, l'obiettivo non è fare danni subito: è restare. Vengono seminate più backdoor indipendenti in punti diversi, così che rimuoverne una non chiuda la partita. Su WordPress, tipicamente: un file mascherato dentro wp-content/uploads (una cartella che nessuno guarda mai e che spesso è scrivibile), una utenza amministratore dal nome plausibile, un plugin "must-use" che non compare nella lista dei plugin dell'amministrazione, del codice offuscato in coda a wp-config.php o a functions.php del tema, e un'attività pianificata che rimette tutto a posto se qualcuno cancella qualcosa.

Il punto da portare a casa è questo: il traffico del tuo sito non c'entra nulla. Quello che ha valore non sono i tuoi visitatori, è la risorsa in sé — uno spazio web funzionante, con un dominio che ha una reputazione pulita, una casella di posta che può inviare e un po' di potenza di calcolo. Da quel punto di vista un sito vetrina con dieci visite al giorno vale esattamente quanto un portale con diecimila.

A cosa serve, un sito bucato

Vale la pena essere concreti su cosa succede dopo, perché aiuta a capire perché il danno non è mai solo "il sito non si vede".

• Spam SEO. Vengono pubblicate centinaia di pagine nascoste (visibili solo a Google, non a te) che vendono farmaci, scommesse o repliche, sfruttando l'autorevolezza del tuo dominio. Il risultato è che il tuo sito viene penalizzato o rimosso dai risultati di ricerca, e recuperare posizionamento richiede mesi.
• Phishing. Sul tuo dominio viene ospitata una finta pagina di login di una banca o di un servizio di posta. Quando la segnalazione arriva, il dominio finisce nelle liste nere dei browser e degli antivirus: i tuoi clienti vedono la schermata rossa "sito ingannevole".
• Invio di posta. Il server viene usato come relè per campagne di spam. Conseguenza diretta: l'IP e il dominio finiscono in blacklist e le tue mail ordinarie — preventivi, conferme d'ordine, fatture — smettono di essere consegnate. È spesso il danno più costoso e il più difficile da ricostruire.
• Furto di dati e skimming. Su un eCommerce, l'attacco più redditizio non blocca niente: inietta poche righe di JavaScript nella pagina di checkout che copiano i dati della carta mentre il cliente li digita. Il sito funziona perfettamente, gli ordini arrivano, e la compromissione può passare inosservata per mesi. Qui si entra nel territorio della violazione di dati personali, con obblighi di notifica al Garante entro 72 ore.
• Cryptomining e botnet. Il tuo hosting lavora per qualcun altro: rallentamenti, consumo di risorse, e il tuo server che partecipa ad attacchi verso terzi.

Perché di sabato, e perché a Ferragosto

Non è una coincidenza né una leggenda da addetti ai lavori. Per chi attacca, il momento del lancio è quasi irrilevante — è tutto automatizzato — ma è decisivo il tempo di reazione di chi difende. Colpire il venerdì sera, il sabato mattina o nella settimana di Ferragosto significa comprare due o tre giorni di lavoro indisturbato: il tempo di piazzare le backdoor, creare le utenze, esfiltrare quello che c'è da esfiltrare e consolidare la presenza prima che qualcuno apra il sito e si accorga che qualcosa non va.

Non è un'impressione: FBI e CISA hanno pubblicato un avviso congiunto proprio su questo schema, dopo aver osservato un aumento sistematico degli incidenti a ridosso di fine settimana e festività. La lezione operativa è che la sicurezza non si misura solo in quanto sei difficile da bucare, ma in quanto ci metti ad accorgertene. Un monitoraggio automatico che ti avvisa entro l'ora vale, in pratica, più di metà delle contromisure preventive.

WordPress: non è il codice, è la scala

WordPress si porta addosso la fama di piattaforma insicura, ed è una fama in buona parte ingiusta. Il nucleo di WordPress è software maturo, con un team di sicurezza serio, aggiornamenti automatici per le patch critiche e un processo di divulgazione responsabile. I report annuali di settore sono concordi: oltre il 90% delle vulnerabilità sfruttate non è nel core, ma nei plugin e nei temi di terze parti.

Il problema di WordPress è di natura diversa, e sono due fattori che si moltiplicano fra loro.

La scala. WordPress fa girare circa il 43% dei siti web del mondo. Per chi sviluppa un exploit automatico, è di gran lunga l'investimento con il ritorno migliore: scrivi una volta, lo lanci su decine di milioni di bersagli. Nessun'altra piattaforma offre questo rapporto.

La catena di fornitura. L'ecosistema conta decine di migliaia di plugin, di qualità enormemente disomogenea. Ogni plugin installato è codice di un terzo che gira con i pieni privilegi del tuo sito e accesso completo al database. E il rischio non è solo il bug: ci sono plugin abbandonati dall'autore che restano installati per anni senza più ricevere patch, e casi documentati di plugin popolari acquistati da terzi per poi inserirvi codice malevolo tramite un aggiornamento perfettamente regolare.

Cosa fa la differenza, in pratica, su un WordPress:

• Ridurre il numero di plugin è la singola misura più efficace in assoluto. Ogni plugin rimosso è superficie d'attacco che sparisce. Vale la pena chiedersi, per ciascuno, se serve davvero e se è ancora mantenuto.
• Aggiornare in tempi brevi, con un ritmo definito, non "quando capita". Data la finestra di poche ore di cui sopra, un ciclo mensile non è abbastanza per i componenti esposti.
• Autenticazione a due fattori su tutte le utenze amministrative, più limitazione dei tentativi di accesso. Il credential stuffing — provare a raffica password rubate da altre violazioni — resta una delle vie d'ingresso più comuni e più banali.
• Disattivare l'editor di file dal pannello (DISALLOW_FILE_EDIT): toglie all'attaccante che ottiene un accesso amministrativo il modo più rapido per trasformarlo in esecuzione di codice.
• Impedire l'esecuzione di PHP nelle cartelle di upload: neutralizza in un colpo solo la famiglia di attacchi che carica una webshell mascherata da immagine.
• Un firewall applicativo (WAF) davanti al sito, che blocca gli schemi di attacco noti prima ancora che arrivino a PHP. È la rete di protezione per la finestra tra la scoperta di una falla e il momento in cui riesci ad aggiornare.

PrestaShop: superficie più stretta, posta in gioco più alta

PrestaShop parte da una posizione strutturalmente migliore, e per ragioni concrete, non di marketing.

Un bersaglio meno remunerativo per gli attacchi di massa. La base installata è di ordini di grandezza inferiore a quella di WordPress: gli exploit automatici generici vengono scritti per WordPress, perché è lì che il rapporto sforzo/risultato torna. Non è "sicurezza per oscurità" — è semplice economia dell'attaccante, e ha un effetto reale e misurabile sul volume dei tentativi che il tuo sito riceve ogni giorno.

Un ecosistema più professionale. Il marketplace ufficiale dei moduli ha una soglia d'ingresso e un processo di validazione, e chi sviluppa moduli per PrestaShop lo fa quasi sempre come attività commerciale strutturata, non come progetto gratuito del fine settimana. Il tasso di abbandono è nettamente inferiore.

Un'architettura più rigorosa. Il framework impone convenzioni (ORM, override controllati, token anti-CSRF nel back office, separazione netta tra front e back) che rendono più difficile scrivere per sbaglio codice vulnerabile, rispetto alla libertà quasi totale che WordPress concede a un autore di plugin.

Detto questo, va detto con altrettanta chiarezza che PrestaShop non è invulnerabile, e chi sostiene il contrario non aiuta nessuno. Il caso più istruttivo è l'ondata del 2022: una catena d'attacco che partiva da una SQL injection in un modulo di terze parti non aggiornato e la trasformava in esecuzione di codice sfruttando la cache Smarty su database. Gli attaccanti iniettavano un finto modulo di pagamento nella pagina di checkout per raccogliere i dati delle carte. PrestaShop pubblicò un avviso di sicurezza dedicato, con l'indicazione di disattivare la funzione di cache Smarty su MySQL. Due lezioni valide ancora oggi: l'anello debole resta il modulo di terze parti non aggiornato, e su un eCommerce l'attacco più redditizio è quello che non rompe niente.

Su PrestaShop, quindi, la posta in gioco è più alta: si maneggiano dati di pagamento e anagrafiche di clienti. Le priorità cambiano di conseguenza — inventario aggiornato dei moduli installati con le rispettive versioni, controllo periodico dell'integrità dei file del checkout, una Content Security Policy che impedisca a JavaScript non autorizzato di girare nelle pagine di pagamento, back office non raggiungibile dal mondo intero, e cifratura dei dati sensibili a riposo.

Piattaforme custom: nessuna impronta pubblica, tutta la responsabilità sullo sviluppatore

Il terzo scenario è quello dei gestionali e delle applicazioni sviluppate su misura. Qui il profilo di rischio si ribalta, e va capito bene in entrambe le direzioni.

Il vantaggio è reale. Un'applicazione custom non ha un'impronta riconoscibile: non esiste un readme.html che dichiara la versione, non esistono percorsi noti da provare, non esiste un archivio pubblico di vulnerabilità "per il tuo software" perché il tuo software esiste in un solo esemplare. Le scansioni di massa descritte all'inizio, semplicemente, non trovano corrispondenze e passano oltre. Questo elimina di fatto l'intera categoria degli attacchi automatici — che è la categoria da cui proviene la larghissima maggioranza delle compromissioni reali.

Lo svantaggio è altrettanto reale. Non c'è una comunità mondiale che verifica il codice, non arrivano aggiornamenti di sicurezza dall'esterno, e nessuno ti avvisa se c'è una falla. La sicurezza coincide integralmente con la disciplina di chi ha scritto e mantiene il codice. Un'applicazione custom scritta male è più pericolosa di un WordPress tenuto bene, e va detto senza giri di parole. L'assenza di impronta pubblica è un vantaggio che si somma alle buone pratiche, non una che le sostituisce.

Le pratiche che, nella nostra esperienza, fanno davvero la differenza su un progetto custom:

• Query esclusivamente parametrizzate (prepared statement), che chiudono per costruzione l'intera famiglia delle SQL injection.
• Segreti fuori dalla cartella pubblica. Chiavi API, password di database e token non stanno mai in un file raggiungibile via web, e le cartelle di sistema non vengono mai esposte. Un errore classico e disastroso è inizializzare un repository Git nella radice del sito: rende scaricabile l'intera cronologia del codice, segreti compresi.
• Credenziali cifrate a riposo nel database, non in chiaro. Se il database viene letto, il contenuto sensibile resta illeggibile.
• Intestazioni di sicurezza e CSP configurate a livello di server, per limitare cosa il browser può eseguire e caricare.
• Blocco esplicito dei file sensibili per estensione (.env, .sql, .log, backup) direttamente nella configurazione del web server, come seconda linea di difesa rispetto al non pubblicarli.
• Backup notturni verificati e conservati fuori dal server di produzione, con ripristino provato almeno una volta. Un backup mai testato non è un backup: è una speranza.
• Monitoraggio automatico di disponibilità e integrità, con avviso immediato. Torniamo al punto di prima: contro un attacco del sabato mattina, il monitoraggio vale quanto la prevenzione.

Chi risponde di cosa: la zona grigia dove nascono i guai

Questa è la parte che manca quasi sempre, ed è quella che nella pratica determina se un incidente viene gestito in due ore o in due settimane. Quando un sito è seguito da più fornitori — uno per l'hosting, uno per il CMS, magari un terzo per il marketing — la sicurezza non ha un proprietario unico, e le compromissioni si annidano esattamente nelle zone che ciascuno dà per scontato siano coperte da qualcun altro.

La divisione corretta, in sintesi:

Un sito compromesso attraverso un plugin non aggiornato non è un problema di hosting. Un server con una versione di PHP fuori supporto non è un problema del CMS. Ma l'ultima riga — la sorveglianza — è quella che nella maggior parte dei casi non è assegnata a nessuno, e infatti è quella che salta per prima. Se hai più fornitori, la domanda giusta da porre non è «il mio sito è sicuro?» ma «chi se ne accorge, e in quanto tempo?».

"Ripulito" non vuol dire "risolto"

Ultima distinzione, e non è pedanteria: è la differenza tra un incidente chiuso e uno che si ripresenta.

Ripulire significa rimuovere i file infetti e rimettere il sito online. È l'urgenza, si fa per prima, ed è quello che rende di nuovo visibile il sito.

Risolvere è un'altra cosa, e comprende: individuare la via d'ingresso analizzando i log del server (senza di che si lavora alla cieca), chiudere quella specifica falla, cercare e rimuovere tutti i meccanismi di persistenza — utenze create, attività pianificate, plugin fantasma, codice iniettato nei file di configurazione — ruotare ogni credenziale che l'attaccante potrebbe aver letto (database, FTP, pannello, API, posta), verificare che i backup a cui si pensa di tornare siano precedenti alla compromissione, e infine chiedersi se ci sono stati dati personali coinvolti, perché in quel caso scattano obblighi normativi con tempi stretti.

Se ci si ferma alla pulizia, la reinfezione arriva. Non perché qualcuno ce l'abbia con te: perché la stessa botnet ripasserà, troverà la stessa porta ancora aperta e rifarà esattamente quello che aveva già fatto. È il motivo per cui certi siti sembrano essere "sfortunati" e vengono bucati tre volte in un mese.

In sintesi

Non esiste una piattaforma sicura e una insicura: esistono profili di rischio diversi, che vanno gestiti in modo diverso. WordPress paga la propria diffusione e la qualità disomogenea del suo ecosistema di plugin, e va tenuto con disciplina sugli aggiornamenti e con pochi componenti. PrestaShop parte meglio come superficie esposta ma alza la posta, perché tratta pagamenti e dati dei clienti. Le piattaforme custom escono dal raggio degli attacchi automatici, ma affidano tutta la sicurezza alla serietà di chi le sviluppa.

Quello che è uguale per tutte e tre è il resto: aggiornamenti con un ritmo definito, superficie d'attacco ridotta al minimo, accessi protetti da secondo fattore, backup fuori sede e verificati, monitoraggio che avvisa in tempo reale, e — soprattutto — una divisione delle responsabilità scritta, non presunta.

In ECM gestiamo hosting e piattaforme per decine di aziende, tra siti istituzionali, eCommerce PrestaShop e applicazioni sviluppate su misura. Se hai il dubbio che nessuno stia davvero presidiando il tuo sito, o se ti è già successo e vuoi capire se è stato chiuso il problema o solo l'effetto, possiamo fare insieme una verifica. Se invece stai valutando su quale piattaforma costruire, ne parliamo nella pagina dedicata a design e sviluppo, e nei servizi di gestione in outsourcing.