cavallini.net
Penetration test

Penetration test per PrestaShop, e-commerce e sistemi web

Un test di sicurezza strutturato del tuo negozio, del back office e del server sotto, eseguito su tua autorizzazione scritta. Ricevi un rapporto che indica i problemi veri e dice cosa sistemare prima, in modo chiaro. Da 1.200€.

Da 1.200€

PrezziQuanto costa
Da 1.200€

PrestaShop o WordPress / Woo

Test esterno di negozio, back office e API, con rapporto scritto e un giro di verifica dei fix. Il prezzo finale dipende dal perimetro: numero di host, moduli custom, ruoli, API.

Lavoriamo insieme
Da 1.800€

Negozio + server Linux

Come sopra, più il server sotto: esposizione, livello di patch, SSH, servizi, TLS, accesso ai backup.

Lavoriamo insieme
Da 900€

WHMCS

Test esterno di area clienti, back office e API, per aziende di hosting e servizi che girano su WHMCS.

Lavoriamo insieme

Un penetration test non è uno scanner che lanci da solo e stai tranquillo: è un esercizio a tempo in cui qualcuno guarda il tuo negozio come lo guarderebbe un attaccante, trova i punti deboli e mette per iscritto cosa conta. Lo faccio su PrestaShop (1.6 → 9), WordPress e WooCommerce, WHMCS, e i server Linux sotto. Ogni test parte da un’autorizzazione scritta del proprietario del sistema: senza autorizzazione, nessun test.

L’obiettivo non è un rapporto di 200 pagine che nessuno leggerà. L’obiettivo è un documento breve e onesto che ti dice dove sei debole, cosa sistemare oggi, cosa puoi pianificare dopo.

Casi

Ti riconosci in questi casi?

  • Un cliente chiede una verifica di sicurezzaUn buyer B2B, un ente certificatore o la tua assicurazione ti chiede di dimostrare che il negozio è stato testato, e ti serve un rapporto credibile da consegnare.
  • Il negozio e il back office non sono mai stati controllatiIl sito è cresciuto negli anni, moduli sono andati e venuti, e nessuno è mai davvero andato a cercare falle con intenzione.
  • Hai appena finito una migrazione o una release grossaPrima di aprire la nuova versione al traffico reale, vuoi essere sicuro che non ci sia nulla di evidente esposto.
  • Un incidente ti ha spaventatoÈ successo qualcosa di strano, forse ve la siete cavata per un soffio. Vuoi trovare e chiudere ogni altra via d’ingresso prima che venga usata.
Cosa faccio

Cosa faccio, esattamente

  • Perimetro concordato per iscrittoDefiniamo cosa è dentro e cosa fuori (domini, percorsi admin, API, server), le date e la finestra di test. L’autorizzazione scritta del proprietario è un requisito, non un dettaglio.
  • Test automatici e manualiEntrambi: gli scanner trovano l’ovvio, il lavoro a mano trova il resto. Su PrestaShop e WHMCS la parte manuale è quella da cui arrivano i risultati veri.
  • OWASP ASVS come riferimentoUso l’OWASP Application Security Verification Standard come checklist, così la copertura è esplicita e il tuo team vede cosa è stato guardato e cosa no.
  • Verifica di back office e autenticazioneLogin, reset password, gestione sessioni, 2FA, separazione dei privilegi admin: le parti che un attaccante prova per prime.
  • Verifica lato serverEsposizione del server, livello di patch, configurazione TLS, SSH, servizi aperti, accesso ai backup, permessi dei file.
  • Rapporto scritto, due pubbliciUn executive summary che chi non è tecnico può usare per decidere, e un’appendice tecnica che il tuo sviluppatore o il tuo hoster possono usare per sistemare davvero.
  • Verifica dei fix, un giro inclusoQuando sistemi i rilievi, ri-testo quelli che contano per confermare che siano chiusi. Un giro è compreso.
Come funziona

Come lavoro

  1. Chiamata di scopingMezz’ora per capire i tuoi sistemi, concordare perimetro e date, e decidere cosa vuoi ottenere.
  2. Autorizzazione scrittaPrima che inizi qualunque test firmi un documento di scope e autorizzazione. Nomina i sistemi, le date e le persone. Senza, il test non parte.
  3. Finestra di testIl test si svolge nella finestra concordata, in genere da 5 a 10 giorni lavorativi a seconda del perimetro, con stato giornaliero se lo vuoi.
  4. Rapporto e lettura insiemeRicevi il rapporto, poi lo leggiamo insieme in una chiamata di un’ora, così esci con un piano chiaro: cosa sistemare oggi, questo mese, questo trimestre.
  5. Re-testDopo che il tuo team sistema i rilievi, verifico i fix sulle cose che contano. Compreso nel prezzo.
Perché io

Perché lavorare con me

  • Scrivo e gestisco i sistemi che testoOltre venti moduli PrestaShop in produzione, server Linux che tengo online ogni giorno, sistemi WHMCS che sviluppo e gestisco. So dove sono le falle vere perché pubblico lo stesso codice.
  • Rapporti che si leggono davveroBrevi, con priorità, in lingua chiara. Non uno scarico di output di scanner.
  • Base legale chiaraOgni incarico parte da un documento di scope e autorizzazione firmato dal proprietario del sistema. Non testo nulla che non mi sia esplicitamente consentito.
  • Fattura italiana e una persona veraP.IVA italiana, fattura elettronica, e la stessa persona prima, durante e dopo il test.
FAQ

Domande, con risposta

Puoi testare un negozio che non è tuo?

Solo con un’autorizzazione scritta del proprietario del negozio e del server. L’autorizzazione nomina i sistemi, le date e le persone. Senza, non parto.

Testi la produzione o una copia?

Dipende dal perimetro e dal rischio. Per test rumorosi si usa una copia di staging. Per verifiche che devono essere realistiche, si testa la produzione dentro una finestra concordata, modulando il traffico per non buttare giù il negozio.

Il test fa fermare il negozio?

L’obiettivo è trovare i problemi senza causare un fermo. Evito tecniche distruttive in produzione, limito la frequenza dove serve, e mi fermo subito se qualcosa sembra fragile. Se un test si può fare in sicurezza solo in staging, lo faccio in staging.

Cosa succede ai rilievi?

Vengono a te. Non li pubblico, non li vendo, non li condivido con nessuno. Il rapporto viene consegnato cifrato e cancello le mie copie di lavoro dopo il periodo di conservazione concordato.

Rilasci un certificato?

Non emetto certificazioni ufficiali: quelle le danno enti accreditati. Quello che ricevi è un rapporto scritto che il tuo cliente, la tua assicurazione o il tuo ente certificatore possono leggere e verificare.

Ogni quanto va rifatto?

Una volta all’anno è una base ragionevole per la maggior parte degli e-commerce, più un re-test più breve dopo ogni release importante o migrazione.

Contatti

Dimmi cosa non funziona, o cosa non parla con cosa.

Un progetto nuovo, un sistema da salvare, un’integrazione, l’adeguamento alle norme UE (recesso, GPSR, accessibilità). Un solo sviluppatore che lo costruisce e resta a gestirlo. Rispondo entro un giorno lavorativo.

Preferisci l’email?
luca@cavallini.net

Rispondo entro un giorno lavorativo.