Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Un'altra area di preoccupazione è il potenziale di vulnerabilità di sicurezza sfruttate dalle condizioni di gara. Ci sono diversi modi in cui questo potrebbe accadere. Gli argomenti secondari che seguono delineano alcune delle principali insidie che lo sviluppatore deve evitare.
Condizioni di gara nel metodo Dispose
Se il metodo Dispose di una classe (per altre informazioni, vedere Garbage Collection) non è sincronizzato, è possibile che il codice di pulizia all'interno di Dispose possa essere eseguito più volte, come illustrato nell'esempio seguente.
Sub Dispose()
If Not (myObj Is Nothing) Then
Cleanup(myObj)
myObj = Nothing
End If
End Sub
void Dispose()
{
if (myObj != null)
{
Cleanup(myObj);
myObj = null;
}
}
Poiché questa implementazione dispose non è sincronizzata, è possibile Cleanup
chiamare da un primo thread e quindi un secondo thread prima _myObj
di essere impostato su Null. Se si tratta di un problema di sicurezza dipende da ciò che accade quando viene eseguito il Cleanup
codice. Un problema importante con le implementazioni dispose non sincronizzate implica l'uso di handle di risorse come i file. L'eliminazione non corretta può causare l'uso dell'handle errato, che spesso causa vulnerabilità di sicurezza.
Condizioni di corsa nei Costruttori
In alcune applicazioni, potrebbe essere possibile che altri thread accedano ai membri della classe prima che i costruttori della classe abbiano terminato completamente la loro esecuzione. È consigliabile esaminare tutti i costruttori di classi per assicurarsi che non siano presenti problemi di sicurezza, se necessario, o sincronizzare i thread.
Condizioni di gara con oggetti memorizzati nella cache.
Il codice che memorizza nella cache le informazioni di sicurezza o usa l'operazione Assert per l'accesso al codice potrebbe anche essere vulnerabile alle race condition se altre parti della classe non sono sincronizzate in modo appropriato, come illustrato nell'esempio seguente.
Sub SomeSecureFunction()
If SomeDemandPasses() Then
fCallersOk = True
DoOtherWork()
fCallersOk = False
End If
End Sub
Sub DoOtherWork()
If fCallersOK Then
DoSomethingTrusted()
Else
DemandSomething()
DoSomethingTrusted()
End If
End Sub
void SomeSecureFunction()
{
if (SomeDemandPasses())
{
fCallersOk = true;
DoOtherWork();
fCallersOk = false;
}
}
void DoOtherWork()
{
if (fCallersOK)
{
DoSomethingTrusted();
}
else
{
DemandSomething();
DoSomethingTrusted();
}
}
Se ci sono altri percorsi verso DoOtherWork
che possono essere chiamati da un altro thread con lo stesso oggetto, un chiamante non attendibile può eludere una richiesta.
Se il codice memorizza nella cache le informazioni di sicurezza, assicurarsi di esaminarlo per questa vulnerabilità.
Condizioni di gara nei finalizzatori
Le condizioni di gara possono verificarsi anche in un oggetto che fa riferimento a una risorsa statica o non gestita, che viene poi liberata nel suo finalizzatore. Se più oggetti condividono una risorsa modificata nel finalizzatore di una classe, gli oggetti devono sincronizzare tutti gli accessi a tale risorsa.