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. 
Quando colleghi un'applicazione a un identity provider, ogni utente locale guadagna una colonna con l'identificativo esterno. Quella colonna è preziosa e fragile: costa migliaia di chiamate API per essere ricostruita, e applicarla alla riga sbagliata assegna l'identità di una persona a un'altra. Come l'ho portata fra ambienti diversi con un file di poche decine di kilobyte, una guardia che aborta invece di indovinare, e un'operazione ripetibile senza conseguenze. 
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. 
Attivare l'autenticazione a due fattori su un pannello di posta sembra una spunta da mettere, finché non ti accorgi che il codice via email finirebbe su una casella tecnica che per standard è recapitata all'operatore e non al cliente. Il difetto non è il secondo fattore: è che l'identità di accesso è una casella e non una persona. Il percorso di rimedio in tre passi, come si convive con i due sistemi durante la transizione, e le scadenze NIS2 reali che lo rendono urgente. 
Un setup Docker per Laravel che funziona uguale in sviluppo e in produzione elimina la classe di bug che si manifestano solo sul server. Come containerizzare un'applicazione Laravel in modo pulito: ambiente di sviluppo riproducibile, Dockerfile multi-stage per la produzione, gestione separata di code, cache e asset, e i punti dove la configurazione dev e prod deve divergere. Pattern concreti, non un docker-compose copiato. 
Aggiungere il single sign-on a un prodotto che gira anche presso clienti senza identity provider non è mettere un flag: è progettare due forme del prodotto che convivono nello stesso codice. E siccome il flusso coinvolge due applicazioni, la modalità effettiva non è una configurazione ma un'intersezione, che va scoperta invece che assunta. Il pattern della negoziazione, il degrado direzionale, la macchina a cinque stati e come si collauda un prodotto che le ha tutte. 
Per una PMI italiana l'AI Act passa dall'astratto al concreto con l'enforcement del 2 agosto 2026. Cosa fare nella pratica: censire i sistemi AI usati e il loro ruolo, applicare gli obblighi di trasparenza dell'Art. 50 dove si genera o si usa contenuto AI, capire quali fornitori GPAI sono coinvolti. I primi adempimenti operativi, distinguendo ciò che è in vigore da ciò che è ancora provvisorio per via del Digital Omnibus. 
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.