Pagina 3 di 4
Pensare come un attaccante è l'unico modo per difendersi davvero. Un penetration test non è scaricare uno scanner e leggere il report: è capire come i pezzi di un sistema si combinano in un percorso di compromissione che nessun tool automatico vede da solo. Questa categoria racconta la sicurezza offensiva applicata, con finalità difensiva.
Il primo tema è il metodo dell'attaccante: la ricognizione, lo sfruttamento della logica applicativa che il WAF non intercetta, il lateral movement, l'analisi di codice legacy per trovare le falle prima che lo faccia qualcun altro. Il valore non è nel singolo exploit, ma nel ragionamento che collega form di upload, credenziali deboli e servizi esposti in una catena.
Il secondo tema sono le CVE reali riprodotte in laboratorio: dall'RCE pre-auth nell'SSH di Erlang a regreSSHion, dalle vulnerabilità della supply chain come xz-utils ai bug dei tool dell'ecosistema AI. Capire un attacco eseguendolo in un ambiente controllato è ciò che permette poi di chiudere davvero la porta, con la sandbox e la documentazione che una ricerca responsabile richiede.
Il terzo tema è il fronte offensivo nuovo: la pipeline CI/CD come vettore di attacco sottovalutato, il container escape, e il mondo agentic, dalla prompt injection come compromissione di sistema all'over-broad token scoping di MCP.
Se vuoi un assessment offensivo della tua infrastruttura, vedi la consulenza cybersecurity e NIS2 o scrivimi.
Non puoi difendere quello che non capisci. E per capire un attacco, a volte, devi saperlo eseguire in un ambiente controllato.
Security testing manuale è costoso e non scala. Ho costruito un layer di security testing automatico nella pipeline GitHub Actions di un cliente: PHPStan per l'analisi statica, OWASP ZAP in modalità baseline per il DAST, Trivy per i container. Zero colli di bottiglia, il tempo di CI è aumentato solo di 4 minuti. Continua a leggere
JWT è facile da implementare male. Ho trovato algorithm confusion attack (alg: none) in tre API Laravel auditate nell'ultimo anno - una vulnerabilità che permette di forgiare token validi senza conoscere il segreto. Vi spiego le vulnerabilità tipiche e il pattern di implementazione sicura con firebase/php-jwt. Continua a leggere
Ho trovato una vulnerabilità critica in un gestionale PHP usato da 300 PMI italiane. Non era un mio cliente. La gestione della disclosure è stata complicata: il vendor non aveva un canale dedicato, i tempi di fix erano incerti, e le PMI erano a rischio. Vi racconto come ho gestito ogni fase. Continua a leggere
Dopo la compromissione di un'applicazione Laravel, il cliente voleva sapere come erano entrati e cosa avevano preso. Ho ricostruito la kill chain completa dai log di Nginx, PHP, MySQL e dal filesystem: webshell caricata tramite IDOR + unrestricted upload, backdoor persistente in un file di configurazione. Vi mostro il metodo. Continua a leggere
Su cinque API Laravel con OAuth 2.0 auditate nell'ultimo anno, quattro avevano almeno una vulnerabilità critica nell'implementazione. La più comune era l'assenza di validazione del parametro state, che apre a attacchi CSRF sull'autorizzazione. Vi mostro le vulnerabilità, i payload di test e le fix. Continua a leggere
Ho trovato un SSRF in un sistema di webhook di un SaaS Laravel durante un assessment. Il client HTTP di Laravel, senza validazione dell'URL di destinazione, permetteva di raggiungere i metadata AWS e l'intranet del cliente. Vi spiego il percorso di exploitation completo e le tre righe di codice che lo avrebbero impedito. Continua a leggere
In un engagement red team su un'azienda retail con tre VPS e un cluster Docker, siamo passati da un form upload con SSRF a root su tutti i server in 4 ore. Il percorso di attacco era banale ma invisibile dai tool di monitoring standard. Vi descrivo la catena di compromissione e le contromisure. Continua a leggere
La versione 2025 dell'OWASP Top 10 introduce cambiamenti significativi rispetto al 2021, in particolare sull'insecure design e sulla sicurezza del codice generato da AI. Ho analizzato 12 applicazioni PHP di clienti PMI contro il nuovo framework: i risultati mostrano pattern di vulnerabilità diversi rispetto a cinque anni fa. Continua a leggere
In un recente assessment su un gestionale Laravel per una PMI manifatturiera, ho trovato mass assignment non protetto, IDOR su quattro endpoint API, e un file .env esposto via misconfiguration Nginx. Nessuna di queste vulnerabilità richiedeva strumenti sofisticati per essere trovata - bastava sapere dove guardare. Continua a leggere
Un gestionale PHP 7.0 con 14 SQL injection, 23 punti XSS e un file phpinfo.php accessibile pubblicamente con tutte le credenziali visibili. L'audit che ho condotto in 3 giorni con grep, Psalm taint analysis e OWASP ZAP, e il piano di remediation che ha chiuso le 37 vulnerabilità critiche in due settimane. Continua a leggere
Tool gratuiti per l'analisi di sicurezza:
Audit JWT, Audit del composer.lock, Analisi security headers, Decodifica certificato SSL.
