Ambito e sicurezza delle variabili

1

Questa domanda è diretta al framework .Net, ma si spera che si possa rispondere per comprendere molte lingue e amp; quadri.

Supponiamo di avere due metodi, uno che in realtà decifra i dati e uno che prende i dati decriptati e li restituisce all'utente:

private string Decypt_Data(string encryptedText, string EncryptionKey) {

    string plainText = "";
    using(SomeEncryptionClass  myObject = new SomeEncryptionClass()) {

        myObject.Key = EncryptionKey;  //lets not worry about how we create or store these
        myObject.IV = GetIV();

        plainText = myObject.DecryptText(encryptedText);  

    }

    return plainText;  //REFERENCE 1

}

//specifically this is called from a controller after a POST
private ActionResult Read_Encrypted_Value()
{

    string encryptedEncryptionKey = GetDataFromDatabase("keyfield");
    string encryptionKey = Decypt_Data(encryptedEncryptionKey, GetKeyFromSomeWhereThisIsUnImportant());

    //decrypt data with plainText (ie. plainText is a key.. but this isnt important to the question)
    syromg encryptedData = GetDataFromDatabase("datafield");

    return View(Decypt_Data(encryptedData, encryptionKey));   //RFERENCE 2

}   

Osservando il metodo Decrypt_Data, il testo crittografato viene passato e decodificato, quindi viene restituito il testo semplice.

La domanda è ... quanto è sicuro il valore memorizzato in "plainText" (in REFERENCE 1)?

La variabile plainText dura solo per l'ambito del metodo ... ma cosa allora? Questo valore rimane in memoria finché il Garbage Collector non lo gestisce? Ottiene NULLed o qualcosa del genere? Dovrei fare qualcosa come in REFERENCE 2, dove faccio il calcolo e restituisco il valore insieme? Devo passare le stringhe come riferimenti, in modo che la variabile che restituisce il valore non debba essere istanziata?

Se il valore rimane in memoria, non è vulnerabile? Un utente malintenzionato non può leggere la memoria e rubare il valore? (Sto lavorando sul princaplo che questo valore è usato per decriptare altri dati ... quindi l'autore dell'attacco che ha accesso diretto al database non gli da tutti i dati).

La risposta

Grazie mille a tutti per le vostre risposte, ho trovato questo articolo: collegamento in uno dei collegamenti dalla risposta dell'utente10008. Copre praticamente tutto ciò che è necessario sapere + completare l'elenco dei codici.

    
posta binks 11.09.2014 - 14:25
fonte

3 risposte

0

Hai ragione, questo è un problema comune per la gestione dei dati sensibili del codice. Nell'ambiente gestito .Net, anche se azzerassi la tua stringa, avresti comunque dei problemi, a causa di spostamento della stringa come risultato della garbage collection . Il garbage collector vuole deframmentare l'heap e quindi può muovere la stringa. Lo spostamento naturalmente non azzera i dati, è piuttosto una copia. Pertanto dovresti dire al GC di "appuntare" la stringa particolare per impedirne il movimento. Vedi sopra il link su come farlo.

E no, i dati non vengono azzerati, è possibile che quando il programma esce (o prima quando libera la memoria), questa memoria diventa disponibile per eventuali altri processi ostili.

SecureString può memorizzare i dati in modo sicuro, ma è comunque necessario interfacciarli con il mondo esterno. Questa domanda copre questo argomento.

    
risposta data 11.09.2014 - 15:10
fonte
0

Questo dipende realmente dalla lingua, se è compilata, allora quale compilatore è stato usato.

The question is... how secure is the value stored in "plainText" (at REFERENCE 1)?

Senza usare una speciale classe sicura questa variabile risiederà in memoria fino a quando non verrà sovrascritta. Non tutte le lingue forniscono una "classe sicura" per i dati. La liberazione della memoria non implica sempre l'azzeramento della memoria. Invalida solo il puntatore con il gestore della memoria. Alcuni garbage collector potrebbero azzerare automaticamente la memoria per te, C ovviamente non azzererà nulla quando libererai memoria.

If the value remains in memory, is it not vulnerable?

È ancora vulnerabile alle letture della memoria. Se quella porzione di memoria non viene sovrascritta e un utente malintenzionato legge quella memoria, il testo in chiaro sarà lì. Questo vale anche se il programma è stato chiuso.

Il modo migliore per attenuare questo problema in generale è limitare l'ambito dei dati sensibili e sovrascrivere la memoria quando hai finito di usarlo. Puoi azzerarlo, puoi sovrascriverlo con dati casuali, qualunque cosa tu voglia. In questo modo quando la memoria viene visualizzata al di fuori del suo ambito non ci sono dati sensibili.

In .NET, il garbage collector sovrascriverà la memoria degli oggetti morti quando le variabili lasciano l'ambito. Questo articolo di 2 pagine spiega .NET Garbage Collection

Once the dead objects have been identified, the garbage collector starts a new procedure. This moves the live objects within the heap, overwriting the memory used by the dead objects to remove dead items and make the heap contiguous again.

Continuerò comunque a sovrascrivere i dati per sicurezza (se possibile, dipende dalla lingua). Ma sono anche un po 'paranoico.

    
risposta data 11.09.2014 - 15:18
fonte
-1

In .Net è possibile utilizzare una stringa sicura per avere un certo livello di protezione contro la lettura della memoria in questo modo: link

    
risposta data 11.09.2014 - 14:57
fonte

Leggi altre domande sui tag