SSRF e OAuth exploitation: attacchi alla logica applicativa che il WAF non vede
Un WAF filtra pattern noti, ma gli attacchi alla logica applicativa gli passano sotto. Come funzionano davvero la Server-Side Request Forgery e l'abuso dei flussi OAuth: accesso a servizi interni e metadata cloud via SSRF, furto di token e confusione di redirect_uri negli OAuth. Esempi reali e difese che vivono nel codice, non nel perimetro: allowlist di destinazioni, validazione rigorosa dei redirect, isolamento delle richieste in uscita. Continua a leggere
Ultima modifica:
Molti team trattano il container come una sandbox di sicurezza, ma per default non lo è. I vettori di escape su Docker: privileged mode, socket Docker montato, capability eccessive, namespace condivisi. Come un attaccante esce dal container verso l'host e l'hardening che lo previene: user namespace, capability minime, seccomp, read-only filesystem. Dalla prospettiva offensiva, per capire cosa difendere davvero in una infrastruttura containerizzata. 
La pipeline di deploy ha accesso a segreti, registry e produzione, eppure viene trattata con meno attenzione del codice applicativo. I vettori d'attacco reali sul CI/CD: workflow injection, segreti esposti nei log, dipendenze di action non pinnate, escalation da una pull request. Come un attaccante usa la pipeline per arrivare in produzione e le contromisure concrete: least-privilege dei token, CODEOWNERS sui workflow, pinning e isolamento dei runner. 
Un penetration test non è uno scan automatico: è un percorso metodico dalla ricognizione allo sfruttamento controllato. Cosa accade davvero quando si testa un'applicazione web in azienda: le fasi, le vulnerabilità che si trovano più spesso (auth, logica applicativa, injection di seconda mano), come si distingue un finding reale da un falso positivo e come il report si traduce in remediation prioritizzate. Dalla prospettiva di chi attacca per difendere. 
Il collegamento che porta l'utente da un'applicazione all'altra già autenticato e sulla risorsa giusta è la funzionalità che tutti vogliono e che quasi nessuno implementa senza aprire un buco. Il problema non è l'autenticazione, che il protocollo risolve: è che un URL è un dato che l'utente controlla, e ogni parametro che ci metti diventa qualcosa su cui qualcuno proverà a barare. L'invariante che ho adottato, i vettori che ho provato e i compromessi che ho accettato. 
Gli LLM introducono classi di vulnerabilità prevedibili, perché replicano pattern insicuri visti nei dati di training. Analisi dal lato attaccante: quali debolezze cercare per prime nel codice generato (deserializzazione, SSRF, auth bypass, race condition), come si sfruttano nella pratica e come chiuderle. Per un team che usa l'AI per scrivere codice, sapere cosa proverebbe un attaccante è la differenza tra un assistente e un rischio. 
Il codice generato dagli assistant AI entra in produzione più in fretta di quanto venga revisionato. Audit sistematico dei pattern di vulnerabilità ricorrenti nell'output di ChatGPT e Copilot per PHP: injection non parametrizzate, validazione mancante, segreti hardcoded, dipendenze obsolete suggerite con fiducia. Una checklist offensiva per auditare ciò che l'AI scrive prima che diventi un incidente, dalla prospettiva di chi i bug li cerca per mestiere. 
Nei log di un sito reale compaiono richieste a path sensibili come .env, .ssh/id_rsa e .aws/credentials veicolate dagli user-agent di assistant AI come ChatGPT e Perplexity. Sono pochi tentativi isolati, non una campagna: ma il pattern è interessante per chi espone un'applicazione. Analisi forense onesta di cosa si vede davvero nei log, con la metodologia per distinguere il rumore dal segnale e le contromisure lato server. Information gain di prima mano, background offensivo dell'autore. 
Ad aprile 2026 Anthropic ha annunciato Mythos, modello troppo pericoloso da rilasciare al pubblico per le sue capacità di trovare zero-day in OS e browser principali. Disponibile solo entro Project Glasswing a 12 partner enterprise con 100 milioni di crediti usage. Diagnosi del problema che il precedente apre: una stessa azienda crea, valuta e narra il proprio modello senza audit terze parti. Implicazioni di cyber intelligence, governance e cosa una PMI può fare per verificare un vendor AI. 
Unit 42 ha pubblicato il 31 marzo 2026 il report Double Agents su Vertex AI - il P4SA service account ADK, creato di default per ogni Agent Engine, aveva permessi per estrarre credenziali dal metadata service e leggere Cloud Storage cross-tenant. Google ha risposto con BYOSA. Ma lo stesso pattern esiste in AWS Bedrock Agents e Azure AI Foundry - ti mostro il threat model generalizzato e uno script di audit per enumerare lo scoping sui tre cloud.