Cosa prendono di mira davvero gli attacchi a PrestaShop: 1,1 milioni di attacchi reali, analizzati

La maggior parte dei consigli sulla “sicurezza PrestaShop” nasce dall’immaginazione di chi difende — un elenco di cose che potrebbero andare storte. Noi volevamo l’opposto: una misurazione di ciò che accade davvero a uno store PrestaShop live, sul campo, adesso. Così abbiamo strumentato la nostra flotta e contato.

Gestiamo e difendiamo diversi store PrestaShop in produzione e in oltre un decennio abbiamo costruito e mantenuto un ampio catalogo di moduli PrestaShop. Questo ci ha dato qualcosa che la maggior parte degli articoli sulla sicurezza non ha: un insieme di vetrine reali e trafficate e il permesso di osservare ogni richiesta ostile che le colpisce. Per sei settimane abbiamo registrato ogni richiesta malevola — non solo quelle andate a segno, e non solo quelle rivolte al software che effettivamente usiamo. Se un bot sondava un modulo che nemmeno abbiamo installato, lo registravamo comunque, perché l’obiettivo era un quadro onesto e completo della pressione a cui è sottoposto un normale store.

Il totale è arrivato a circa 1,1 milioni di richieste malevole da più di 13.300 indirizzi IP distinti. Ecco cosa cercavano davvero gli attaccanti — e, per ogni risultato, esattamente cosa fare al riguardo.

Prima verità: circa il 99% è rumore

La cosa più importante da capire è la forma del traffico. La stragrande maggioranza — ben oltre un milione di richieste — è ricognizione automatica: scanner di massa che percorrono internet, sparando gli stessi payload preconfezionati contro ogni IP raggiungibile, indifferenti al fatto che tu usi PrestaShop, WordPress o un’applicazione Java.

È rassicurante e pericoloso allo stesso tempo. Rassicurante, perché quasi tutto rimbalza su uno store aggiornato e ben configurato. Pericoloso, perché quel muro di rumore è esattamente dove si nasconde un tentativo mirato. La punta davvero acuminata è reale ma piccola — nell’ordine di 34.000 sondaggi di SQL injection e un paio di migliaia di tentativi di eseguire codice direttamente sul server — una fetta sottile sepolta dentro un milione di richieste di rumore di fondo. Se scorri a occhio i log d’accesso grezzi, non individuerai mai in modo affidabile l’unica richiesta che conta. È tutta qui la ragione per preferire il rilevamento strutturato al “controllo i log se qualcosa mi puzza”.

Ecco lo stesso quadro suddiviso per obiettivo.

Vengono prima per i tuoi segreti

Per puro volume, il singolo obiettivo più rumoroso non era affatto lo sfruttamento di una falla. Era il furto di credenziali a badilate: oltre 220.000 richieste che tentavano di scaricare file segreti — .env e le sue dozzine di varianti (.env.local, .env.production, .env.backup, /api/.env, e via così), oltre a .git/config, file di configurazione dei framework e credenziali in cache.

La logica è brutalmente efficiente. Perché scrivere un exploit quando un server mal configurato semplicemente consegna la password del database, la chiave API dei pagamenti e le credenziali della posta in un file di testo? Un singolo .env trapelato spesso significa partita finita — nessuna vulnerabilità richiesta, solo una directory che non doveva mai essere pubblica ma lo è.

Cosa fare: assicurati in modo assoluto che il tuo web server rifiuti di servire dotfile e file di configurazione. Devono restituire 403 o 404 dal perimetro, non il loro contenuto. È una modifica di cinque minuti che neutralizza l’obiettivo più comune che abbiamo registrato:

# Place these ABOVE your generic PHP handler - nginx matches location blocks in order
# Never serve dotfiles (except ACME) or config/secret files
location ~ /\.(?!well-known/) { deny all; }

location ~* \.(env|git|bak|old|dist|sql|log|lock)$ { deny all; }

location ~* /(composer\.(json|lock)|package(-lock)?\.json|yarn\.lock)$ { deny all; }

# PrestaShop config/credential files (all supported versions)
location ~* /(settings\.inc\.php|parameters\.(php|ya?ml))$ { deny all; }

# Block dotfiles and config/secret files
RedirectMatch 404 /\.(?!well-known)

<FilesMatch "\.(env|git|bak|old|dist|sql|log|lock)$">
    Require all denied
</FilesMatch>

<FilesMatch "^(composer\.(json|lock)|package(-lock)?\.json|yarn\.lock)$">
    Require all denied
</FilesMatch>

# PrestaShop config/credential files (all supported versions)
<FilesMatch "^(settings\.inc\.php|parameters\.(php|ya?ml))$">
    Require all denied
</FilesMatch>

Il componente mirato n. 1: un modulo abbandonato

Quando abbiamo filtrato fino agli attacchi rivolti a PrestaShop nello specifico, un bersaglio superava di gran lunga tutti gli altri: una falla di local file inclusion in un vecchio modulo blog non più mantenuto — circa 32.000 tentativi, più di ogni altra vulnerabilità di modulo messa insieme.

È questo lo schema che rovina gli store in silenzio. Quasi mai è il core di PrestaShop a far entrare gli attaccanti. È il modulo di terze parti che hai installato tre anni fa, hai smesso di aggiornare e ti sei dimenticato di avere. Gli attaccanti mantengono liste curate di questi — nome del modulo, percorso vulnerabile, exploit già pronto — e li spargono su tutta internet in loop.

Più in basso nella lista c’erano i soliti sospetti: sondaggi di SQL injection contro moduli di contatto e newsletter, una vulnerabilità nota in un modulo wishlist e una manciata di add-on per slider e ricerca. Tutti di terze parti. Tutta quella roba che si accumula in uno store nel corso degli anni e poi resta lì, non aggiornata, molto dopo che chiunque ricordi di averla installata.

Cosa fare: fai l’inventario dei tuoi moduli ed elimina quelli che non usi — un modulo installato ma inutilizzato è pura superficie d’attacco a beneficio zero. Aggiorna quelli che tieni e, se lo sviluppatore è sparito, sostituisci il modulo invece di sperare. Se sei bloccato su una versione che non puoi aggiornare in sicurezza, la nostra guida su come mettere in sicurezza uno store che non puoi aggiornare illustra come applicare virtualmente una patch proprio a questo tipo di buco.

Il kit dello scasso: webshell e backdoor

Oltre la ricognizione e la caccia ai segreti c’è la punta acuminata. Gli attaccanti hanno tentato ripetutamente di depositare o localizzare webshell — gli strumenti che trasformano una singola vulnerabilità in controllo remoto totale. I nomi dei file sono quasi una firma di per sé: adminer.php, alfa.php, wso.php, sondaggi sparsi verso phpinfo e script di gestione database lasciati da una compromissione precedente.

Abbiamo anche colto qualcosa di più mirato della scansione generica. Quando uno store di un gruppo viene compromesso, gli attaccanti prendono l’esatto payload che ha funzionato lì e lo sparano contro ogni store correlato che riescono a trovare, scommettendo che la stessa backdoor sia ancora presente su un altro. La persistenza paga: una backdoor sepolta in un file raramente ispezionato può sopravvivere a più “pulizie” superficiali e continuare a reinfettare uno store per settimane. Se una volta hai ripulito una compromissione rimuovendo solo il JavaScript malevolo visibile ed è tornata, è per questo — abbiamo ripercorso esattamente quel fallimento nella nostra anatomia di uno skimmer in stile Magecart.

Cosa fare: nega l’esecuzione di PHP in ogni directory che dovrebbe contenere solo upload, immagini, cache o strumenti. Se un bot riesce a scrivere shell.php nella tua cartella immagini, la differenza tra una brutta giornata e una violazione completa è semplicemente se il server lo eseguirà:

# Put this ABOVE your existing "location ~ \.php$" block - nginx is first-match-wins
# A bot that writes shell.php into an image folder must never get it executed
location ~* ^/(img|upload|uploads|cache|var|download)/.*\.(php|phar|phtml|php[0-9])$ {
    deny all;
}

# Drop this .htaccess inside an uploads folder: turn PHP off for the whole tree
<FilesMatch "\.(php|phar|phtml|php[0-9])$">
    Require all denied
</FilesMatch>

Non controllano nemmeno cosa stai usando

Un’illustrazione eloquente di quanto sia automatizzato tutto questo: abbiamo registrato decine di migliaia di tentativi di exploit rivolti a stack tecnologici completamente diversi — payload Java e JSF, exploit di plugin WordPress, trucchi ASP.NET — tutti sparati alla cieca contro store PHP che non potrebbero mai esservi vulnerabili.

La lezione non è “ah, hanno mancato il bersaglio”. È l’opposto: sei attaccato di continuo, da attaccanti che non sanno né si curano di cosa usi. Non devi essere un bersaglio per essere una vittima. Ti basta essere raggiungibile e non aggiornato.

Controlla subito il tuo negozio

Leggerne è una cosa; qui trovi quattro controlli che puoi eseguire sul tuo negozio nei prossimi cinque minuti. Corrispondono esattamente a ciò che gli aggressori visti sopra vanno cercando.

1. I tuoi segreti sono davvero irraggiungibili? Dalla tua macchina, richiedi i file che cercano gli scanner. Ogni riga dovrebbe restituire 403 o 404 — mai 200 con il contenuto:

# From your own machine: 403/404 = safe, 200 = exposed, 000 or 3xx = check by hand
for f in .env .git/config app/config/parameters.php composer.json; do
  printf '%s -> ' "$f"
  curl -s -o /dev/null --connect-timeout 5 --max-time 15 -w '%{http_code}\n' "https://your-store.com/$f"
done

2. C’è del PHP nascosto dove dovrebbero esserci solo asset? Via SSH, dalla radice del tuo shop, cerca file eseguibili in cartelle che dovrebbero contenere solo upload e immagini. Non dovrebbe stampare nulla:

# PHP hiding in folders that should only hold assets (a clean store prints nothing)
find img upload uploads download -type f \
  \( -iname '*.php' -o -iname '*.php[0-9]' -o -iname '*.phtml' -o -iname '*.phar' \) \
  ! -iname index.php 2>/dev/null

3. Cosa è cambiato di recente? Una backdoor appena installata è un file PHP modificato di recente che non hai toccato. Elenca le modifiche dell’ultima settimana e controlla con attenzione qualsiasi cosa non ti sia familiare:

# PHP changed in the last 7 days, cache excluded (GNU/Linux find) - review anything unfamiliar
find . \( -path ./var/cache -o -path ./cache \) -prune -o \
  -type f -iname '*.php' -mtime -7 -printf '%TY-%Tm-%Td  %p\n' | sort

4. Chi può accedere al tuo back office? Ogni account è una chiave della porta d’ingresso. Verifica ogni dipendente che non riconosci e chiunque non acceda da mesi:

-- Back-office accounts: investigate any you do not recognise
-- Run in phpMyAdmin or the mysql client; change the ps_ prefix if yours differs
SELECT id_employee, email, active, last_connection_date
FROM ps_employee
ORDER BY last_connection_date DESC;

Cosa facciamo davvero sui nostri store

Poiché queste sono anche le nostre vetrine, l’elenco difensivo qui sopra non è teorico. Sugli store di questo studio blocchiamo dotfile e file di configurazione al perimetro, neghiamo l’esecuzione di PHP su ogni percorso scrivibile, teniamo un’impronta di moduli deliberatamente ridotta e rimuoviamo tutto ciò che è inutilizzato, imponiamo l’autenticazione a due fattori sull’admin e mettiamo il tutto dietro uno strato edge che limita la frequenza degli scanner e scarta i payload di injection evidenti. E teniamo il registratore in funzione — lo stesso logging a livello di richiesta che ha prodotto questo articolo — così che un tentativo davvero mirato emerga invece di annegare nel 99% di rumore. Niente di esotico. Tutto noioso, e il noioso è ciò che funziona.

• Blocca i file segreti al perimetro. .env, .git, composer.json e i file di configurazione devono restituire 403/404 — mai il loro contenuto.
• Sfoltisci i tuoi moduli. Elimina tutto ciò che non usi; un modulo inutilizzato è pura superficie d’attacco.
• Aggiorna o sostituisci ciò che tieni. Soprattutto add-on di terze parti per blog, slider, moduli e ricerca.
• Nega PHP nelle cartelle scrivibili. Upload, immagini, cache e tmp non devono mai eseguire codice.
• Blinda il login admin. Credenziali forti e uniche e autenticazione a due fattori.
• Resta su una versione supportata. Una piattaforma a fine vita porta con sé un insieme permanente di chiavi note.
• Metti il rilevamento tra te e il rumore così che l’1% che conta non possa nascondersi nel 99% che non conta.

Domande frequenti

In conclusione

Togli il volume e il quadro è semplice. Gli attacchi che vanno a segno quasi mai si basano su qualche esotico zero-day. Si basano sulle cose noiose: un file segreto lasciato leggibile, un modulo di terze parti non aggiornato o abbandonato, una directory che eseguirà un file PHP caricato, un login admin con una password debole o riutilizzata, una piattaforma non aggiornata. Nessuna di queste è difficile da correggere. Tutte sono cose che uno store mantenuto fa bene e uno trascurato no. Gli attaccanti hanno automatizzato la ricerca della trascuratezza — un milione di volte in sei settimane. L’unica vera difesa è non essere trascurati: aggiorna, sfoltisci, blinda le porte ovvie e metti un rilevamento reale tra te e quel muro di rumore.

Nota metodologica: le cifre sono aggregate dal logging degli attacchi a livello di richiesta su più store live in produzione lungo una finestra di circa sei settimane conclusasi a luglio 2026. Tutti i dati sono anonimizzati; non è incluso alcun dettaglio di store, cliente o credenziale, e non viene pubblicato alcun dettaglio di exploit.