Perché JSON.stringify non è così innocuo come sembra
Gli sviluppatori utilizzano JSON. stringify ogni giorno per serializzare dati, inviare oggetti in rete, memorizzare lo stato in file o rendere persistenti le configurazioni. Ma questa chiamata apparentemente innocua a JSON. stringify può introdurre una deserializzazione non sicura se i dati vengono successivamente reidratati senza convalida.
Il problema non è JSON. stringify in sé, ma il modo in cui lo usiamo in modo improprio. Quando serializziamo oggetti complessi (specialmente con prototipi o istanze di classe) e li deserializziamo alla cieca in seguito usando JSON. analizzare, rischi di dare vita a payload dannosi all'interno della tua applicazione.
In JavaScript, è facile presumere che ciò che è serializzato sia sicuro perché è "semplicemente JSON." Ma JSON è fatto di dati, non di logica. Se gli aggressori controllano quei dati, possono sfruttare i limiti di attendibilità del codice. È qui che inizia la deserializzazione non sicura.
Errori comuni degli sviluppatori che consentono una deserializzazione non sicura
La deserializzazione non sicura deriva solitamente da abitudini che sembrano innocue nelle revisioni del codice. Ma quando JSON.stringify viene utilizzato in modo non corretto, la superficie di attacco si espande.
Pratica non sicura: serializzazione di input utente non convalidati
⚠️Attenzione: Questo pattern serializza l'input controllato dall'aggressore senza alcuna convalida. Potrebbe portare a una deserializzazione non sicura se i dati vengono successivamente considerati attendibili.
⚠️Attenzione: La deserializzazione degli stessi dati senza convalida può reintrodurre il payload nella tua app.
Modello pericoloso: riutilizzo di JSON oltre i confini di fiducia
Il codice JSON serializzato creato in un servizio (ambiente di sviluppo) viene riutilizzato in un altro (ambiente di produzione), senza convalida. Questo accade spesso negli strumenti interni o nei microservizi.
Esempio Python di rischio silenzioso:
⚠️Attenzione: Sia la serializzazione che la deserializzazione descritte di seguito gestiscono dati potenzialmente non attendibili senza convalida.
Entrambi gli esempi serializzano e deserializzano i dati controllati dall'utente senza imporre alcuno schema. Questo costituisce un terreno fertile per exploit di deserializzazione non sicuri, innescati da un utilizzo improprio di JSON.stringify.
Rischi reali in Pipelines: Dal codice a CI/CD Flussi di deserializzazione
Ora prendi quel comportamento in un pipeline. Quando JSON. stringify viene utilizzato in modo improprio all'interno CI/CD flussi di lavoro, esponi il tuo processo di build a rischi di deserializzazione non sicura. Questo accade spesso con i metadati degli artefatti, le fixture di test e gli snapshot di configurazione.
Uncommon CI/CD insidie:
- Generazione di artefatti non sicura: gli artefatti di build includono oggetti serializzati che vengono riutilizzati nei processi senza convalida.
- Variabili di ambiente serializzate: i team archiviano le variabili di ambiente come JSON serializzati e le riutilizzano in più fasi o persino progetti.
- Dati di test iniettati: dati di test deserializzati da non attendibili commits o rami eseguiti senza controllo del tipo.
Questi modelli facilitano l'inserimento di payload in sistemi attendibili da parte degli aggressori pipelineutilizzando la logica di stringa JSON manipolata.
⚠️Attenzione:Questo flusso di lavoro trasmette dati serializzati senza convalida. Se test-runner.js non convalida l'input, rischia una deserializzazione non sicura.
If test-runner.js carica e analizza JSON senza convalida, può innescare una deserializzazione non sicura.
Protezione di JSON. stringify con convalida e analisi sicura
La soluzione non è evitare JSON. stringify, ma usarlo con attenzione e applicare controlli di sicurezza in modo coerente. Gestito correttamente, è sicuro, ma nelle moderne pipelines, le ipotesi si rompono velocemente.
Pratiche DevSecOps per proteggere JSON.stringify:
- Utilizzare gli schemi JSON per convalidare i dati serializzati e deserializzati.
- Applicare una tipizzazione rigorosa, evitare il duck typing o le ipotesi sulle forme degli oggetti.
- Utilizzare librerie di analisi sicure che supportino l'applicazione dello schema o le protezioni dei tipi.
- Trattare i dati serializzati come non attendibili, anche se provengono da un repository attendibile.
- Strumento pipelineper individuare tempestivamente i modelli JSON.stringify rischiosi.
Best Practice: questo esempio utilizza la convalida dello schema JSON per prevenire la deserializzazione non sicura. Esempio utilizzando avv in Node.js:
La deserializzazione sicura significa convalidare prima fiducioso. Non affidarti a JSON. stringify defaults per la tua sicurezza; definisci cosa significa "sicuro".
Rilevamento dei rischi di serializzazione con Xygeni
L'audit manuale rileva solo una parte dei dati. Xygeni fornisce visibilità su come JSON.stringify viene utilizzato nella tua base di codice e pipelines.
Cosa fa Xygeni:
- tracce JSON.stringify utilizzo dal codice sorgente alla distribuzione.
- Rileva flussi di deserializzazione non sicuri, in particolare nei microservizi e pipeline fasi.
- Segnala la serializzazione di dati non sicuri come variabili ambientali, input utente o artefatti.
- Avvisi sulle deviazioni del modello, che mostrano quando i dati serializzati cambiano forma o superano i limiti di attendibilità.
Questo tipo di visibilità è fondamentale quando si ha a che fare con i rischi di deserializzazione non sicura introdotti da JSON.stringify, soprattutto in CI/CD sistemi in cui i dati serializzati si muovono in modo rapido e silenzioso.
Protezione JSON. stringify: Il tuo Shield Contro la deserializzazione insicura
JSON. stringify non è di per sé insicuro. Ma se usato senza cautela, diventa la porta d'accesso a una deserializzazione non sicura.
Se sei uno sviluppatore che lavora con JSON:
- Verifica il tuo utilizzo nei vari servizi, pipelinee strumenti.
- Trattare i dati deserializzati come non attendibili.
- Applica la convalida dello schema, applica i tipi e integra la sicurezza nel tuo CI/CD.
E non fermarti alle best practice: usa Xygeni per tracciare, rilevare e bloccare i rischi di deserializzazione non sicura prima che arrivino in produzione. La serializzazione non è neutrale. Fai in modo che il tuo utilizzo di JSON.stringify sicuro.
