Test di intrusione su web app, portali e reti aziendali. Non una scansione automatica con un bollino alla fine: qualcuno che prova davvero ad entrare, con le stesse tecniche di chi lo farebbe per rubare, e poi ti scrive cosa ha trovato in una lingua che puoi girare al tuo fornitore.
pentest --scope "app + api" --mode grey-box
superficie mappata ..... 148 endpoint
tentativi di accesso ... nessun limite rilevato
controllo autorizzazioni 1 falla critica
[ok] referto consegnato in 5 giorni lavorativi
pentest --retest
riprova dopo la correzione: inclusa
in attesa
$ ./pentest --target "il tuo sistema"
Un penetration test non è una scansione automatica con un bollino alla fine. È qualcuno che prova davvero ad entrare, con le stesse tecniche di chi lo farebbe per rubare — e poi ti scrive cosa ha trovato in una lingua che puoi girare al tuo fornitore.
Cambiando un numero nell'indirizzo si aprivano i documenti di un'altra azienda. È la falla più comune che troviamo, e quasi sempre nessuno l'ha mai cercata.
Chiavi di API e password dentro il repository o dentro il JavaScript servito al browser. Chiunque sappia guardare, le trova.
Il modulo di login accettava tentativi all'infinito: una password debole cade in pochi minuti.
Un accesso rubato resta valido per sempre. Chi ha lasciato l'azienda entra ancora.
Componenti con vulnerabilità note e già pubblicate. Non serve un attacco: serve leggere il bollettino.
Nessuna di queste è teorica: sono le cinque che ritroviamo più spesso. Il referto che consegniamo dice dov'è, come ci siamo arrivati e cosa fare — con la riprova gratuita dopo la correzione.
// quando serve
Non serve a tutti allo stesso modo. Ma se ne riconosci tre, il costo di non guardare ha già superato quello di un test.
// cosa facciamo davvero
Un test serio si distingue da uno finto per una cosa sola: quello finto produce un elenco di avvisi automatici, questo produce una strada percorsa.
Si mappa la superficie esposta: domini, sottodomini, endpoint, servizi dimenticati accesi da anni. La metà delle intrusioni comincia da qualcosa che nessuno sapeva più di avere online.
Si provano davvero le strade: autorizzazioni aggirabili, sessioni riutilizzabili, dati di altri raggiungibili cambiando un numero. Concordiamo prima limiti e orari, e non tocchiamo mai dati reali.
Una parte per chi decide — cosa rischiate, quanto è grave, cosa fare per primo. Una parte per chi corregge, con richieste, risposte e passi per riprodurre. Senza la seconda, la prima non si può sistemare.
Dopo che avete corretto, si ritorna sugli stessi punti e si verifica. È la parte che quasi nessuno include, ed è l'unica che dimostra che il problema è chiuso davvero.
// come ci arriviamo
Un test di intrusione senza un mandato firmato non è un test: è un reato. È la prima cosa che mettiamo sul tavolo, e se manca non si comincia.
Si scrive cosa è dentro e cosa è fuori, in quali orari, con quali limiti. Firmato da chi ha il potere di autorizzarlo — non da chi gestisce il sistema, da chi lo possiede.
Si costruisce l'inventario di quello che è raggiungibile. Spesso è qui che esce la prima sorpresa: un ambiente di prova aperto, un vecchio sottodominio ancora vivo.
Le falle critiche si comunicano subito, non alla consegna: se troviamo una porta aperta sui dati dei vostri clienti, lo sapete quel giorno.
Consegna del referto con priorità e passi di correzione, e dopo i vostri interventi si ritorna a verificare gli stessi punti.
// un pezzo di referto
Questa è la forma con cui arrivano le cose nel referto: cosa abbiamo mandato, cosa ha risposto, e dove sta il punto. È anche la falla che troviamo più spesso.
referto 04 · controllo di autorizzazione mancante · gravità alta
# La sessione è quella di un utente vero: ha fatto login# regolarmente. Cambia solo il numero nell'indirizzo.GET /api/documenti/4187 HTTP/2Host: portale.esempio.itCookie: sessione=8f2a91c4d7e0HTTP/2 200 OKContent-Type: application/json{ "id": 4187, "cliente": "un'altra azienda", "file": "contratto-firmato.pdf", "url": "https://portale.esempio.it/media/9f1c2b.pdf"}// Il codice che ha risposto 200.function documento(int $id): ?array{ // Un controllo c'è, e a prima vista è quello giusto: // senza sessione valida di qui non si passa. if (!utente_autenticato()) { return null; } // Ma la domanda a cui questa riga risponde è // "esiste il documento 4187?" — e non // "il documento 4187 è di chi lo sta chiedendo?". return db()->riga( 'SELECT * FROM documenti WHERE id = ?', [$id] );}// La stessa funzione, con il proprietario dentro la domanda.function documento(int $id): ?array{ $utente = utente_autenticato(); if (!$utente) { return null; } // Ora la riga chiede tutte e due le cose insieme, e // il documento di un altro non è "vietato": non esiste. // Nessun secondo controllo da ricordarsi altrove, perché // non c'è nessun altro posto in cui si possa dimenticare. return db()->riga( 'SELECT * FROM documenti WHERE id = ? AND cliente_id = ?', [$id, $utente->cliente_id] );}La correzione non aggiunge un controllo: toglie la possibilità di dimenticarlo. Finché l'autorizzazione è un if scritto accanto alla query, prima o poi qualcuno scriverà una query nuova senza quell'if a fianco. Messa dentro la query, la domanda sbagliata non si può più formulare — e chi prova un numero a caso riceve 404, quindi non impara nemmeno che quel numero corrisponde a qualcosa.
$ cat stack.json
$ ./domande --frequenti
Solo con un mandato scritto da chi possiede il sistema, che definisce perimetro, orari e limiti. È la prima cosa che prepariamo, e senza quella non si comincia: un test di intrusione non autorizzato è un reato, per noi e per chi l'ha commissionato.
I test distruttivi — quelli che possono far cadere un servizio — si fanno solo se richiesti e su ambienti concordati, con una finestra dichiarata. Su sistemi in produzione lavoriamo in modo non distruttivo e non tocchiamo dati reali.
Un test su una web app di media dimensione sta fra i 5 e i 10 giorni lavorativi, referto compreso. La ricognizione richiede più tempo di quanto si immagini: è la parte che decide la qualità di tutto il resto.
Un referto in due parti: una per chi decide, con rischio e priorità, e una tecnica con passi per riprodurre ogni falla. Più una chiamata per leggerlo insieme, perché un PDF consegnato e basta finisce in una cartella.
Se raccoglie dati di persone, sì — e non per la dimensione: le scansioni automatiche che cercano falle non guardano il fatturato. Se è un sito vetrina senza dati e senza area riservata, spesso la risposta onesta è che bastano aggiornamenti e backup.
La sicurezza non è uno stato ma una manutenzione: aggiornamenti, revisione degli accessi, e un nuovo test quando cambia qualcosa di rilevante. Nel referto scriviamo ogni quanto ha senso ripeterlo per il vostro caso.
fymera init --progetto "il tuo"
Trenta minuti in video per capire il perimetro. Se la risposta giusta è "aggiornate e mettete un limite ai tentativi di accesso", ve lo diciamo senza venderti un test.
