Freigeben über

Best Practices für partielle Vertrauenswürdigkeit

  • Artikel

In diesem Artikel werden Best Practices bei der Ausführung von Windows Communication Foundation (WCF) in einer teilweise vertrauenswürdigen Umgebung beschrieben.

Serialisierung

Verwenden Sie diese Best Practices, wenn Sie DataContractSerializer in einer teilweise vertrauenswürdigen Anwendung verwenden.

Alle serialisierbaren Typen müssen explizit mit dem [DataContract]-Attribut gekennzeichnet werden. Die folgenden Techniken werden in einer teilweise vertrauenswürdigen Umgebung nicht unterstützt:

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

Verwenden von DataContractSerializer

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

  • Alle [DataContract]-Member in einem serialisierbaren [DataContract]-Typ müssen öffentlich sein. Ein Typ mit einem nicht öffentlichen Datenmember ([DataMember]) kann in einer teilweise vertrauenswürdigen Umgebung nicht serialisiert werden.

  • Methoden, die Serialisierungsereignisse verarbeiten (z. B. OnSerializing, OnSerialized, OnDeserializing und OnDeserialized), müssen als öffentlich deklariert werden. Jedoch werden sowohl explizite als auch implizite Implementierungen von OnDeserialization(Object) unterstützt.

  • [DataContract]-Typen, die in Assemblys implementiert und mit AllowPartiallyTrustedCallersAttribute gekennzeichnet sind, dürfen keine sicherheitsbezogenen Aktionen im Typkonstruktor ausführen, da DataContractSerializer den Konstruktor des neu instanziierten Objekts während der Deserialisierung nicht aufruft. Die folgenden allgemeinen Sicherheitstechniken müssen 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

  • Da das Objekt erfolgreich instanziiert wurde, wird davon ausgegangen, dass eventuelle vom Konstruktor erzwungene Validierungsprüfungen erfolgreich bestanden wurden.

Verwenden von IXmlSerializable

Die folgenden empfohlenen Vorgehensweisen gelten für Typen, die IXmlSerializable implementieren und mit DataContractSerializer serialisiert werden:

  • Die statischen GetSchema-Methodenimplementierungen müssen public sein.

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

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 ferner davon aus, dass nur ein einzelner Anwendungssicherheitskontext für jede App-Domäne (AppDomain) vorhanden ist und dass dieser Kontext zum Zeitpunkt der AppDomain-Erstellung durch einen vertrauenswürdigen Host eingerichtet wird (beispielsweise durch einen Aufruf von CreateDomain oder durch den ASP.NET-Anwendungs-Manager).

Hinweis

Die Codezugriffssicherheit (CAS, Code Access Security) 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*innen sollten alternative Mittel zum Ausführen von Sicherheitsaufgaben suchen.

Dieses Sicherheitsmodell gilt für Anwendungen, die von Benutzer*innen erstellt wurden und keine zusätzlichen CAS-Berechtigungen gewähren können – beispielsweise ein Benutzercode, der in einer ASP.NET-Anwendung mittlerer Vertrauenswürdigkeit ausgeführt wird. Bei vollständig vertrauenswürdigem Plattformcode (beispielsweise eine von Dritten erstellte Assembly, die im globalen Assemblycache installiert wird und Aufrufe von teilweise vertrauenswürdigem Code akzeptiert) ist jedoch eine vorsichtige Vorgehensweise erforderlich, wenn WCF im Auftrag einer teilweise vertrauenswürdigen Anwendung aufgerufen wird, um das Entstehen von Sicherheitsrisiken auf Anwendungsebene zu vermeiden.

Vollständig vertrauenswürdiger Code sollte es vermeiden, den CAS-Berechtigungssatz des aktuellen Threads zu verändern (durch Aufrufen von Assert, PermitOnly oder Deny), bevor er WCF-APIs für teilweise vertrauenswürdigen Code aufruft. Das Gewähren, Abweisen oder anderweitige Erstellen von threadspezifischem Berechtigungskontext, der unabhängig vom Sicherheitskontext der Anwendungsebene ist, kann zu unerwartetem Verhalten führen. Je nach Anwendung kann dieses Verhalten zu Sicherheitslücken auf Anwendungsebene führen.

Code, der WCF unter Verwendung eines threadspezifischen Berechtigungskontexts aufruft, muss auf die Behandlung der folgenden möglichen Situationen vorbereitet werden:

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

  • Interner WCF-Code sowie von Benutzer*innen bereitgestellte Rückrufe werden möglicherweise in einem anderen Sicherheitskontext ausgeführt als dem, in dem der Aufruf ursprünglich initiiert wurde. Zu diesen Kontexten gehören:

    • Der Berechtigungskontext der Anwendung

    • 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 stellt sicher, dass teilweise vertrauenswürdiger Code voll vertrauenswürdige Berechtigungen nur dann erhalten kann, wenn die Berechtigungen vor dem Aufrufen der öffentlichen WCF-APIs von einer voll vertrauenswürdigen Komponente gewährt werden. Jedoch wird dabei nicht garantiert, dass die Gewährung voller Vertrauenswürdigkeit auf einen bestimmten Thread, Vorgang oder eine bestimmte Benutzeraktion beschränkt ist.

Es empfiehlt sich daher, die Erstellung von threadspezifischem Berechtigungskontext durch Aufrufen von Assert, PermitOnly oder Deny zu vermeiden. Gewähren oder verweigern Sie stattdessen der Anwendung selbst die Berechtigung, damit Assert, Deny oder PermitOnly nicht erforderlich ist.

Siehe auch