Pagina 6 di 7
La maggior parte delle compromissioni nasce da una validazione mancante, un upload non filtrato, un secret in chiaro, molto più spesso che da un exploit sofisticato. Nel codice un'azienda si gioca i dati dei clienti, e lì un intervento mirato rende più di qualsiasi appliance perimetrale. Questa categoria vive dentro il codice.
Molti articoli trattano le classi di vulnerabilità che continuano a colpire: OWASP Top 10 applicata sul serio, XSS, SQL injection, SSRF e attacchi alla logica che il WAF non vede, autenticazione fatta bene (JWT senza le trappole dell'algorithm confusion, OAuth, WebAuthn e passwordless), crittografia con libsodium, sicurezza degli upload. Sono gli errori che trovo davvero negli assessment, ciascuno con la sua difesa.
Altri seguono la difesa lungo tutta la pipeline: gestione dei segreti e rotazione delle credenziali, security testing automatico (SAST e DAST) in CI, protezione della supply chain con Composer, WAF configurato per non bloccare il traffico legittimo. La sicurezza applicativa attraversa sviluppo e rilascio, dal primo commit al deploy.
E c'è la nuova superficie del codice AI-generated, che entra in produzione più in fretta di quanto venga revisionato e porta con sé classi di vulnerabilità ricorrenti: capirle e auditarle in modo sistematico è ormai parte del mestiere.
Se vuoi un audit di sicurezza applicativo o mettere in sicurezza un'applicazione, vedi la consulenza cybersecurity e NIS2 o scrivimi.
La sicurezza che funziona sta scritta nel codice. Quella comprata e mai configurata protegge poco.
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
Le credenziali del database di un cliente erano hardcoded nel file .env committato su un repo privato - privato, ma con accesso a 8 collaboratori. Quando uno di loro ha lasciato l'azienda, abbiamo scoperto che non esisteva un modo rapido per ruotare tutte le credenziali. HashiCorp Vault ha risolto il problema strutturalmente. Continua a leggere
Dopo la backdoor xz-utils e il compromise di tj-actions del 2025, ho auditato le dipendenze Composer di 12 clienti PHP: 3 avevano pacchetti con nomi sospetti, nessuno aveva allow-plugins configurato, zero SBOM. Il playbook che ho implementato: pinning, audit in CI, blocco script e SBOM CycloneDX. 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
Quando lo sviluppatore freelance scompare e l'account del provider è intestato alla sua partita IVA, il server dedicato non è solo un problema tecnico: è una questione di proprietà legale, credenziali irrecuperabili e certificati in scadenza. Il caso reale di un cliente genovese del settore nautico B2B, un Hetzner AX51-NVMe con Magento 2 e gestionale custom in produzione, e i sei giorni di lavoro con cui ho restituito al titolare il controllo completo dell'infrastruttura. Continua a leggere
Un attacco di credential stuffing che genera 14.000 richieste al minuto su un'infrastruttura PMI è la cosa più simile a un'emergenza notturna che capita a chi gestisce server PHP in produzione. Il caso reale di un cliente toscano del marzo 2025, la pipeline di difesa stratificata Nginx + Fail2ban + Cloudflare con cui ho riportato il sito a regime in 47 minuti, e il decalogo operativo per non farsi cogliere impreparati. Continua a leggere
Quando un sito PHP viene compromesso su un server Hetzner o OVH, il riflesso istintivo del cliente è "rimuovere i file infetti e ripartire". È sbagliato e fa danni. Il protocollo corretto è cinque fasi strutturate: contenimento immediato senza distruggere evidenze, raccolta forensics, eradicazione completa, ripristino da fonte fidata, hardening permanente. E sotto NIS2 va aggiunta una sesta fase giuridica: la notifica al Garante entro 72 ore. Continua a leggere
Le macchine degli sviluppatori sono il punto di ingresso preferito per cercare persistenza in una PMI. Git offre tre vettori ignorati: hooks locali in `.git/hooks/`, alias con prefisso `!` in `~/.gitconfig`, e CVE-2024-32002 che ha trasformato `git clone --recurse-submodules` in code execution. Cosa cercare in audit, e perché un endpoint developer compromesso vale più di un server. Continua a leggere
Dalla backdoor di xz-utils scoperta da Andres Freund per un ritardo di 500ms sul login SSH al compromise di tj-actions/changed-files del marzo 2025, il 2024-2025 ha ridefinito cosa significhi "sicurezza della supply chain" per le PMI. Racconto il mio audit post-xz sui clienti PHP e Node, cinque contromisure operative e perché SBOM e SLSA nel 2026 sono il nuovo baseline. Continua a leggere
regreSSHion (CVE-2024-6387) ha riaperto un buco nella sshd di OpenSSH 18 anni dopo che era stato chiuso. Anatomia del race condition nel signal handler SIGALRM, perché il refactor del 2020 ha rimosso la fix originale, quanto era realisticamente sfruttabile su 64-bit, e l'hardening SSH che applico oggi alle PMI dopo aver patchato circa 200 server in produzione la notte del 1 luglio 2024. Continua a leggere
Tool gratuiti per verificare e irrobustire le tue applicazioni:
Audit JWT, Analisi security headers, Generatore CSP, Hash bcrypt e argon2, Cifratura AES.
