Rischi di deserializzazione nell'uso di BinaryFormatter e dei tipi correlati

Questo articolo si applica ai tipi seguenti:

Questo articolo si applica alle implementazioni di .NET seguenti:

  • .NET Framework tutte le versioni
  • .NET Core 2.1 - 3.1
  • .NET 5 e versioni successive

Avviso

Il BinaryFormatter tipo è pericoloso e non è consigliato per l'elaborazione dei dati. Le applicazioni devono smettere di usare BinaryFormatter il prima possibile, anche se ritengono che i dati elaborati siano attendibili. BinaryFormatter non è sicuro e non può essere reso sicuro.

Vulnerabilità di deserializzazione

Le vulnerabilità di deserializzazione sono una categoria di minacce in cui i payload delle richieste vengono elaborati in modo non sicuro. Un utente malintenzionato che sfrutta correttamente queste vulnerabilità contro un'app può causare denial of service (DoS), divulgazione di informazioni o esecuzione remota del codice all'interno dell'app di destinazione. Questa categoria di rischio rende coerente la top 10 di OWASP. Le destinazioni includono app scritte in diversi linguaggi, tra cui C/C++, Java e C#.

In .NET, la destinazione di rischio maggiore è costituito dalle app che usano il BinaryFormatter tipo per deserializzare i dati. BinaryFormatter è ampiamente usato in tutto l'ecosistema .NET a causa della sua potenza e della sua facilità d'uso. Tuttavia, questa stessa potenza offre agli utenti malintenzionati la possibilità di influenzare il flusso di controllo all'interno dell'app di destinazione. Gli attacchi riusciti possono causare l'esecuzione del codice nel contesto del processo di destinazione da parte dell'utente malintenzionato.

Come analogia più semplice, si supponga che la chiamata BinaryFormatter.Deserialize a un payload sia l'equivalente di interpretare tale payload come eseguibile autonomo e avviarlo.

Vulnerabilità di sicurezza binaryFormatter

Avviso

Il BinaryFormatter.Deserialize metodo non è mai sicuro quando viene usato con input non attendibile. È consigliabile invece che gli utenti considerino l'uso di una delle alternative descritte più avanti in questo articolo.

BinaryFormatter è stata implementata prima della deserializzazione le vulnerabilità erano una categoria di minacce ben compresa. Di conseguenza, il codice non segue le procedure consigliate moderne. Il Deserialize metodo può essere usato come vettore per gli utenti malintenzionati per eseguire attacchi DoS contro l'utilizzo delle app. Questi attacchi potrebbero rendere l'app non risponde o causare la chiusura imprevista del processo. Questa categoria di attacchi non può essere mitigata con un'altra SerializationBinderBinaryFormatter opzione di configurazione o . .NET considera questo comportamento in base alla progettazione e non genera un aggiornamento del codice per modificare il comportamento.

BinaryFormatter.Deserialize può essere vulnerabile ad altre categorie di attacchi, ad esempio la divulgazione di informazioni o l'esecuzione di codice remoto. L'utilizzo di funzionalità come un personalizzato SerializationBinder potrebbe non essere sufficiente per attenuare correttamente questi rischi. Esiste la possibilità che venga individuata una nuova vulnerabilità per la quale .NET non può pubblicare praticamente un aggiornamento della sicurezza. I consumatori devono valutare i singoli scenari e considerare la loro potenziale esposizione a questi rischi.

È consigliabile che BinaryFormatter i consumatori eseguano valutazioni dei rischi individuali nelle proprie app. È responsabilità esclusiva del consumatore determinare se utilizzare BinaryFormatter. Se si sta valutando di usarlo, è consigliabile valutare la sicurezza, la reputazione, la reputazione, la legalità e le conseguenze normative.

Alternative preferite

.NET offre diversi serializzatori predefiniti in grado di gestire in modo sicuro i dati non attendibili:

Alternative pericolose

Evitare i serializzatori seguenti:

I serializzatori precedenti eseguono tutte la deserializzazione polimorfica senza restrizioni e sono pericolosi, proprio come BinaryFormatter.

I rischi di supporre che i dati siano attendibili

Spesso, uno sviluppatore di app potrebbe credere che stia elaborando solo input attendibile. Il caso di input sicuro è vero in alcune circostanze rare. Ma è molto più comune che un payload attraversa un limite di trust senza che lo sviluppatore lo renda conto.

Si consideri un server locale in cui i dipendenti usano un client desktop dalle workstation per interagire con il servizio. Questo scenario potrebbe essere considerato ingenuo come una configurazione "sicura" in cui l'utilizzo BinaryFormatter è accettabile. Tuttavia, questo scenario presenta un vettore di malware che ottiene l'accesso al computer di un singolo dipendente per poter essere distribuito in tutta l'azienda. Tale malware può sfruttare l'uso dell'organizzazione di BinaryFormatter per passare successivamente dalla workstation del dipendente al server back-end. Può quindi esfiltrare i dati sensibili dell'azienda. Tali dati possono includere segreti commerciali o dati dei clienti.

Prendere in considerazione anche un'app che usa BinaryFormatter per salvare in modo permanente lo stato. Questo potrebbe inizialmente sembrare uno scenario sicuro, poiché la lettura e la scrittura di dati sul proprio disco rigido rappresentano una minaccia secondaria. Tuttavia, la condivisione di documenti tramite posta elettronica o Internet è comune e la maggior parte degli utenti finali non percepisce l'apertura di questi file scaricati come comportamento rischioso.

Questo scenario può essere sfruttato per influire in modo nefarioso. Se l'app è un gioco, gli utenti che condividono i file salvati inconsapevolmente si trovano a rischio. Gli sviluppatori stessi possono anche essere destinati. L'utente malintenzionato potrebbe inviare un messaggio di posta elettronica al supporto tecnico degli sviluppatori, allegando un file di dati dannosi e chiedendo al personale di supporto di aprirlo. Questo tipo di attacco potrebbe dare all'utente malintenzionato un punto di appoggio nell'azienda.

Un altro scenario è quello in cui il file di dati viene archiviato nell'archiviazione cloud e sincronizzato automaticamente tra i computer dell'utente. Un utente malintenzionato in grado di ottenere l'accesso all'account di archiviazione cloud può avvelenare il file di dati. Questo file di dati verrà sincronizzato automaticamente con i computer dell'utente. Al successivo apertura del file di dati da parte dell'utente, viene eseguito il payload dell'utente malintenzionato. L'utente malintenzionato può quindi sfruttare una compromissione di un account di archiviazione cloud per ottenere autorizzazioni di esecuzione del codice complete.

Si consideri un'app che passa da un modello di installazione desktop a un modello cloud-first. Questo scenario include app che passano da un'app desktop o un modello client avanzato a un modello basato sul Web. I modelli di minaccia creati per l'app desktop non sono necessariamente applicabili al servizio basato sul cloud. Il modello di minaccia per l'app desktop potrebbe ignorare una determinata minaccia come "non interessante per il client per attaccare se stesso". Ma la stessa minaccia potrebbe diventare interessante quando considera un utente remoto (il client) che attacca il servizio cloud stesso.

Nota

In termini generali, la finalità della serializzazione consiste nel trasmettere un oggetto all'interno o all'esterno di un'app. Un esercizio di modellazione delle minacce contrassegna quasi sempre questo tipo di trasferimento dei dati come superamento di un limite di trust.

Vedi anche