Delen via

Beveiligings- en racevoorwaarden

Een ander aandachtspunt is het potentieel voor beveiligingsgaten die worden misbruikt door raceomstandigheden. Er zijn verschillende manieren waarop dit kan gebeuren. De subonderwerpen die volgen geven een overzicht van enkele van de belangrijkste valkuilen die de ontwikkelaar moet vermijden.

Racevoorwaarden in de verwijderingsmethode

Als de verwijderingsmethode van een klasse (voor meer informatie, zie Garbagecollection) niet is gesynchroniseerd, is het mogelijk dat opschoningscode in Verwijdering meer dan één keer kan worden uitgevoerd, zoals wordt weergegeven in het volgende voorbeeld.

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;  
    }  
}

Omdat deze verwijderings-implementatie niet wordt gesynchroniseerd, kan Cleanup worden aangeroepen door de eerste thread en vervolgens een tweede thread voordat _myObj is ingesteld op null. Of dit een beveiligingsprobleem is, is afhankelijk van wat er gebeurt wanneer de Cleanup code wordt uitgevoerd. Een belangrijk probleem met niet-gesynchroniseerde verwijderings-implementaties omvat het gebruik van resource-ingangen, zoals bestanden. Onjuiste verwijdering kan ertoe leiden dat de verkeerde handgreep wordt gebruikt, wat vaak leidt tot beveiligingslekken.

Raceomstandigheden in constructors

In sommige toepassingen kan het mogelijk zijn dat andere threads toegang kunnen krijgen tot de leden van de klasse voordat hun constructoren van de klasse volledig zijn uitgevoerd. Controleer alle klasseconstructors om er zeker van te zijn dat er geen beveiligingsproblemen zijn als dit moet gebeuren, of synchroniseer indien nodig threads.

Racevoorwaarden met objecten in cache

Code die beveiligingsinformatie in de cache opslaat of de codetoegang beveiligingsbewerking Assert gebruikt, kan ook kwetsbaar zijn voor racecondities als andere delen van de klasse niet op de juiste manier worden gesynchroniseerd, zoals wordt getoond in het volgende voorbeeld.

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();  
    }  
}

Als er andere paden naar DoOtherWork zijn die vanuit een andere thread met hetzelfde object kunnen worden aangeroepen, kan een niet-vertrouwde beller gemakkelijk langs een beveiligingseis komen.

Als uw code beveiligingsgegevens in de cache opslaat, zorg dat u deze controleert op deze kwetsbaarheid.

Racevoorwaarden in Finalizers

Racevoorwaarden kunnen ook optreden in een object dat verwijst naar een statische of onbeheerde resource die vervolgens wordt vrijgemaakt in de finalizer. Als meerdere objecten een resource delen die wordt gemanipuleerd in de finalizer van een klasse, moeten de objecten alle toegang tot die resource synchroniseren.

Zie ook

  • Last updated on