Megosztás a következőn keresztül:

Biztonsági és versenyfeltételek

  • Cikk

Egy másik aggodalomra okot adó terület a versenyfeltételek által kihasznált biztonsági rések lehetősége. Ennek többféle módja is lehet. Az alábbi altopikák ismertetik a fejlesztő által elkerülendő főbb buktatókat.

Versenyfeltételek a megsemmisítési módszerben

Ha egy osztály lomtalanítási metódusa (további információkért lásd: Szemétgyűjtés) nincs szinkronizálva, lehetséges, hogy az Elidegenítésben lévő törlési kód többször is futtatható, ahogy az alábbi példában is látható.

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

Mivel ez az Elvetés implementáció nincs szinkronizálva, lehetségesCleanup, hogy először egy szál, majd egy második szál hívja meg, mielőtt _myObj null értékűre lenne állítva. Attól függ, hogy ez biztonsági probléma-e, attól függ, hogy mi történik a Cleanup kód futtatásakor. A nem aszinkron elidegenítési implementációkkal kapcsolatos egyik fő probléma az erőforrás-kezelők, például a fájlok használata. A nem megfelelő ártalmatlanítás a helytelen leíró használatát okozhatja, ami gyakran biztonsági réseket okoz.

Versenyfeltételek a konstruktorokban

Egyes alkalmazásokban előfordulhat, hogy más szálak hozzáférhetnek az osztálytagokhoz, mielőtt az osztálykonstruktorok teljesen lefutnak. Tekintse át az összes osztálykonstruktort, hogy biztosan ne legyen biztonsági probléma, ha ez bekövetkezik, vagy szükség esetén szinkronizálja a szálakat.

Versenyfeltételek gyorsítótárazott objektumokkal

A biztonsági információkat gyorsítótárazó vagy a kódhozzáférés biztonsági érvényesítése műveletet használó kód is sebezhető lehet a versenyfeltételekkel szemben, ha az osztály más részei nincsenek megfelelően szinkronizálva, ahogy az az alábbi példában is látható.

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

Ha más elérési utak DoOtherWork is meghívhatók ugyanahhoz az objektumhoz tartozó másik szálról, a nem megbízható hívó átcsúszhat egy igényen.

Ha a kód gyorsítótárazza a biztonsági információkat, ellenőrizze, hogy áttekinti-e a biztonsági rést.

Versenyfeltételek a Finalizersben

A versenyfeltételek olyan objektumokban is előfordulhatnak, amelyek egy statikus vagy nem felügyelt erőforrásra hivatkoznak, amelyet aztán felszabadít a véglegesítőben. Ha egy osztály véglegesítőjében manipulált erőforrás több objektumot is használ, az objektumoknak szinkronizálnia kell az adott erőforráshoz való összes hozzáférést.

Lásd még