SafeHandle verwenden, um systemeigene Ressourcen einzukapseln

Aktualisiert: November 2007

Ursache

In verwaltetem Code wird IntPtr für den Zugriff auf systemeigene Ressourcen verwendet.

Regelbeschreibung

Die Verwendung von IntPtr in verwaltetem Code kann auf ein potenzielles Sicherheitsrisiko und Zuverlässigkeitsproblem hinweisen. Alle Vorkommen von IntPtr müssen daher überprüft werden, um festzustellen, ob stattdessen die Verwendung von SafeHandle (oder einer ähnlichen Technologie) erforderlich ist. Probleme treten auf, wenn IntPtr eine systemeigene Ressource darstellt (Speicher, Dateihandle, Socket usw.), von der angenommen wird, dass sie sich im Besitz des verwalteten Codes befindet. Daher wird erwartet, dass der verwaltete Code die Ressource freigibt. Falls dies nicht geschieht, könnte dies zu einem Ressourcenverlust führen.

In solchen Szenarien treten ebenfalls Sicherheitsrisiken oder Zuverlässigkeitsprobleme auf, wenn Multithreaded-Zugriff auf IntPtr zulässig ist und zum Freigeben der durch IntPtr dargestellten Ressource verwendet wird. Zu diesen Problemen gehört das Recycling des IntPtr-Werts bei der Ressourcenfreigabe während der gleichzeitigen Verwendung der Ressource auf einem anderen Thread. Dies führt zu Racebedingungen, wobei ein Thread Daten, die mit der falschen Ressource verknüpft sind, lesen oder schreiben kann. Wenn der Typ beispielsweise ein Betriebssystemhandle als IntPtr speichert und zulässt, dass Benutzer sowohl die Close-Methode als auch eine beliebige andere Methode aufrufen und dieses Handle (ohne Synchronisierung) gleichzeitig verwenden, hat der Code ein Problem beim Recyceln von Handles.

Dies führt zu Datenbeschädigung und häufig zu einem Sicherheitsrisiko. SafeHandle und CriticalHandle bieten einen Mechanismus zum Kapseln eines systemeigenen Handles in einer Ressource, sodass solche Threadingprobleme vermieden werden können. Zudem können Sie SafeHandle und CriticalHandle für andere Threadingprobleme verwenden, beispielsweise für die sorgfältige Kontrolle der Lebensdauer von verwalteten Objekten, die eine Kopie des systemeigenen Handles über Aufrufe an systemeigene Methoden enthalten, d. h., Sie können Aufrufe an GC.KeepAlive häufig entfernen. Es gibt implizite Leistungsverluste beim Verwenden von SafeHandle (und in geringerem Maße beim Verwenden von CriticalHandle), die oft durch einen sorgfältigen Entwurf gemildert werden können.

Behandlung von Verstößen

Konvertieren Sie IntPtr in SafeHandle, um den Zugriff auf systemeigene Ressourcen sicher zu verwalten.

Wann Warnungen unterdrückt werden sollten

Diese Warnung sollte nicht unterdrückt werden.