Freigeben über

Bewährte Praktiken für teilweises Vertrauen

In diesem Artikel werden bewährte Methoden beim Ausführen von Windows Communication Foundation (WCF) in einer teilweise vertrauenswürdigen Umgebung beschrieben.

Serialisierung

Wenden Sie diese Methoden bei Verwendung der DataContractSerializer in einer teilweise vertrauenswürdigen Anwendung an.

Alle serialisierbaren Typen müssen explizit mit dem [DataContract] Attribut gekennzeichnet werden. Die folgenden Techniken werden in einer teilweisen Vertrauensumgebung nicht unterstützt:

  • Das Markieren von Klassen, die serialisiert werden sollen, mit SerializableAttribute
  • Implementieren der ISerializable Schnittstelle, damit eine Klasse ihren Serialisierungsprozess steuern kann.

Verwenden von DataContractSerializer

  • Alle typen, die mit dem [DataContract] Attribut gekennzeichnet sind, müssen öffentlich sein. Nicht öffentliche Typen können in einer teilweise vertrauenswürdigen Umgebung nicht serialisiert werden.

  • Alle [DataContract] Elemente in einem serialisierbaren [DataContract] Typ müssen öffentlich sein. Ein Typ mit einem nicht öffentlichen [DataMember] kann in einer Umgebung mit eingeschränktem Vertrauen nicht serialisiert werden.

  • Methoden, die Serialisierungsereignisse behandeln (wie OnSerializing, OnSerialized, OnDeserializing und OnDeserialized), müssen öffentlich deklariert werden. Sowohl explizite als auch implizite Implementierungen von OnDeserialization(Object) werden unterstützt.

  • [DataContract] Typen, die in Assemblys implementiert sind und mit dem AllowPartiallyTrustedCallersAttribute gekennzeichnet sind, sollten keine sicherheitsrelevanten Aktionen im Typenkonstruktor durchführen, da der DataContractSerializer Konstruktor des neu instanziierten Objekts während der Deserialisierung nicht aufgerufen wird. Insbesondere müssen die folgenden allgemeinen Sicherheitstechniken für [DataContract] Typen vermieden werden:

  • Der Versuch, den teilweise vertrauenswürdigen Zugriff durch Definieren des Konstruktors für den Typ als intern oder privat zu beschränken

  • Einschränken des Zugriffs auf den Typ durch Hinzufügen von [LinkDemand] zum Konstruktor des Typs

  • Angenommen, da das Objekt erfolgreich instanziiert wurde, wurden alle vom Konstruktor erzwungenen Überprüfungen erfolgreich bestanden.

Verwenden von IXmlSerializable

Die folgenden bewährten Methoden gelten für Typen, die IXmlSerializable implementieren und mit DataContractSerializer serialisiert werden.

  • Die GetSchema Implementierungen statischer Methoden müssen sein public.

  • Die Instanzmethoden, die die IXmlSerializable Schnittstelle implementieren, müssen sein public.

Verwenden von WCF aus vollständig vertrauenswürdigem Plattformcode, der Aufrufe teilweise vertrauenswürdiger Aufrufer zulässt

Beim WCF-Sicherheitsmodell für partielle Vertrauenswürdigkeit wird davon ausgegangen, dass jeder Aufrufer einer öffentlichen WCF-Methode oder -Eigenschaft im CAS-Kontext (Code Access Security, Codezugriffssicherheit) der Hostanwendung ausgeführt wird. WCF geht auch davon aus, dass für jeden AppDomain nur ein Anwendungssicherheitskontext vorhanden ist und dass dieser Kontext zum Zeitpunkt der AppDomain-Erstellung durch einen vertrauenswürdigen Host eingerichtet wird (z. B. durch den ASP.NET Anwendungs-Manager oder durch einen Aufruf CreateDomain).

Hinweis

Code Access Security (CAS) ist in allen Versionen von .NET Framework und .NET veraltet. Aktuelle Versionen von .NET berücksichtigen keine CAS-Anmerkungen und erzeugen Fehler, wenn CAS-bezogene APIs verwendet werden. Entwickler sollten alternative Mittel zum Ausführen von Sicherheitsaufgaben suchen.

Dieses Sicherheitsmodell gilt für vom Benutzer geschriebene Anwendungen, die keine zusätzlichen CAS-Berechtigungen geltend machen können, z. B. Benutzercode, der in einer mittleren Vertrauensstellung in einer ASP.NET-Anwendung ausgeführt wird. Voll vertrauenswürdiger Plattformcode (z. B. eine Drittanbieterassembly, die im globalen Assemblycache installiert ist und Aufrufe von teilweise vertrauenswürdigem Code akzeptiert) muss jedoch explizit darauf achten, wenn Aufrufe an WCF im Auftrag einer teilweise vertrauenswürdigen Anwendung erfolgen, um die Einführung von Sicherheitsrisiken auf Anwendungsebene zu vermeiden.

Vollständig vertrauenswürdiger Code sollte vermeiden, den CAS-Berechtigungssatz des aktuellen Threads (durch Aufrufen von Assert, PermitOnly oder Deny) vor dem Aufrufen von WCF-APIs im Auftrag von teilweise vertrauenswürdigem Code zu ändern. Das Bestätigen, Verweigern oder anderweitiges Erstellen eines threadspezifischen Berechtigungskontexts, der unabhängig vom Sicherheitskontext auf Anwendungsebene ist, kann zu unerwartetem Verhalten führen. Je nach Anwendung kann dieses Verhalten zu Sicherheitsrisiken auf Anwendungsebene führen.

Code, der mithilfe eines threadspezifischen Berechtigungskontexts in WCF aufruft, muss vorbereitet sein, um die folgenden Situationen zu behandeln, die auftreten können:

  • Der threadspezifische Sicherheitskontext kann für die Dauer des Vorgangs nicht aufrechterhalten werden, was zu potenziellen Sicherheitsausnahmen führt.

  • Interner WCF-Code und alle vom Benutzer bereitgestellten Rückrufe können in einem anderen Sicherheitskontext ausgeführt werden als der, unter dem der Aufruf ursprünglich initiiert wurde. Zu diesen Kontexten gehören:

    • Der Anwendungsberechtigungskontext.

    • Ein beliebiger threadspezifischer Berechtigungskontext, der zuvor von anderen Benutzerthreads verwendet wurde, um WCF während der Lebensdauer der aktuell ausführenden App-Domäne (AppDomain) aufzurufen

WCF garantiert, dass teilweise vertrauenswürdiger Code keine voll vertrauenswürdigen Berechtigungen erhalten kann, es sei denn, diese Berechtigungen werden von einer vollständig vertrauenswürdigen Komponente vor dem Aufrufen öffentlicher WCF-APIs bestätigt. Es wird jedoch nicht garantiert, dass die Auswirkungen der Bestätigung der vollständigen Vertrauenswürdigkeit auf einen bestimmten Thread, einen bestimmten Vorgang oder eine bestimmte Benutzeraktion isoliert sind.

Vermeiden Sie als Best Practice das Erstellen von threadspezifischem Berechtigungskontext durch Aufrufen von Assert, PermitOnly oder Deny. Erteilen oder verweigern Sie stattdessen die Berechtigung für die Anwendung selbst, sodass kein Assert, , Denyoder PermitOnly erforderlich ist.

Siehe auch

  • Last updated on