Threat modeling di agent systems: quali rischi introducono gli LLM autonomi e come perimetrarli
Un agent LLM con accesso a tool esegue codice in nome dell'utente. Gli stessi principi del least privilege valgono - ma il perimetro è fluido, e l'LLM può essere manipolato. Ti mostro il framework di threat modeling che ho sviluppato: categorie di rischio (privilege escalation, data exfiltration, denial of service), analisi trust boundary, mitigazioni applicative concrete con esempio di agent Laravel + Claude API perimetrato. Continua a leggere
Ultima modifica:
La sessione PHP è uno dei vettori di attacco più sottovalutati. In un assessment su un portale bancario PHP, ho dimostrato session fixation in meno di 10 minuti sfruttando un PHPSESSID passato in query string. Vi mostro la configurazione php.ini che elimina la classe di vulnerabilità e i pattern di sessione sicura per Laravel. 
Un agent LLM che può eseguire query al database, inviare email, chiamare API è una backdoor delegata. Un attaccante che controlla l'input controlla le azioni dell'agent. Ti mostro le classi di prompt injection più pericolose su agent systems, le strategie di difesa applicativa (input validation, output fencing, least privilege), e un esempio concreto di human-in-the-loop gate che ho implementato in un agent Laravel nella mia sandbox di audit. 
ModSecurity con le regole OWASP CRS di default blocca il 30% delle richieste legittime su applicazioni PHP complesse. Il tuning è il lavoro vero. Vi mostro il processo che uso: audit mode per una settimana, analisi delle regole che scattano di più, whitelist chirurgiche e graduale passaggio a blocking mode. 
Il codice generato da AI sembra pulito ma nasconde classi di vulnerabilità ricorrenti che il contesto non riesce a catturare: SQL injection con parametri concatenati, XSS in output non sanitizzati, API key committate, pattern anti-OWASP. Nella mia sandbox di audit su codice AI-generated ho analizzato 40 output di ChatGPT, Copilot e Claude: ecco il catalogo dei pattern pericolosi e la checklist che applico sistematicamente prima di mergiare qualsiasi codice AI-generated. 
In un assessment su un portale Symfony per la gestione documentale di un'azienda legale, ho trovato upload senza validazione del MIME reale: bastava rinominare un PHP in .pdf per caricarlo ed eseguirlo. Vi mostro la catena di validazione completa che uso in produzione, dal content-type all'isolamento dello storage. 
Ho analizzato 200 snippet PHP generati da Copilot e ChatGPT nel contesto di progetti clienti: il 23% conteneva vulnerabilità, di cui il 8% classificabili come high severity. I pattern sono prevedibili: prepared statements dimenticati, input validation assente, errori gestiti con die(). Ecco come fare audit sistematico. 
Lo XSS stored che ho trovato in un CMS proprietario di un cliente media non era ovvio: si attivava solo in un campo amministrativo raramente utilizzato. Il payload sopravviveva a tre livelli di sanitizzazione perché ognuno usava una libreria diversa. Vi mostro la catena di bypass e come costruire una CSP che regge. 
Ho trovato una SQL injection in un gestionale di ordini PHP usato da un'azienda con 80 dipendenti. Il codice era del 2019, aggiornato più volte, ma la query vulnerabile era sopravvissuta a tutti i refactoring. Vi spiego perché SQLi è ancora viva, quali pattern la nascondono e come fare code review mirata. 
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.