Security Audit Pro – Proteggi il tuo negozio dagli attacchi basati sull'IA - Modulo PrestaShop

Audit di sicurezza per PrestaShop: comprendere i risultati e seguire le correzioni

Errori di configurazione, file esposti e moduli vulnerabili meritano attenzione prima di un incidente. Security Audit Pro riunisce nel back-office controlli di sicurezza PrestaShop: header HTTP, file, amministrazione, moduli, WebService, codice SQL, XSS/CSRF e permessi.

L’audit aiuta a decidere cosa correggere e cosa approfondire. Non sostituisce un penetration test professionale e non fornisce un firewall o una protezione specifica contro una tecnologia di attacco.

Come funziona — 3 passaggi

Passaggio 1 — Analizza: cerca Security Audit in Moduli → Gestione moduli, fai clic su Configura e Avvia audit. Puoi metterlo in pausa e riprenderlo dopo un ricaricamento; un’interruzione conserva i passaggi salvati.

Passaggio 2 — Esamina: filtra per stato, categoria o ricerca. Passaggio 3 — Segui le correzioni: fai esaminare le raccomandazioni, ricontrolla un punto preciso e confronta due report.

Esportazione per lo sviluppatore o assistente IA

Il report di testo raccoglie risultati, prove disponibili e raccomandazioni. Condividilo con lo sviluppatore o un assistente IA per preparare correzioni adeguate; il JSON consente un’analisi strutturata.

Il modulo non applica le modifiche. Un sospetto nel codice richiede conferma prima di intervenire; fai revisionare e testare le proposte. I nuovi report escludono i valori grezzi dei cookie e i segreti individuati dal processo di rimozione dei dati sensibili.

Report dettagliati: risultati, prove e raccomandazioni

Ogni risultato riporta stato, ambito, spiegazione, prove disponibili e una raccomandazione quando serve intervenire. Problemi confermati, sospetti, controlli non verificati ed errori sono distinti dai controlli superati.

Un percorso di file, un header o un modulo interessato orientano l’esame. I filtri sostituiscono le otto vecchie schede; i dettagli si aprono quando servono. Le spiegazioni aiutano a stabilire le priorità, senza garantire che una correzione tecnica possa essere svolta senza assistenza.

Sezione 1 — Header HTTP e Configurazione Server

Gli header HTTP del tuo server sono la prima linea di difesa. Header mancanti o mal configurati espongono il tuo negozio a clickjacking, attacchi XSS, MIME sniffing e fughe di dati.

Esamina HSTS, CSP, protezione dall’inclusione in frame, X-Content-Type-Options, Referrer-Policy e Permissions-Policy. I report rilevano anche versioni del server divulgate e determinati attributi dei cookie.

Quando la risposta HTTPS è utilizzabile, vengono verificati il certificato e la sua scadenza. La politica CORS osservata sulla pagina pubblica offre indicazioni limitate e non convalida tutti gli endpoint.

Sezione 2 — File e Directory Sensibili

Uno dei vettori di attacco più comuni e devastanti: file che non dovrebbero mai essere accessibili pubblicamente. Un singolo file .env esposto può consegnare le credenziali del tuo intero database a un hacker.

Il modulo esamina un elenco limitato di percorsi sensibili: file .env, metadati Git, configurazione PrestaShop, file Composer, backup e log comuni. Cerca inoltre indizi di elenco delle directory.

Una risposta HTTP200 a una verifica di file è un sospetto da confermare, non la prova che il contenuto sia esposto. Risposte non accessibili o ambigue restano non verificate.

Sezione 3 — Sicurezza del Back-Office

Esamina il nome della cartella di amministrazione, gli account dipendenti pertinenti, alcune date di accesso e i formati delle password memorizzate. Una data mancante o non valida non dimostra l’inattività di un account.

Gli eventuali moduli di protezione rilevati sono indizi: la loro efficacia richiede un controllo. Il modulo non tenta accessi mediante forza bruta e non certifica la protezione del back-office.

Sezione 4 — Sicurezza dei Moduli

Confronta le versioni del nucleo e dei moduli con gli avvisi nel catalogo incorporato, corredati di fonte e data di revisione. Individua directory di moduli non registrati e alcuni punti di ingresso da esaminare.

Il catalogo comprende una selezione esplicita di avvisi. L’assenza di corrispondenze non dimostra che un modulo sia sicuro. L’audit non richiama punti di ingresso di moduli che potrebbero modificare dati.

Sezione 5 — Audit delle API WebService

Controlla l’attivazione del WebService, l’uso di HTTPS e la risposta anonima di /api/. Il modulo esamina lunghezza e varietà dei caratteri delle chiavi attive del negozio e alcuni permessi di scrittura sensibili.

Il report contiene conteggi e osservazioni, senza esportare i valori delle chiavi. Gli indizi di accesso anonimo o diritti estesi vanno esaminati nel contesto; non vengono estratte risorse dei clienti per dimostrare un’intrusione.

Sezione 6 — Indizi di SQL injection e analisi del codice

Una richiesta limitata sulla ricerca controlla la divulgazione di errori SQL. Una lettura limitata di file PHP nei moduli e negli override segnala determinate chiamate e sequenze, senza eseguire il codice analizzato.

Gli indizi statici sono sospetti, non SQL injection sfruttabili confermate. Profondità, numero e dimensione dei file sono limitati; il raggiungimento di un limite viene indicato nel report.

Sezione 7 — Controlli XSS e CSRF

Il Cross-Site Scripting (XSS) permette agli hacker di iniettare script malevoli nelle tue pagine, rubando i cookie dei clienti, i token di sessione e i dati personali. Il Cross-Site Request Forgery (CSRF) inganna gli utenti autenticati facendogli compiere azioni indesiderate.

La verifica sulla ricerca usa un marcatore HTML inerte per rilevare una riflessione da esaminare. Non invia script eseguibili. CSP rientra nelle osservazioni sugli header.

Un campo token nel modulo di contatto non dimostra la validazione sul server. Il controllo CSRF resta non verificato e richiede un esame aggiuntivo.

Sezione 8 — Permessi e Controllo Accessi

Esamina alcuni permessi dei file di configurazione, la presenza di regole Apache nelle cartelle di caricamento e una risposta di reindirizzamento, senza seguire la destinazione esterna.

Un file .htaccess non dimostra che il server blocchi l’esecuzione PHP. Il modulo non tenta di accedere agli ordini di altri clienti e non certifica i controlli di proprietà degli oggetti (IDOR).

Un punteggio da A a F quando i controlli lo consentono

I contatori evidenziano risultati critici, avvisi e controlli verificati. La valutazione globale viene calcolata solo per un audit terminato con controlli applicabili verificati; altrimenti non viene assegnata e il motivo è spiegato.

Un risultato critico limita il punteggio calcolabile. Una valutazione alta o un controllo superato non garantiscono la sicurezza globale: copertura e prove restano fondamentali.

Dashboard, Cronologia e Confronto

Ritrova audit datati, apri i report quando servono e confronta risultati nuovi, persistenti, risolti o non verificati. Un controllo assente non diventa automaticamente una correzione confermata.

Puoi mettere in pausa, riprendere o annullare l’audit. Dopo l’aggiornamento di un modulo o un intervento tecnico, ricontrolla il punto interessato e segui l’evoluzione nella cronologia.

Controlli limitati, senza modifiche automatiche al negozio

I controlli leggono i file e le impostazioni esaminati senza correggerli automaticamente. Il modulo salva i propri report e lo stato di avanzamento. Le richieste HTTP sono limitate, restano nel negozio configurato e non seguono reindirizzamenti.

Nessuno script viene aggiunto alla vetrina. L’audit consuma comunque risorse durante l’esecuzione; la durata dipende dal negozio e dall’hosting. Puoi sospenderlo o annullarlo.

Cronologia per negozio nel multinegozio

Seleziona un negozio per consultare e avviare i suoi audit. I nuovi report e confronti sono separati per negozio; i risultati relativi ai file condivisi sono identificati come tali.

Le vecchie voci senza attribuzione affidabile a un negozio sono riservate al superamministratore ed escluse dai confronti. I permessi dei dipendenti sono rispettati per lettura, audit ed eliminazione.

Compatibilità e funzionamento

Accedi tramite Configura in Gestione moduli, senza una voce aggiuntiva nel menu laterale. Interfaccia e report sono disponibili in francese, inglese, spagnolo, italiano e polacco.

PrestaShop 1.7.8, 8 e 9; almeno PHP 7.4, in una versione compatibile con il tuo PrestaShop. Estensioni richieste: JSON, PDO, mbstring, cURL e OpenSSL. Interfaccia locale senza librerie remote e senza compilazione a carico del commerciante.

A chi è rivolto questo modulo?

Per commercianti che vogliono capire i risultati prima di coinvolgere lo sviluppatore; agenzie che seguono più negozi; e sviluppatori che esaminano indizi nei file e confrontano i risultati dopo una correzione.

Un audit specialistico resta necessario per confermare i sospetti e verificare le protezioni che non possono essere convalidate automaticamente.

Leggi la guida all’audit di sicurezza e alla verifica delle correzioni