L’insecure deserialization (deserializzazione non sicura) è una vulnerabilità che si manifesta quando un’applicazione deserializza — ricostruisce oggetti in memoria a partire da una rappresentazione serializzata — dati che provengono da fonti non fidate senza validazione sufficiente. Il problema è strutturale: la deserializzazione di oggetti complessi in linguaggi come Java, PHP e Python può eseguire codice arbitrario come effetto collaterale del processo di ricostruzione degli oggetti, prima ancora che l’applicazione possa ispezionare il contenuto.
Serializzazione e deserializzazione
La serializzazione è il processo di conversione di un oggetto in memoria in una sequenza di byte (o testo) per la trasmissione o la persistenza. La deserializzazione è l’operazione inversa. È usata pervasivamente per: session token, parametri di form, messaggi in code (JMS, RabbitMQ), RPC, cache, cookie.
Il problema nasce quando l’applicazione deserializza dati che l’attaccante può controllare e modificare — e quando il tipo di oggetto deserializzato ha metodi il cui comportamento a runtime è pericoloso.
Java: gadget chain
Java è il linguaggio storicamente più colpito. Il meccanismo di serializzazione nativo di Java (ObjectInputStream) invoca automaticamente il metodo readObject() dell’oggetto durante la deserializzazione. Se il classpath contiene classi (gadget) con readObject() che eseguono operazioni pericolose (riflessione, invocazione di metodi, esecuzione di comandi), l’attaccante può costruire un payload che le concatena per ottenere RCE.
ysoserial è il tool di riferimento per la generazione di payload Java di deserializzazione. Contiene gadget chain per le librerie più diffuse (Commons Collections, Spring, Hibernate). La vulnerabilità Apache Commons Collections (2015) ha dimostrato che librerie presenti in praticamente ogni applicazione Java enterprise contenevano gadget chain sfruttabili.
CVE-2017-9805 (Apache Struts): deserializzazione di XML in XStream ha permesso RCE su migliaia di server. CVE-2019-2725 (Oracle WebLogic): deserializzazione Java su porta T3 ha permesso RCE senza autenticazione su server WebLogic esposti su Internet.
PHP: Object Injection
PHP serializza gli oggetti in un formato testuale (O:4:"User":2:{s:4:"name";s:5:"Mario";...}). Durante la deserializzazione con unserialize(), PHP invoca automaticamente i magic method __wakeup() e __destruct() dell’oggetto ricostruito. Se una classe nel codebase ha implementazioni pericolose di questi metodi, l’attaccante può iniettare un oggetto di quella classe con attributi arbitrari.
L’attacco più comune è la property-oriented programming (POP chain): concatenare magic method di classi diverse per costruire una catena che porta a RCE, LFI (Local File Inclusion) o SQL injection.
Python: pickle
Il modulo pickle di Python è notoriamente pericoloso con input non fidato: deserializzare un pickle oggetto può eseguire codice Python arbitrario tramite il metodo __reduce__. Non esiste un modo sicuro di usare pickle con dati non fidati — la documentazione ufficiale Python lo avverte esplicitamente. Formati sicuri per la serializzazione di dati in Python sono JSON, msgpack o dataclass-based serializers.
Difese
Non deserializzare dati non fidati: la difesa principale. Sostituire la serializzazione nativa con formati di dati strutturati come JSON o Protocol Buffers, che serializzano solo dati, non oggetti con comportamento.
Firma crittografica: se i dati serializzati devono provenire dallo stesso sistema (es. session token), firmarli con HMAC prima di trasmetterli. Verificare la firma prima della deserializzazione — rifiutare dati con firma non valida senza deserializzarli.
Java deserialization filter (JEP 290, Java 9+): configurare un filtro che blocca la deserializzazione di classi non nella whitelist, limitando i gadget disponibili. Necessario ma non sufficiente — non elimina le gadget chain nelle classi permesse.
Aggiornare le dipendenze: molte gadget chain sfruttano librerie di terze parti con versioni vulnerabili. Mantenere aggiornate le dipendenze elimina i gadget conosciuti.