Sicurezza Heap memoria: Garbage Collection stringa

Question

Recentemente ho eseguito una revisione del codice di sicurezza per la mia azienda e utilizzando uno strumento denominato Fortify360. Identificherà molti problemi con il codice e descriverà i problemi. Un problema interessante che ha rilevato che non ho trovato altre informazioni è il seguente:

"I dati sensibili (come le password) archiviati in memoria possono essere trapelati se sono memorizzati in un oggetto String gestito. non sono bloccati, quindi il garbage collector può riposizionare questi oggetti a piacimento e lasciare diverse copie in memoria.Questi oggetti non sono crittografati per impostazione predefinita, quindi chiunque possa leggere il processo 'memoria sarà in grado di vedere il contenuto. processo 'memoria viene trasferito su disco, il contenuto non crittografato della stringa verrà scritto in un file di scambio.Infine, dal momento che gli oggetti stringa sono immutabili, la rimozione del valore di una stringa dalla memoria può essere effettuata solo dal garbage collector CLR. Garbage Collector non è richiesto per l'esecuzione a meno che il CLR abbia poca memoria, quindi non c'è alcuna garanzia in merito a quando garbage collecti su avrà luogo. In caso di crash dell'applicazione, un dump di memoria dell'applicazione potrebbe rivelare dati sensibili."

Tutto questo ho capito di fare buon senso e nella mia ricerca del problema è abbastanza standard.

Il la domanda è: come risolvo il problema? Supponiamo che la classe o le classi che sono in questione non possano ereditare da iDisposable (app molto grande, e la classe è necessaria molto tempo dopo la stringa in questione). Esiste un modo alternativo di gestione manuale della memoria per smaltire una stringa specifica senza chiamare il garbage collector, GC.Collect() ??

Apprezzare l'aiuto in anticipo

Alex

Answer 1

Se si vuole evitare questo è necessario utilizzare System.SecureString, che è IDisposable, per contenere i dati sensibili, trattenendo ciò solo per l'eventuale tempo minimo necessario.

È un po 'ironico che il codice di esempio MSDN non contenga l'istanza Dispose, esplicitamente o con l'incapsulamento using.

Answer 2

Onestamente, risolvere questo "problema" sarà più un problema che ne vale la pena.

Mantenere le password inviate dall'utente nelle stringhe non può essere impedito quando si utilizzano tecnologie come ASP.NET, a meno che non si intenda crittografare le stringhe lato client prima di inviarle, poiché ASP.NET le memorizzerà come stringhe nelle raccolte di moduli , ecc.

E se si è passati al percorso di crittografia JS, si noti che qualsiasi potenziale aggressore sarebbe in grado di decrittografare le stringhe recuperate dall'applicazione.

Tuttavia, se qualcuno ha violato il server Web, è probabile che possa compromettere l'intero database. E questo è un problema molto peggiore rispetto alla raccolta di alcune password dall'heap del server web ...

Ora, se questa non è un'applicazione ASP.NET, e si ha il controllo completo su come le password vengono elaborate nel codice, potresti dare un'occhiata a SecureString. Ma potresti ancora scoprire che i benefici minimi superano la maggiore complessità del codice. Dipende davvero dalla cattiva perdita di una password e dalla vulnerabilità delle macchine a essere compromesse in primo luogo. Se non sei preoccupato che alcuni utenti malintenzionati possano eseguire il debug dei tuoi processi e acquisire istantanee di memoria, questo è davvero un problema.

In sintesi: se un utente malintenzionato ha il potere di estrarre queste stringhe dalla memoria o dallo scambio, , ha anche il potere di fare cose che sono molto peggiori.