Le parole che usiamo quando parliamo della sicurezza del tuo negozio, spiegate senza gergo. Ogni termine ha la sua ancora: le altre pagine del sito rimandano direttamente qui.
Un errore in un codice che permette di fargli fare ciò che non dovrebbe.
Una vulnerabilità non è un virus: è un difetto di progettazione o di programmazione, quasi sempre un controllo dimenticato su un dato ricevuto dall'esterno. Finché nessuno la usa, non fa nulla. Il pericolo arriva quando qualcuno scrive il modo di sfruttarla: è l'exploit. Su PrestaShop la stragrande maggioranza delle falle sfruttate non sta nel cuore del sistema ma nei moduli di terze parti.
Le istruzioni che trasformano una falla in un'intrusione reale.
Il frammento di codice o la sequenza di richieste che sfrutta concretamente una vulnerabilità. È ciò che fa passare un problema teorico a un problema che ti costa denaro: una falla senza exploit noto resta dormiente, una falla con exploit pubblico viene setacciata dai bot in poche ore. Ecco perché il tempo che passa tra la pubblicazione di una falla e l'aggiornamento del tuo negozio conta così tanto.
Una falla già sfruttata mentre non esiste ancora alcuna correzione.
Il caso più scomodo: gli attacchi sono iniziati e l'editore del modulo non ha ancora pubblicato un aggiornamento, e a volte non lo pubblicherà mai, soprattutto su un modulo abbandonato. Aggiornare non serve, perché non c'è nulla da installare. È esattamente ciò che copre un firewall applicativo: rifiuta la richiesta d'attacco a monte, il che protegge subito, senza aspettare una correzione che non esiste.
Un accesso nascosto lasciato dall'attaccante per rientrare quando vuole.
Un file discreto depositato sul tuo server, spesso in una cartella banale come /upload, /img o /cache, che permette all'attaccante di riprendere il controllo del negozio anche dopo che hai cambiato tutte le password. È il motivo per cui «ho cambiato la password di amministratore» non basta mai a risolvere un attacco: finché la backdoor è lì, resta aperta. Una pulizia seria comincia col trovarle tutte.
Una backdoor pilotabile dal browser, come un pannello di amministrazione pirata.
Una forma di backdoor che offre all'attaccante una vera interfaccia: sfogliare i tuoi file, caricarne altri, eseguire comandi sul server, collegarsi al tuo database. I webshell si camuffano volentieri: un nome che somiglia a un file PrestaShop, oppure codice nascosto in fondo a un'immagine.
Codice iniettato nella pagina di pagamento che copia i numeri di carta dei tuoi clienti.
Poche righe di JavaScript aggiunte al processo di acquisto. Il cliente paga normalmente, l'ordine viene registrato normalmente, e in parallelo il numero della sua carta finisce all'attaccante. Nulla è visibile a occhio nudo, né per te né per l'acquirente: di solito è la banca o un cliente ad avvisarti, settimane dopo. È il tipo di infezione più costoso: oltre alla frode, coinvolge la tua responsabilità GDPR.
Termine generico per qualsiasi codice messo sul tuo sito senza il tuo consenso.
La parola copre tanto una backdoor quanto uno script di reindirizzamento, un miner di criptovalute o un relay di spam. Su PrestaShop arriva quasi sempre dalla stessa strada: un modulo di terze parti la cui vulnerabilità non è mai stata corretta.
I tuoi file o il tuo database resi illeggibili, e un riscatto chiesto per riaverli.
Su un negozio l'attacco assume raramente la forma della cifratura spettacolare che si vede sui computer da ufficio: più spesso l'attaccante cifra o cancella il database e i file, poi lascia una nota che chiede un pagamento. L'unica difesa che funziona davvero è un backup esterno che hai già provato a ripristinare — non un backup che vive sullo stesso server, perché viene cifrato insieme a tutto il resto. Pagare non garantisce nulla e finanzia l'attacco successivo.
Dirottare un modulo o un URL per far parlare il tuo database.
L'attaccante infila un frammento di query in un campo di ricerca, in un filtro o in un parametro di URL. Se il modulo non verifica correttamente ciò che riceve, il database la esegue: account clienti, ordini, a volte la creazione di un account amministratore. È la vulnerabilità più diffusa nei moduli PrestaShop di terze parti.
Far eseguire il codice dell'attaccante nel browser dei tuoi visitatori.
L'attaccante piazza uno script in una zona che il tuo negozio ristampa tale e quale: una recensione prodotto, un nome, un parametro di URL. Lo script viene poi eseguito da ogni visitatore che apre la pagina: furto di sessione, reindirizzamento, o installazione di uno skimmer sulla pagina di pagamento.
Provare migliaia di password finché una funziona.
Dei bot provano in continuazione combinazioni di utente e password sulla tua pagina di accesso amministratore. Senza limitazioni, una password debole cade in poche ore. Oltre al rischio di intrusione, queste ondate rallentano il server e a volte mettono offline il negozio da sole.
Un falso messaggio che ti fa digitare le credenziali su una pagina che imita quella vera.
Un'email o un SMS che si spaccia per il tuo hosting, per PrestaShop, per il tuo fornitore di pagamento — o per il tuo stesso back-office — e ti invita a «rifare l'accesso». La password digitata finisce all'attaccante, che poi entra dalla porta principale: non serve alcuna vulnerabilità tecnica, ed è esattamente per questo che un firewall da solo non basta. È il senso del controllo degli accessi da un indirizzo insolito. Da sapere: gli attaccanti fanno phishing anche verso i tuoi clienti, usando i dati rubati da un negozio compromesso per rendere credibile il messaggio.
Far leggere al sito un file che non avrebbe mai dovuto aprire.
Manipolando un parametro che indica un file, l'attaccante risale l'albero del server e fa visualizzare un file sensibile, tipicamente il tuo parameters.php, che contiene le credenziali del database. Nei casi peggiori la vulnerabilità permette anche di eseguire un file caricato in precedenza.
Mostrare a te una pagina pulita e agli altri una pagina compromessa.
Il codice malevolo controlla chi sta chiedendo la pagina. Un visitatore arrivato da Google viene reindirizzato verso spam o phishing; tu, connesso dal tuo indirizzo abituale, non vedi nulla di anomalo. È così che un attacco può durare settimane senza che il commerciante se ne accorga, finché il traffico non crolla.
La tua home page sostituita da un messaggio dell'attaccante.
La forma più visibile di un attacco: il negozio sparisce dietro una pagina rivendicata da un gruppo. Paradossalmente è la meno grave, perché si vede subito e quindi si tratta in fretta. Le infezioni che costano care sono quelle che si guardano bene dal cambiare l'aspetto del sito. Resta comunque un segnale serio: se qualcuno ha potuto riscrivere la tua home page, ha avuto accesso a tutto il resto.
Il tuo server dirottato per inviare email al posto dell'attaccante.
Uno script depositato sul sito invia migliaia di email fraudolente dal tuo server. Conseguenze immediate: il tuo dominio finisce nelle blacklist dei provider di posta (le conferme d'ordine vere non arrivano più) e il tuo hosting finisce per sospendere l'account.
Nessuno ti ha scelto: dei robot bussano a tutte le porte, in continuazione.
«Perché il mio negozio? Non sono Amazon.» Perché nessun essere umano ti ha preso di mira. Reti di macchine compromesse percorrono Internet senza sosta e provano su ogni sito l'elenco delle falle pubblicate, senza distinzione di dimensione o di fatturato. Un piccolo negozio con un modulo non aggiornato è un bersaglio valido quanto uno grande, spesso di più, perché è meno sorvegliato. È anche ciò che rende efficace la blacklist condivisa: sono gli stessi indirizzi a bussare ovunque.
Un filtro che blocca le richieste ostili prima che raggiungano il tuo negozio.
Dove un antivirus guarda i tuoi file, il firewall applicativo guarda il traffico in entrata e rifiuta ciò che somiglia a un attacco: SQL injection, script iniettato, tentativi di accesso in massa. Il suo valore principale è il tempo: protegge una vulnerabilità nota subito, senza aspettare che l'editore del modulo pubblichi una correzione.
L'identificativo pubblico di una vulnerabilità nota.
Quando una vulnerabilità viene scoperta in PrestaShop o in un modulo, riceve un numero di riferimento mondiale, per esempio CVE-2024-6648. Quel numero è pubblico: gli attaccanti lo usano come catalogo e scandagliano internet in cerca dei negozi non ancora aggiornati. È una corsa tra il momento in cui la vulnerabilità viene pubblicata e il momento in cui la correggi.
La scheda che descrive una vulnerabilità: modulo interessato, versioni, correzione.
Per ogni vulnerabilità che seguiamo teniamo una scheda: quale modulo, quali versioni sono vulnerabili, da quale versione è corretta e cosa facciamo nel frattempo. La tua dashboard incrocia queste schede con i moduli realmente installati sul tuo negozio, per mostrarti solo ciò che ti riguarda.
Confrontare ciascuno dei tuoi file con l'originale ufficiale PrestaShop.
Ogni file ha un'impronta digitale unica. Confrontando l'impronta dei tuoi file con quella dei file ufficiali della tua versione di PrestaShop, individuiamo con precisione ciò che è stato modificato, aggiunto o eliminato, anche quando il codice iniettato è scritto troppo bene per somigliare a un virus.
Un attacco bloccato su un cliente protegge immediatamente tutti gli altri.
Quando un indirizzo IP attacca un negozio della rete, viene aggiunto a una lista condivisa da tutti i negozi protetti. Lo stesso attaccante che si presenta poi da te viene respinto ancora prima di provarci. Più negozi ci sono nella rete, più la lista è aggiornata.
Un secondo fattore oltre alla password, perché una password rubata non basti più.
Un codice usa e getta richiesto in aggiunta alla password al momento dell'accesso. È l'unica protezione davvero efficace contro il phishing e il furto di credenziali: anche con la password giusta, l'attaccante viene fermato. Lo stesso principio vale per il controllo degli accessi amministratore da un indirizzo che il negozio non ha mai usato: viene richiesta una prova in più prima di lasciar entrare.
Un file segnalato come sospetto quando è perfettamente legittimo.
Alcuni moduli commerciali contengono codice compresso o codificato che, da lontano, somiglia a codice malevolo. Un buon antivirus deve segnalarlo invece di ignorarlo, ma deve anche permettere di decidere in fretta. La dashboard ti dà il contesto e l'estratto di codice esatto per decidere, e il nostro team arbitra i casi dubbi.
Chiudere le porte inutili per ridurre ciò che un attaccante può raggiungere.
L'insieme delle impostazioni che rendono un'intrusione più difficile e meno redditizia: permessi dei file corretti, versione di PHP mantenuta, accesso amministratore limitato, cartelle di installazione rimosse. Non è una protezione contro un attacco specifico: è ciò che fa sì che una vulnerabilità sfruttata causi meno danni.
La schermata rossa «Sito pericoloso» che azzera il tuo traffico.
Quando Google rileva contenuto malevolo su un negozio, mostra un avviso a schermo intero prima di far entrare il visitatore, e il posizionamento crolla. La rimozione non è automatica: bisogna ripulire e poi chiedere un riesame in Search Console. Metti in conto dalle 24 alle 72 ore dopo la convalida.
Chiudere una falla senza cambiare la versione del modulo.
Quando una falla viene pubblicata, la risposta normale è aggiornare il modulo — a patto che l'editore abbia pubblicato una versione corretta, che sia compatibile con il negozio e che si possa installare. Una patch agisce diversamente: modifica esattamente le righe difettose nella versione già in uso. La falla si chiude senza cambio di versione, senza rischio di regressione sul tema, e l'operazione è reversibile.
Avvisare prima l'editore, pubblicare il dettaglio dopo — o mai.
Pubblicare il dettaglio di una falla prima che l'editore l'abbia corretta arma chiunque contro tutti i negozi che usano quel modulo. La divulgazione coordinata consiste nell'avvisare l'editore, lasciargli il tempo di rilasciare una correzione e pubblicare solo dopo. Per questo contiamo pubblicamente le nostre scoperte senza mai nominare il modulo finché la correzione non è disponibile per tutti.
Manca un termine, o una definizione non è chiara? Scrivicelo e la aggiungiamo.
