Violazione PrestaShop: contenimento, indagine e recupero

Cosa faremmo

Concorderemmo prima le responsabilità di contenimento e notifica, poi sceglieremmo un percorso di ripristino in base ai riscontri sul tuo negozio esistente. L'ambito dipende da hosting, versioni di PrestaShop e PHP, moduli, integrazioni, tema, contenuti e dati archiviati, oltre che dai mercati serviti e dal team disponibile a intervenire. Includi gli altri negozi che condividono l'account e le persone che gestiscono pagamenti, evasione degli ordini e assistenza clienti.

In caso di compromissione confermata, prepareremmo un ambiente di ripristino pulito e faremmo una prova su un sito di staging privato, con dati verificati e integrazioni controllate. Una copia del negozio compromesso resta non affidabile finché non viene analizzata. Pianifica il passaggio solo dopo il superamento dei controlli seguenti, con l'approvazione di un responsabile designato, la riconciliazione degli ordini e una distribuzione reversibile verso uno stato noto e affidabile.

Per una valutazione con ambito definito, il servizio PrestaShop Security Audit & Hardening Report fornisce riscontri e un piano ordinato per priorità; gli interventi correttivi hanno un ambito separato.

Ferma i danni in corso e conserva una cronologia dell'incidente

Registra quando ne sei venuto a conoscenza, cosa è stato segnalato, gli host interessati e le prove iniziali. Assegna un responsabile dell'incidente e incaricati paralleli per contenimento, prove, contatto con il fornitore di pagamenti e valutazione legale. Mantieni un registro delle azioni con timestamp in UTC.

Fornisci a chi interviene una scheda sintetica dell'incidente: domini interessati, sintomo osservato, distribuzioni recenti, contatti dell'hosting e modalità di accesso sicuro alle prove conservate. Concorda un canale di comunicazione esterno a qualsiasi account email o del personale sospettato di compromissione e non inserire credenziali nel registro delle azioni.

Se i clienti sono esposti a uno skimmer attivo o a un altro attacco in corso, limita tempestivamente l'accesso. Coordina con hosting e responsabile della risposta la conservazione delle prove volatili quando possibile, ma non rimandare l'interruzione dei danni ai clienti durante l'indagine.

La modalità manutenzione di PrestaShop si trova in Parametri negozio > Generale > Manutenzione nelle versioni moderne. Può mostrare una pagina di attesa e consentire IP di manutenzione selezionati. Non isola l'host: file PHP malevoli autonomi, attività pianificate e altri servizi possono restare raggiungibili.

I nomi delle impostazioni sottostanti sono PS_SHOP_ENABLE e PS_MAINTENANCE_IP. Se il back office non è disponibile, chiedi al fornitore di hosting o allo sviluppatore di confermare il contesto negozio applicabile e un metodo di contenimento sicuro; non applicare modifiche al database non verificate a un'intera installazione multinegozio.

• Chiedi all'hosting di limitare amministrazione in ingresso, traffico in uscita e servizi interessati secondo necessità.
• Usa una pagina di attesa esterna, perimetrale o a livello host, se l'applicazione stessa non è attendibile.
• Avvisa tempestivamente il fornitore di pagamenti/acquirer quando dati di pagamento o integrità del checkout possono essere compromessi. Segui le sue istruzioni per gli incidenti.
• Coinvolgi un esperto qualificato, l'assicuratore o il team interno pertinente secondo le procedure previste per gli incidenti.
• Evita di accedere al sistema compromesso con nuovi segreti che l'attaccante potrebbe leggere.

Carrelli spazzatura e spam nei moduli non dimostrano da soli una compromissione, ma possono creare costi, disservizi o nascondere altri abusi. Tratta i sintomi come prove da esaminare, non come dimostrazione che l'evento sia innocuo.

Raccogli prove con permessi restrittivi e hash verificati

Preferisci istantanee del fornitore e strumenti di raccolta attendibili insieme all'esperto incaricato. Copia la radice web inclusi i file nascosti, il database, i log web/PHP/applicativi e i record pertinenti del piano di controllo. Acquisisci processi volatili, connessioni di rete e sessioni prima dello spegnimento quando l'esperto lo ritiene utile. Gli strumenti dell'host compromesso potrebbero non essere affidabili.

Includi i log applicativi configurati per questa installazione e le eventuali destinazioni separate dei log dei moduli. Percorsi come var/logs/ e log/ sono esempi da confermare nella tua versione. Chiedi al fornitore di hosting di conservare i log ruotati e i registri esterni al server, come quelli dei servizi edge, delle autenticazioni e delle distribuzioni, prima che scada il periodo di conservazione. Registra le lacune nell'inventario.

Il seguente esempio GNU/Linux raccoglie file ordinari e log. Non è un'immagine forense del disco né un'acquisizione completa dell'incidente. Imposta prima percorsi, database e file protetto delle opzioni client MySQL. La destinazione delle prove deve essere fuori dalla radice web e inaccessibile all'utente web. Esegui bash -n collect-evidence.sh prima dell'uso.

#!/usr/bin/env bash
set -u -o pipefail
umask 077

evidence_root='/srv/incident-evidence'
webroot='/var/www/html'
database='prestashop'
mysql_options='/root/incident-mysql.cnf'

mkdir -p -- "$evidence_root" || exit 1
chmod 700 -- "$evidence_root" || exit 1
case_dir=$(mktemp -d "$evidence_root/prestashop-incident-$(date -u +%Y%m%dT%H%M%SZ)-XXXXXX") || exit 1
chmod 700 -- "$case_dir" || exit 1
failures=0

if ! tar --xattrs --acls -czf "$case_dir/files.tgz" -C "$webroot" . 2>"$case_dir/files-errors.log"; then
  printf '%s\n' 'File archive incomplete or failed.' >&2
  failures=$((failures + 1))
fi
if ! mysqldump --defaults-extra-file="$mysql_options" --single-transaction \
     --routines --triggers "$database" >"$case_dir/database.sql" 2>"$case_dir/database-errors.log"; then
  printf '%s\n' 'Database dump failed or incomplete.' >&2
  failures=$((failures + 1))
fi
mkdir -- "$case_dir/logs" || exit 1
for log_path in /var/log/nginx /var/log/apache2 /var/log/php*; do
  if [[ -e "$log_path" ]]; then
    if ! cp -a -- "$log_path" "$case_dir/logs/" 2>>"$case_dir/log-copy-errors.log"; then
      printf 'Failed to copy: %s\n' "$log_path" >&2
      failures=$((failures + 1))
    fi
  fi
done
printf 'UTC: %s\nCollection failures: %s\n' "$(date -u +%FT%TZ)" "$failures" >"$case_dir/COLLECTION-STATUS"

if ! (
  cd -- "$case_dir" || exit 1
  find . -type f ! -path './SHA256SUMS' ! -path './HASH-ERRORS' -print0 |
    LC_ALL=C sort -z |
    xargs -0 -r sha256sum
) >"$case_dir/SHA256SUMS" 2>"$case_dir/HASH-ERRORS"; then
  printf '%s\n' 'Hashing failed; inspect HASH-ERRORS.' >&2
  exit 1
fi
printf 'Evidence directory: %s\n' "$case_dir"
if (( failures > 0 )); then
  printf '%s\n' 'Collection is incomplete; resolve recorded failures.' >&2
  exit 1
fi

I permessi vengono limitati prima della raccolta. Il manifest calcola ricorsivamente gli hash dei file ordinari ed esclude il proprio output e il file degli errori di hashing. Ogni esecuzione crea una nuova directory. Esamina ogni log degli errori e l'inventario atteso delle prove anche quando lo script termina correttamente. L'assenza di percorsi log opzionali non dimostra che siano stati raccolti tutti i log pertinenti.

Un archivio dei file live e un dump del database non sono necessariamente un'istantanea atomica. --single-transaction fornisce una coerenza che dipende dalle tabelle transazionali e dalle modifiche concorrenti al database. L'archivio può segnalare file in cambiamento. Coordina un'istantanea o un'acquisizione a sistema quiescente quando richiesto e documentane i limiti.

Copia le prove in un archivio protetto inaccessibile all'attaccante. Conserva originali, timestamp, identificativi della sorgente e registri di accesso/trasferimento. Ricontrolla gli hash dopo il trasferimento con sha256sum -c SHA256SUMS dalla directory delle prove. Gli hash rilevano modifiche successive rispetto a quel manifest; non dimostrano che la sorgente fosse pulita o completa.

Esamina file PrestaShop, account e contenuti memorizzati

I modelli Employee nativi di PrestaShop 1.7.8 e 9.1 non forniscono un campo date_add per la creazione dell'account. Costruisci la cronologia dell'account da altri record. Correla gli elenchi degli account con backup, log di autenticazione/audit e cronologia disponibile del database.

Una ricerca per data di modifica è utile per una prima valutazione:

find . -type f -name "*.php" -mtime -30 -ls

Eseguila su una copia delle prove quando possibile. I timestamp possono essere manipolati e anche gli aggiornamenti legittimi modificano i file. Un nome sospetto non è una prova; l'assenza dai risultati non dimostra la sicurezza.

Cerca elementi script inattesi, domini esterni ed esecuzioni codificate sospette. Usa queste corrispondenze come indizi. Le ricerche per parole chiave possono non rilevare contenuti malevoli nel database. Fai esaminare da una persona competente in sicurezza payload decodificati, differenze rispetto a fonti attendibili, impostazioni, accessi utenti e registrazioni aziendali modificate. Non aprire pagine potenzialmente ostili in un normale browser del personale.

Estendi il confronto dei file ai percorsi scrivibili come img/, upload/, download/, var/cache/ e alle cartelle di caricamento del tema. Un nome apparentemente normale come config.php non è un motivo per fidarsi di un file. Confronta modules/, override/classes/ e override/controllers/ con pacchetti affidabili dei fornitori e codice personalizzato verificato. Indaga sui moduli inattesi e sui meccanismi che potrebbero ricreare file o account rimossi.

Dopo aver conservato le prove, Security Scan può fornire riscontri ordinati per priorità e posizioni da esaminare su una copia di lavoro isolata. L'installazione modifica file e stato del database, anche se l'analisi non corregge file né modifica impostazioni. Verifica i risultati confrontandoli con fonti affidabili; un risultato ottenuto da un ambiente di esecuzione compromesso non può dimostrare che l'ambiente sia pulito.

Esempio: un checkout che sembra normale al personale

Un cliente segnala un modulo per la carta sconosciuto, ma l'amministratore non riesce a riprodurlo mentre è autenticato. Considerala una segnalazione da indagare. Fornisci a chi interviene l'URL interessato, l'orario approssimativo e il contesto del visitatore, senza chiedere al cliente i dati della carta. Prima di visualizzare contenuti non affidabili, usa una copia di indagine usa e getta, senza credenziali di produzione, con integrazioni reali disabilitate e traffico in uscita limitato. Usa un browser isolato con accesso di rete controllato per confrontare checkout visualizzato, script caricati e destinazioni di rete tentate con i sorgenti affidabili di tema e moduli per il negozio e la lingua interessati.

Se viene trovato un payload in un blocco HTML archiviato, sostituire soltanto i file del tema lascia quella sorgente nel database. Esamina il contenuto interessato e l'accesso o il percorso nel codice che lo ha scritto, poi ripeti il percorso del visitatore pertinente sulla copia ricostruita. Conferma la destinazione del pagamento direttamente con il fornitore prima di riattivare quel percorso.

Limita l'esecuzione con regole specifiche del server

Limita la gestione dei file eseguibili nelle directory di immagini/caricamenti come parte del contenimento e del rafforzamento della sicurezza. Adatta le regole a server, document root, gestore PHP e flusso legittimo dei download. Non presumere che ogni file PHP in una directory scrivibile sia malevolo; anche i file legittimi della versione richiedono un confronto con fonti attendibili.

Esempio Apache 2.4

Questo esempio di configurazione server riguarda una directory. Adattalo e ripetilo per altre directory confermate come destinate ai soli dati. Non richiede la direttiva esclusiva di mod_php php_flag engine off:

<Directory "/var/www/html/img">
    <FilesMatch "(?i)\.(php[0-9]*|phtml|phar)(\.|$)">
        Require all denied
    </FilesMatch>
</Directory>

Se inserisci invece una regola FilesMatch in .htaccess, conferma la configurazione AllowOverride pertinente e le regole esistenti. Non inserire contenitori Directory in .htaccess. Prova la configurazione con lo strumento di controllo Apache installato prima di ricaricarla.

Esempio Nginx

# Place before a generic PHP regex location in the applicable server block.
location ~* ^/(img|upload|download)/.*\.(php[0-9]*|phtml|phar)([./]|$) {
    return 403;
}

Adatta il prefisso URI per i negozi in sottodirectory. Controlla la precedenza delle location, inclusi prefissi ^~, alias e location annidate che potrebbero aggirare la regola. Esegui nginx -t, ricarica con il normale flusso dei servizi e verifica che file di prova noti e sicuri siano bloccati senza eseguirli.

Prova questi schemi con la configurazione del server e il gestore PHP prima di farvi affidamento. Negare l'esecuzione non rimuove script iniettati in modelli legittimi né chiude la vulnerabilità di scrittura originale.

Sostituisci i segreti e revoca gli accessi da un ambiente pulito

Determina cosa l'attaccante poteva leggere o controllare, poi sostituisci le credenziali esposte da un dispositivo attendibile e da un sistema ricostruito o messo in sicurezza. Coordina i cambiamenti affinché vecchi accessi vengano revocati e applicazioni ricevano nuovi segreti insieme.

• Reimposta le credenziali dei dipendenti, verifica i profili e rimuovi o disabilita gli accessi non autorizzati dopo aver conservato le prove.
• Verifica pannello di controllo dell'hosting, utenti SSH/SFTP, chiavi autorizzate, token di distribuzione e credenziali DNS e dei backup.
• Sostituisci le credenziali del database e aggiorna atomicamente la configurazione applicativa locale appropriata.
• Sostituisci le credenziali esposte di pagamento, spedizione, email e altre API, inclusi i segreti di verifica dei webhook.
• Pianifica reimpostazioni delle password dei clienti, revoca delle sessioni attive e notifiche secondo l'esposizione.

PrestaShop 1.6 memorizza la configurazione legacy in config/settings.inc.php; le versioni moderne usano app/config/parameters.php. Esamina l'archiviazione effettiva delle chiavi nella tua versione anziché applicare un unico comando di sostituzione indiscriminato.

La rotazione di cookie/chiavi richiede un piano specifico per versione. Le implementazioni di hashing 1.7.8 e 9.1 mantengono la verifica MD5 legacy usando un salt statico associato alla chiave dei cookie. Cambiare quella chiave può impedire l'accesso ai clienti con hash legacy. Coordina migrazione/reimpostazione delle password, invalidazione dei cookie, sessioni lato server e gestione della cache per clienti e dipendenti.

Aggiungi autenticazione a due fattori supportata, password univoche, limiti di frequenza e accessi monitorati dove disponibili. Il CAPTCHA può ridurre alcune automazioni, ma non è un controllo completo contro l’uso di credenziali rubate o lo sfruttamento di codice vulnerabile dei moduli.

Dopo il ripristino, Security Revolution può offrire accesso del personale tramite app di autenticazione e limiti alle richieste; esamina le osservazioni sul traffico prima di abilitare i blocchi. Configura e verifica questi controlli sul negozio ripristinato, in modo che non escludano chi interviene né interrompano richieste legittime delle integrazioni.

Valuta gli obblighi di notifica mentre prosegue il contenimento

Valuta l'ambito territoriale del GDPR per la tua attività. Considera dove ha sede l'attività, se offri beni o servizi a persone nell'UE e se ne monitori il comportamento. Usare un fornitore europeo di pagamenti non rende da solo applicabile il GDPR a un negozio extraeuropeo. Consulta le indicazioni della Commissione sull'ambito.

Per una violazione dei dati personali soggetta alla normativa, notifica la violazione all'autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne vieni a conoscenza, salvo che sia improbabile un rischio per i diritti e le libertà delle persone. Spiega il ritardo dove richiesto e fornisci le informazioni in più fasi quando necessario.

Comunica alle persone interessate senza ingiustificato ritardo quando è probabile un rischio elevato, fatte salve le eccezioni applicabili. Una categoria di dati come password o dati di pagamento non determina automaticamente la valutazione del rischio: contano misure di protezione, esposizione e conseguenze probabili. Documenta la violazione e la valutazione anche quando la notifica all'autorità non è richiesta. Segui le indicazioni EDPB sulle violazioni.

Il lavoro sulle notifiche procede parallelamente all'indagine. Registra momento della conoscenza, sistemi/dati interessati, conseguenze probabili, misure protettive, decisioni e azioni successive. Verifica con gli specialisti responsabili altri obblighi di segnalazione locali, contrattuali, del settore dei pagamenti e assicurativi.

Comunica ai clienti in modo semplice: ciò che è noto, i dati interessati, i rischi probabili, le azioni protettive e un canale di contatto. Indica con chiarezza le incertezze. Non chiedere ai clienti password o dati delle carte. Spiega quali sono i canali ufficiali di contatto e reimpostazione, così sarà più facile riconoscere i tentativi di phishing che sfruttano l'incidente.

Assegna a qualcuno la gestione di un indirizzo di contatto per l'incidente che venga monitorato, con accesso limitato al team di risposta. Conserva un messaggio approvato e la cronologia degli aggiornamenti, così l'assistenza fornirà risposte coerenti, registrerà le domande irrisolte e indirizzerà le informazioni sensibili al canale sicuro concordato. Traduci il messaggio per i mercati interessati che servi.

Ricostruisci da fonti attendibili e definisci i controlli di riapertura

Un backup recente può già contenere la compromissione. Determina la probabile finestra di esposizione e controlla i backup candidati anziché ripristinare senza revisione i file della notte precedente.

1. Crea un ambiente attendibile e chiudi il punto di ingresso dimostrato, compresi gli accessi a livello host se coinvolti.
2. Installa core, tema e moduli da fonti autenticate dei fornitori. Ripristina solo codice personalizzato e override esaminati.
3. Correggi i componenti vulnerabili e rimuovi quelli non supportati oppure fornisci un piano di transizione testato.
4. Convalida dati migrati, configurazione, accessi dei dipendenti, destinazioni dei pagamenti e HTML memorizzato. Usa confronto dei sorgenti, record noti come validi e revisione esperta, non solo grep.
5. Conferma la sostituzione dei segreti, la revoca delle sessioni, le restrizioni in uscita e il funzionamento dei divieti di esecuzione.
6. Prova checkout, pagamenti, callback, email, rimborsi e accesso amministrativo sotto monitoraggio.
7. Documenta prove, incertezze irrisolte, approvazione dei responsabili e azioni di monitoraggio/ripristino prima di riaprire.

Se un aggiornamento immediato è impossibile, una mitigazione testata a livello delle richieste può ridurre temporaneamente l'esposizione a un exploit noto. Non rimuove persistenze già presenti e non sostituisce una patch supportata.

Una volta stabilito il contenimento, il servizio PrestaShop Upgrade Service: Any Version to PrestaShop 9 può supportare una sostituzione pianificata del sistema legacy; concorda separatamente l'ambito del ripristino e della revisione dei dati.

Prova il ripristino e riconcilia i dati al passaggio

1. Tieni l'archivio delle prove separato dalla copia di lavoro per il ripristino. Limita l'accesso alla copia e disabilita email reali, operazioni di pagamento, attività pianificate ed esportazioni per l'evasione degli ordini finché i relativi percorsi di test non vengono configurati esplicitamente.
2. Registra il punto fino al quale i dati sono stati recuperati e identifica ordini, pagamenti, rimborsi e variazioni delle scorte successivi. Controlla i registri del fornitore di pagamenti e dell'ERP oltre al database del negozio.
3. Prova il trasferimento finale dei dati e i controlli di riapertura usando tema, moduli, lingue, valute e flussi di integrazione reali. Registra gli errori e ripeti i controlli interessati dopo la correzione.
4. Concorda il blocco finale delle scritture e come trattenere, ritentare o riconciliare le notifiche in ingresso dei fornitori e gli aggiornamenti esterni. Assegna un responsabile a ogni coda anziché scartare silenziosamente gli aggiornamenti durante il passaggio.
5. Esegui il passaggio nella finestra concordata, verifica la vetrina pubblica e le destinazioni dei callback e monitora le prime transazioni reali fino ai sistemi a valle. Se i controlli falliscono, ferma l'elaborazione interessata e usa l'alternativa affidabile concordata.

Per esempio, in un database ripristinato potrebbe mancare un pagamento già acquisito dal fornitore o un ordine già spedito dal magazzino. Abbina riferimenti del fornitore, identificativi degli ordini e registri di spedizione prima di rielaborare gli eventi in coda o autorizzare l'evasione. Reimportare un vecchio ordine non deve addebitare di nuovo il cliente né inviare nuovamente la merce. Gestire il punto di ripristino richiede una riconciliazione operativa oltre al ripristino dei file.

Mantieni backup isolati con conservazione sufficiente alle esigenze di rilevamento e recupero e prova il ripristino. Trenta giorni possono essere un esempio di pianificazione, non la prova che ogni incidente sarà coperto. Conserva il registro dell'incidente ed esamina i controlli mancati dopo il ripristino del servizio. Non promettere pulizia garantita o tempi fissi di nuova compromissione.

Usa la guida a backup e ripristino di emergenza per documentare la procedura di ripristino e trasforma i risultati dell'indagine in azioni assegnate nel tuo piano di rafforzamento della sicurezza. Registra chi è responsabile di ogni correzione, come verrà verificata e quale monitoraggio rivelerebbe una ricomparsa del problema.

Cosa chiedere al tuo sviluppatore o all'agenzia

• Quali prove sostengono la valutazione del punto di ingresso e cosa resta sconosciuto?
• Quali pacchetti di core, tema e moduli sono stati usati per confronto e ricostruzione e quali personalizzazioni sono state verificate?
• L'ambito comprendeva account di hosting, altri negozi, accessi di distribuzione e credenziali delle integrazioni?
• Dove vengono conservati inventario delle prove, registro delle azioni, registro delle revoche delle credenziali e decisioni sulle notifiche?
• Quali risultati dei test giustificano la riapertura, come sono stati riconciliati i dati operativi mancanti e chi ha approvato il passaggio?
• Quali sintomi attiveranno un nuovo contenimento, chi riceve gli avvisi e a quale stato affidabile possiamo tornare?

Chiedi prove e responsabili identificati nella consegna. Un elenco di file eliminati o una scansione senza problemi non spiega il punto di ingresso, il periodo di esposizione o perché i controlli di ripristino sono stati superati.

Domande dei titolari

Posso lasciare aperto il negozio durante l'indagine?

Basa la decisione sull'esposizione dei clienti e sui consigli di contenimento del fornitore di hosting. La sola modalità manutenzione non può creare un perimetro affidabile; usa la sezione sul contenimento per concordare quali percorsi limitare e chi li verifica.

Serve un aggiornamento principale prima del ripristino?

Il requisito immediato è un ambiente affidabile con il punto di ingresso chiuso. Un negozio legacy potrebbe richiedere una sostituzione supportata per ottenerlo, ma concorda i controlli di compatibilità e dei dati prima di scegliere il percorso.

Posso riutilizzare il database di clienti e ordini?

Potenzialmente sì, dopo aver verificato contenuti archiviati, configurazione, account e dati operativi. Un'installazione pulita collegata a un database non controllato può caricare nuovamente gli stessi contenuti iniettati.

Devo aspettare la fine dell'indagine prima di notificare l'incidente?

No. Assegna la valutazione degli obblighi di notifica mentre prosegue il lavoro tecnico, registra ciò che è noto e segui la procedura di notifica applicabile, fornendo aggiornamenti quando necessario. La sezione sulle notifiche distingue le segnalazioni alle autorità dalle comunicazioni alle persone interessate.

E se nessuno riesce a dimostrare quando è arrivato l'attaccante?

Registra l'incertezza e usa tutti i registri indipendenti disponibili per valutare i backup candidati e i dati interessati. L'evento più remoto che hai trovato segna il limite delle prove disponibili, non dimostra che tutto ciò che lo precede fosse sicuro.