[nodozero@bologna ~]$ ./chi_siamo --breve
Vi attacchiamo prima
che lo faccia
qualcun altro.
Penetration test, red team e revisione del codice. Non vendiamo licenze software e non abbiamo partnership con nessun vendor: quando vi diciamo che un prodotto non vi serve, non ci stiamo rimettendo una provvigione.
dal 2018
al nostro team
vendute
operative
// servizi
tutti >Il conflitto d'interessi
del settore.
In Italia la maggior parte delle società di sicurezza rivende prodotti. Il margine sta lì, non nella consulenza — e il consiglio tecnico finisce per coincidere con il prodotto su cui si guadagna di più.
Noi non abbiamo niente da rivendervi. L'unica cosa che vendiamo sono le ore delle quattro persone che ci lavorano, e l'unico modo per venderne ancora l'anno prossimo è che il report di quest'anno vi sia servito davvero.
«Un utente autenticato può leggere le fatture di qualsiasi altro cliente modificando un identificatore numerico nell'URL. Non è richiesto alcun privilegio particolare: il controllo di autorizzazione manca del tutto sull'endpoint.»
> leggi il report di esempio completoIl primo confronto
è gratuito.
Trenta minuti per capire cosa vi serve davvero. Spesso la risposta è meno di quello che pensavate.
[ scrivici ]servizi
Tre servizi, nessun pacchetto «enterprise» e nessun abbonamento. Si concorda il perimetro, si lavora, si consegna un report. Il retest è sempre incluso.
- Non vendiamo, non installiamo e non configuriamo prodotti di terze parti.
- Non facciamo vulnerability scan spacciati per penetration test.
- Non facciamo formazione generica sulla sicurezza per il personale.
- Non gestiamo SOC, monitoraggio o risposta agli incidenti in corso.
- Non lavoriamo su sistemi di cui il committente non ha titolarità dimostrabile.
Per le prime quattro cose vi indirizziamo volentieri a chi le fa bene. La quinta non è negoziabile.
[01] · 2 settimane · da 6.500 €
Penetration test
Due settimane in cui proviamo a entrare, con gli stessi strumenti di chi lo farebbe per soldi. Alla fine sapete cosa è rotto, quanto è grave e in che ordine sistemarlo.
- Durata
- 10 giorni lavorativi
- Perimetro tipico
- 1 applicazione web + API
- Approccio
- Grey box, con credenziali di test
- Standard
- OWASP WSTG · PTES
- Consegna
- Report PDF + sessione di riesame
- Retest
- Incluso, entro 90 giorni
- Prezzo
- da 6.500 € + IVA
Cosa succede davvero
Il primo giorno mappiamo la superficie: endpoint, ruoli, flussi di autenticazione, dove passano i dati. Dal secondo cominciamo a rompere le cose, partendo dai controlli di autorizzazione — che è dove si trovano i problemi peggiori nel 70% dei nostri test.
Gli scanner automatici li usiamo, ma occupano mezza giornata su dieci. Il resto è lavoro manuale: leggere le risposte, capire la logica applicativa e provare quello che il programmatore non ha previsto.
// cosa ricevete
- Report con ogni vulnerabilità classificata secondo CVSS 3.1
- Passi di riproduzione che il vostro sviluppatore può seguire
- Raccomandazione concreta, non «implementare le best practice»
- Ordine di priorità basato sul vostro contesto, non sul punteggio
- Una sessione di un'ora con il team di sviluppo per discuterlo
[02] · 3-6 settimane · da 24.000 €
Red team
Non cerchiamo tutte le vulnerabilità: cerchiamo la strada più breve verso un obiettivo che decidete voi. Per esempio: leggere il database dei clienti partendo da zero, senza credenziali.
- Durata
- 3-6 settimane
- Chi sa
- Due persone in azienda, nominate per iscritto
- Obiettivi
- Da 1 a 3, concordati prima
- Include
- Ingegneria sociale, se autorizzata
- Non include
- Attacchi fisici e denial of service
- Consegna
- Cronologia completa + report + debriefing
Serve solo se siete già maturi
Un red team ha senso quando avete già fatto penetration test, avete un sistema di monitoraggio e volete sapere se funziona davvero. Se non avete niente di tutto questo, vi diciamo di non farlo: spendereste 24.000 euro per scoprire cose che un test da 6.500 vi avrebbe già detto.
Il valore vero non è «siamo entrati». È la cronologia: a che ora abbiamo fatto cosa, e in quale momento il vostro team se n'è accorto — o non se n'è accorto. Quella tabella è il prodotto.
giorno ora evento rilevato ───────────────────────────────────────────────────────────── 02 09:14 ricognizione esterna avviata no 04 15:02 credenziali ottenute no 05 11:30 primo accesso interno no 09 08:47 movimento laterale parziale 11 14:20 obiettivo raggiunto no 12 10:05 segnalazione al cliente —
[03] · 1-3 settimane · da 4.500 €
Revisione del codice
Con l'accesso al repository troviamo cose che dall'esterno non si vedono: chiavi lasciate nel codice, controlli di autorizzazione applicati in un ramo e dimenticati nell'altro, dipendenze ferme a tre anni fa.
- Durata
- 1-3 settimane secondo la dimensione
- Linguaggi
- PHP · Python · Go · TypeScript · Java
- Accesso
- Sola lettura, su account dedicato
- Metodo
- Analisi statica + lettura manuale dei punti critici
- Consegna
- Report + issue aperte sul vostro tracker
Il momento giusto è prima
La revisione del codice costa meno di un penetration test e trova più cose, ma quasi nessuno la chiede — perché richiede di far leggere il proprio sorgente a un estraneo, e questo mette a disagio.
Lavoriamo con accesso in sola lettura da un account dedicato che potete revocare quando volete, e ogni riga che leggiamo resta coperta dall'accordo di riservatezza che firmiamo prima di ricevere le credenziali.
metodo
Cinque fasi, sempre le stesse, su qualsiasi tipo di incarico. La differenza tra un test buono e uno inutile sta quasi tutta nella prima e nell'ultima.
Perimetro e autorizzazione
Si definisce per iscritto cosa possiamo toccare, quando, da quali indirizzi IP e chi contattare se qualcosa va storto. Senza autorizzazione firmata non tocchiamo niente: è un reato, non una formalità.
Ricognizione
Mappatura della superficie esposta: sottodomini, endpoint, tecnologie, ruoli utente e flussi di autenticazione. È la fase che nessuno vede e che determina tutto il resto.
Sfruttamento
Verifica pratica di ogni ipotesi. Una vulnerabilità che non riusciamo a dimostrare non entra nel report come «probabile»: o la proviamo o la scriviamo tra le osservazioni.
Report
Due giorni pieni di scrittura, che fatturiamo come lavoro perché lo sono. Ogni finding ha riproduzione, impatto nel vostro contesto e una raccomandazione che si può implementare.
Retest
Quando avete corretto, torniamo a verificare — entro 90 giorni, senza costi aggiuntivi. Il report finale riporta lo stato reale di ogni finding: corretto, mitigato o ancora aperto.
- Ogni attività è tracciata: sapete sempre da quale IP arriviamo e in che orario.
- Se troviamo qualcosa di critico ci fermiamo e vi chiamiamo entro un'ora, non aspettiamo il report.
- Non esfiltriamo dati reali: dimostriamo l'accesso e ci fermiamo lì.
- I dati raccolti vengono distrutti 30 giorni dopo la consegna, con conferma scritta.
- Non pubblichiamo mai il nome di un cliente senza autorizzazione scritta.
Un report vero
Questo è un estratto reale, con nomi e dati sostituiti e pubblicato con il consenso del cliente. Serve a farvi vedere cosa comprate prima di comprarlo: la maggior parte dei report di penetration test in circolazione è l'esportazione di uno scanner con una copertina sopra.
- Committente
- [anonimizzato] · e-commerce, 40 dipendenti
- Perimetro
- Applicazione web + API, 2 ruoli utente
- Periodo
- 03 – 14 · 2026
- Finding totali
- 1 critico · 3 alti · 6 medi · 4 bassi
- Stato al retest
- 12 su 14 corretti
Accesso ai dati di altri clienti tramite identificatore prevedibile
L'endpoint che restituisce le fatture accetta un identificatore numerico sequenziale e non verifica che la fattura richiesta appartenga all'utente autenticato. Un cliente qualsiasi può quindi leggere le fatture di tutti gli altri, che contengono nome, indirizzo, partita IVA e dettaglio degli ordini.
# autenticati come utente A e apri una tua fattura GET /api/v1/invoices/4471 → 200 OK (tua) # decrementa l'identificatore, stessa sessione GET /api/v1/invoices/4470 → 200 OK (di un altro cliente)
Esposizione dei dati personali dell'intera base clienti (circa 31.000 record). Rilevante ai fini dell'articolo 33 del GDPR: in caso di sfruttamento, notifica al Garante entro 72 ore.
Verificare la proprietà della risorsa lato server a ogni richiesta, confrontando l'identificatore dell'utente in sessione con quello associato alla fattura. Sostituire gli identificatori sequenziali con UUID non prevedibili: è una difesa in profondità, non la soluzione — il controllo di autorizzazione resta obbligatorio.
La sessione resta valida dopo il cambio password
Cambiando la password, le sessioni già aperte su altri dispositivi non vengono invalidate. Un utente che si accorge di un accesso non autorizzato e cambia la password continua ad avere l'attaccante collegato.
Il cambio password — cioè la prima cosa che una vittima fa — non serve a niente. È una vulnerabilità che si nota solo quando è già tardi.
Invalidare tutte le sessioni attive al cambio password, tranne quella corrente, e mostrare all'utente l'elenco dei dispositivi collegati con la possibilità di disconnetterli.
Il modulo di recupero password rivela quali email sono registrate
Il modulo risponde «email non trovata» quando l'indirizzo non esiste e «email inviata» quando esiste. Permette di verificare quali indirizzi hanno un account, informazione utile per attacchi mirati.
Rispondere sempre con lo stesso messaggio, indipendentemente dall'esistenza dell'account, e mantenere costante il tempo di risposta.
Nel report completo ogni finding occupa una o due pagine, con riferimenti a CWE e OWASP, e la sezione iniziale contiene un riepilogo di due pagine leggibile da chi non è tecnico — perché è quella che finisce in consiglio di amministrazione.
Volete uno così
sul vostro sistema?
[ richiedi un preventivo ]
team
Quattro persone, tutte operative. Non abbiamo commerciali: la persona con cui parlate al telefono è la stessa che scriverà il vostro report.
Marco Dellepiane
Dodici anni sulle applicazioni web, prima in una società di consulenza e poi in proprio. Ha trovato quattro dei nove CVE del team.
Sara Bertolini
Viene dall'amministrazione di sistemi, il che significa che sa come sono fatte le reti aziendali vere — non quelle dei laboratori.
Youssef Amrani
Sviluppatore per sette anni prima di passare alla sicurezza. Legge il codice come chi l'ha scritto, non come chi lo attacca soltanto.
Elena Rossi
Coordina gli incarichi e cura la parte di conformità: NIS2, GDPR, requisiti dei clienti enterprise. Scrive la sezione che leggerà il vostro consiglio.
contatti
Rispondiamo entro un giorno lavorativo. Se dovete segnalarci una vulnerabilità sui nostri sistemi, usate la chiave PGP qui sotto.
- Sede
- Via del Pratello 42
40122 Bologna - info@nodozero.it
- Sicurezza
- security@nodozero.it
- Telefono
- +39 051 09 88 40
- P. IVA
- 04182760379
4096R/9F2D 41A7 0C88 3B15 fingerprint: 9F2D 41A7 0C88 3B15 6E04 D731 A9C5 88F0 2B4E 71DC
Il file security.txt è pubblicato su /.well-known/security.txt. Divulgazione coordinata: 90 giorni.