La serializzazione trasforma un oggetto in un formato trasmissibile (byte, stringa); la deserializzazione lo ricostruisce. Il problema nasce quando si deserializza input non fidato con meccanismi che possono istanziare oggetti arbitrari ed eseguire codice durante la ricostruzione – e allora un payload malevolo diventa esecuzione di codice remoto (RCE), la vulnerabilità più grave che esista.
I casi noti per linguaggio: il pickle di Python (letteralmente codice eseguibile serializzato – il rischio dei modelli ML in formato legacy), la Java deserialization (le famigerate gadget chain che concatenano classi presenti nell'applicazione per ottenere RCE), il YAML unsafe load, il marshal e i serializzatori PHP. In tutti, l'attaccante costruisce un flusso serializzato che, deserializzato, esegue le sue istruzioni.
Le difese:
- non deserializzare mai input non fidato con serializzatori che possono eseguire codice – la regola prima di tutte
- preferire formati solo-dati: JSON, o safetensors per i modelli – un formato che contiene dati e non codice non può eseguire nulla
- se devi deserializzare oggetti, usa le versioni safe (safe_load di YAML), allowlist delle classi permesse, e verifica l'integrità (firma/HMAC) del dato serializzato prima di toccarlo
È nella OWASP Top 10 (Software and Data Integrity Failures), e la radice è la stessa di tanto altro: input non fidato trattato come fidato. La lezione trasversale dell'appsec vale anche qui – un flusso di byte che arriva dall'esterno è ostile finché non dimostrato innocuo, e certi meccanismi "comodi" trasformano quell'input direttamente in codice eseguito.