Deserializzazione insicura in Java: quando «rimontare» un dato ricevuto fa eseguire codice ostile
Molte applicazioni ricevono oggetti «impacchettati» e li rimontano. Se non controllano cosa stanno rimontando, un attaccante può infilarci dentro istruzioni che il server esegue. Un classico, ancora attualissimo.
Immagina di spedire un mobile smontato in una scatola, con le istruzioni per rimontarlo. Chi lo riceve segue le istruzioni e lo ricompone. Ora immagina che qualcuno, nella scatola, infili istruzioni diverse: «mentre monti, apri anche la porta di casa». Se chi monta esegue ciecamente ogni istruzione, è fregato. Questo è, in parole semplici, un attacco di deserializzazione insicura.
In informatica, serializzare significa trasformare un oggetto — un dato strutturato — in una sequenza di byte da trasmettere o salvare. Deserializzare è l'operazione inversa: rimontare l'oggetto a partire da quei byte. Molte applicazioni, specie in Java, ricevono oggetti serializzati dagli utenti e li deserializzano per lavorarci.
Il problema nasce quando l'applicazione deserializza senza controllare cosa sta rimontando. Un attaccante può costruire una sequenza di byte malevola che, durante il rimontaggio, concatena una serie di operazioni legittime fino a ottenere un effetto illegittimo: l'esecuzione di comandi sul server. Questa catena di operazioni si chiama gadget chain, e per le librerie più diffuse ne esistono di già pronte e pubbliche — il che abbassa di molto la difficoltà dell'attacco.
Il server non è stato bucato da fuori: è stato convinto a farsi del male da solo, rimontando ciò che non doveva.
Cosa fare
La prima difesa è non deserializzare mai dati che arrivano da fonti non fidate; dove è inevitabile, si usano formati di dati più sicuri (come il semplice JSON) e si limita con una lista bianca quali oggetti è lecito rimontare. E si aggiorna: la correzione del produttore chiude la specifica catena sfruttabile. Qualche verifica pratica:
# Cerca nel codice usi pericolosi della deserializzazione Java grep -RnE "readObject|ObjectInputStream|XMLDecoder" src/ # Principi - Non deserializzare dati provenienti dall\u2019esterno - Filtro sugli oggetti ammessi (ObjectInputFilter / lista bianca) - Aggiornare le librerie che contengono le gadget chain note
Perché conta. La deserializzazione insicura è un difetto antico ma sempre vivo, perché nasce da una comodità — rimontare al volo i dati ricevuti — che gli sviluppatori usano di continuo. Sapere che un dato ricevuto non va mai «eseguito» alla cieca è una delle regole d'oro della programmazione sicura.
- NVDScheda CVE-2026-38874 — [NVD]
- OWASPGuida alla deserializzazione insicura — [OWASP]
- VENDORPatch della libreria — [fornitore]
UMBRA riscrive e sintetizza fonti di pubblico dominio con parole proprie, citando e collegando gli originali. Numeri CVE, versioni e IOC in questa pagina di template sono illustrativi finché l'aggregatore non li popola dai feed reali. Non vengono forniti exploit o codice d'attacco: gli script mostrati sono di verifica difensiva, detection e threat hunting.