Deserializzazione non sicura = Esecuzione di codice remoto

. Commit Che ha aperto una porta sul retro

È stata integrata una nuova funzionalità per gestire gli oggetti caricati dagli utenti. Tutto supera i test, ma settimane dopo, un pentest rivela che gli aggressori possono eseguire comandi sul server; il risultato è una deserializzazione non sicura nascosta nel codice. Il divario tra la deserializzazione e l'esecuzione di codice remoto può essere pericolosamente ridotto, soprattutto quando i dati serializzati provenienti da pacchetti open source o servizi interni sono considerati attendibili senza convalida.

Cos'è la deserializzazione nel codice, perché è rischiosa e dove si nasconde

In termini di sviluppatori, cos'è la deserializzazione? È il processo di prendere dati strutturati, JSON, XML, formati binari o oggetti serializzati specifici del linguaggio e trasformarli nuovamente in oggetti in memoria.

Da solo, deserializzazione è innocuo e comune, ad esempio:

Java: Leggere oggetti con ObjectInputStream
Python: Caricamento dati con sottaceto.carico
Node.js: Analisi JSON con JSON.parse

Il rischio si presenta quando la deserializzazione viene applicata a dati non attendibili senza convalida. Un aggressore può creare input che attivano una catena di gadget, ovvero percorsi di codice esistenti utilizzati in modi indesiderati, che possono portare all'esecuzione di codice remoto.

pericoloso deserializzazione si trova spesso in:

Pacchetti open source con impostazioni predefinite non sicure
Codice personalizzato che presuppone che l'input serializzato sia affidabile
API di terze parti stanno restituendo oggetti serializzati senza verifica
Costruisci artefatti per esempio:
- Java .ser file contenenti oggetti pre-serializzati.
- Python .pkl file modello nei flussi di lavoro di apprendimento automatico.
- Oggetti di configurazione serializzati incorporati in immagini Docker o contenitori di distribuzione

Apparecchiature di prova per esempio:
- Vecchi dati di test serializzati copiati da snapshot di produzione.
- Payload serializzati scaricati da repository esterni per test di prestazioni o di regressione.

Questi file possono essere introdotti in un repository e caricati automaticamente durante i test o le distribuzioni, innescando comportamenti non sicuri deserializzazione in CI/CD pipelineprima ancora che il codice raggiunga la fase di produzione.

Dalla deserializzazione non sicura all'esecuzione di codice remoto: il percorso di attacco

La catena di sfruttamento per la deserializzazione non sicura segue spesso uno di questi schemi:

Un input non attendibile entra nell'applicazione.
La deserializzazione non sicura ricrea gli oggetti senza restrizioni.
Una catena di gadget attiva funzionalità esistenti in modi non previsti.
L'aggressore aumenta i privilegi e riesce a eseguire codice in modalità remota.

varianti:

Le catene di gadget Java sfruttano vecchie librerie come Apache Commons.
Python .pkl caricamento del modello con oggetti dannosi incorporati.
Analisi JSON di Node.js con eval () o importazioni dinamiche.

Flusso:

Untrusted Input → Deserialization → Gadget Chain → Remote Code Execution

Come individuare la deserializzazione non sicura prima dell'unione

Rilevare la deserializzazione non sicura prima dell'unione del codice è molto più economico che risolverla dopo la distribuzione. Una combinazione di analisi automatizzata e test proattivi funziona meglio:

Test di sicurezza delle applicazioni statiche (SAST):
- Configurare gli scanner per rilevare API rischiose come ObjectInputStream, sottaceto.caricoe YAML.load senza un caricatore sicuro.
- Scansiona sia il codice sorgente che gli artefatti di build/test per individuare elementi non sicuri deserializzazione modelli.
- Visualizza i risultati direttamente in pull requests in modo che gli sviluppatori possano risolverli prima di procedere alla fusione.
CI/CD Integrazione::

Esempio di flusso di lavoro:

sql

Commit → SAST scan → PR alert → Fix before merge

Blocca le unioni in base ai risultati critici di deserializzazione non sicura per impedire al codice non sicuro di raggiungere i rami di produzione.

Test unitari con input dannosi simulati:
- Crea carichi utili innocui e controllati che imitano i comuni oggetti di attacco serializzati.
- Verificare come l'applicazione li gestisce: dovrebbe rifiutare, sanificare o registrare l'input anziché elaborarlo alla cieca.
- Includere questi test nell'automazione pipeline quindi vengono eseguiti su ogni PR, individuando tempestivamente comportamenti di deserializzazione non sicuri.
- Assicurarsi che i payload di test siano non eseguibili e sicuri da archiviare nel repository, concentrandosi esclusivamente sulla logica di rilevamento.

Questo approccio a strati combina la scansione automatizzata con test di proprietà degli sviluppatori, garantendo che i percorsi di deserializzazione non sicuri vengano identificati e rimossi molto prima che possano trasformarsi in vulnerabilità di esecuzione di codice remoto.

Strategie di prevenzione per gli sviluppatori: impedire che la deserializzazione diventi esecuzione di codice remoto

Confini di fiducia: Deserializzare solo da fonti autenticate e verificate.
API sicure:
- Java: librerie sicure con convalida.
- Python: Usa json.load() ancora sottaceti.carichi() dove possibile.
- Node.js: evitare eval () o esecuzione dinamica del codice.
Liste consentite e schemi: Limita i tipi di oggetti consentiti. Applica gli schemi JSON.
Igiene delle dipendenze: Monitora i CVE che menzionano la deserializzazione o l'esecuzione di codice remoto.
Revisioni del codice: Inserisci deserializzazione controlli di sicurezza per modelli di revisione delle relazioni pubbliche.

Nota sugli utensili: utensili come Xygeni analizzare il codice e le dipendenze per individuare eventuali deserializzazioni non sicure prima dell'unione, identificando le aree ad alto rischio in modo che gli sviluppatori possano risolverle tempestivamente.

Esempi di modelli di rilevamento tra le lingue (Pseudo-codice sicuro)

Tutti gli esempi riportati di seguito sono pseudo-codici ripuliti che mostrano modelli di rilevamento, non exploit funzionanti:

Java – Rilevamento dell'utilizzo non sicuro dell'API:

java
// BAD: Accepting untrusted input without validation
ObjectInputStream in = new ObjectInputStream(userInputStream);
Object obj = in.readObject(); // Unsafe - no class type checks

// GOOD: Validate allowed classes before processing
if (allowedClasses.contains(obj.getClass().getName())) {
    process(obj); // Safe processing of approved classes
}

Python – Evitare la deserializzazione non sicura:

python
import pickle

# BAD: Loading untrusted serialized data directly
data = pickle.loads(untrusted_input)  # Unsafe - arbitrary object execution risk

# GOOD: Use JSON with schema validation
import json
data = json.loads(untrusted_input)  # Safe when validated against schema

Node.js – Prevenzione dell'esecuzione dinamica del codice:

javascript
// BAD: Executing code from parsed data
let obj = JSON.parse(untrustedInput);
eval(obj.code); // Unsafe - allows arbitrary code execution

// GOOD: Use fixed logic without dynamic execution
let safeObj = JSON.parse(untrustedInput);
process(safeObj); // Handle only expected properties and values

Automazione del rilevamento in DevSecOps Pipelines: Rilevare la deserializzazione prima che raggiunga la produzione

L'automazione del rilevamento della deserializzazione non sicura garantisce le vulnerabilità vengono rilevate e corrette prima che portino all'esecuzione di codice remoto in produzione.

Pipeline Scansione

Correre SAST sul codice sorgente, sui file di configurazione e sugli artefatti di compilazione ad ogni commit.
Rileva modelli di deserializzazione non sicuri sia nel codice applicativo che dipendenze.

Ispezione degli artefatti

Scansione .ser, .pkl, e altri file serializzati per individuare modelli non sicuri prima di distribuire o addirittura eseguire i test.

Pull Request Prodotti di blocco

Il blocco si unisce se viene rilevata una deserializzazione non sicura.
Mostra feedback fruibili nelle PR per accelerare la risoluzione dei problemi.

Applicazione dei test unitari

Includere test unitari con input dannosi simulati nel CI/CD pipeline
Le build falliscono se l'applicazione elabora dati serializzati non sicuri anziché rifiutarli.

Evitare falsi positivi senza indebolire le regole

Non disattivare le regole di rilevamento per "silenziare" gli avvisi; ciò potrebbe consentire a una vera deserializzazione non sicura di passare inosservata.
Utilizzare una whitelist controllata (lista consentita) per modelli o dipendenze noti e sicuri.
Richiedi la convalida di sicurezza prima di approvare le voci della whitelist.
Mantenere la whitelist sotto controllo di versione e rivederla periodicamente per garantire che tutte le eccezioni rimangano giustificate e sicure.

Il ruolo di Xygeni

Si integra direttamente in CI/CD pipelineper analizzare sia il codice sorgente che gli artefatti di creazione.
Rileva modelli di deserializzazione non sicuri e dipendenze rischiose nelle prime fasi del ciclo di vita.
Supporta la whitelist basata su policy con revisione di sicurezza obbligatoria, bilanciando la precisione del rilevamento con la produttività degli sviluppatori.

Anticipare l'esecuzione di codice remoto tramite la deserializzazione sicura

La deserializzazione non sicura può passare inosservata finché non diventa un percorso diretto verso l'esecuzione di codice remoto. Per prevenirla è necessario:

Capire cos'è la deserializzazione e come può essere abusata.
Integrazione del rilevamento automatico nel flusso di lavoro di sviluppo.
Revisione regolare delle dipendenze, degli artefatti di build e dei dati serializzati utilizzati nei test.

Ruolo pratico di Xygeni in questo processo:

Scansione del codice sorgente: Identifica modelli di deserializzazione non sicuri in più linguaggi prima che il codice venga unito.
Analisi degli artefatti e delle dipendenze: Rileva i file serializzati rischiosi (.ser, .pkl, configurazione incorporata) e componenti di terze parti con vulnerabilità note.
Controlli basati su policy: Supporta un elenco di elementi consentiti controllato con convalida di sicurezza, garantendo che le eccezioni necessarie non introducano rischi reali.
Feedback degli sviluppatori nel contesto: Segnala la posizione esatta e la causa della deserializzazione non sicura all'interno pull requests, consentendo agli sviluppatori di risolvere immediatamente i problemi e di confermare la mitigazione tramite nuove scansioni.

Integrando controlli come questi direttamente in CI/CD, i team possono individuare e correggere le vulnerabilità non sicure deserializzazione prima che abbia la possibilità di trasformarsi in esecuzione di codice remoto in produzione.

Come la deserializzazione non sicura diventa esecuzione di codice remoto (e come individuarla prima dell'unione)

Sommario

Post da leggere assolutamente

Ultimi post di interesse