Sicherheitsaspekte bei der Reflektionsausgabe

  • Artikel

.NET Framework bietet drei Möglichkeiten, CIL (Common Intermediate Language) auszugeben, die jeweils mit eigenen Sicherheitsproblemen verbunden sind:

Unabhängig davon, wie Sie dynamischen Code generieren, erfordert die Ausführung des generierten Codes alle Berechtigungen, die für die Typen und Methoden erforderlich sind, die von dem generierten Code verwendet werden.

Hinweis

Die Berechtigungen, die für das Reflektieren und Ausgeben von Code erforderlich sind, haben sich mit den Nachfolgeversionen des .NET Framework geändert. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Versionsinformationen.

Dynamische Assemblys

Dynamische Assemblys werden unter Verwendung von Überladungen der AppDomain.DefineDynamicAssembly-Methode erstellt. Die meisten Überladungen dieser Methode werden in .NET Framework 4 als veraltet markiert, weil computerweite Sicherheitsrichtlinien beseitigt wurden. Die verbleibenden Überladungen können von jedem Code, unabhängig von der Vertrauensebene, ausgeführt werden. Diese Überladungen fallen in zwei Gruppen: solche, die eine Liste mit Attributen angeben, die auf die dynamische Assembly angewendet werden sollen, wenn sie erstellt wird, und solche, die dies unterlassen. Wenn Sie das Transparenzmodell für die Assembly beim Erstellen nicht durch Anwendung des SecurityRulesAttribute-Attributs angeben, wird das Transparenzmodell von der ausgebenden Assembly geerbt.

Hinweis

Attribute, die Sie mithilfe von SetCustomAttribute auf die dynamische Assembly nach deren Erstellung anwenden, werden erst wirksam, nachdem die Assembly auf dem Datenträger gespeichert und wieder in den Arbeitsspeicher geladen wurde.

Code in einer dynamischen Assembly kann auf sichtbare Typen und Member in anderen Assemblys zugreifen.

Hinweis

Dynamische Assemblys verwenden nicht die Flags ReflectionPermissionFlag.MemberAccess und ReflectionPermissionFlag.RestrictedMemberAccess, die es dynamischen Methoden gestatten, auf nicht öffentliche Typen und Member zuzugreifen.

Flüchtige dynamische Assemblys werden im Arbeitsspeicher erstellt und nie auf dem Datenträger gespeichert, weshalb sie keine Berechtigungen für den Dateizugriff benötigen. Für das Speichern einer dynamischen Assembly auf dem Datenträger ist FileIOPermission mit den geeigneten Flags erforderlich.

Generieren von dynamischen Assemblys aus teilweise vertrauenswürdigem Code

Beachten Sie die Bedingungen, unter denen eine Assembly mit Internetberechtigungen eine flüchtige dynamische Assembly generieren und deren Code ausführen kann:

  • Die dynamische Assembly verwendet nur öffentliche Typen und Member aus anderen Assemblys.

  • Die für diese Typen und Member erforderlichen Berechtigungen sind im Berechtigungssatz der teilweise vertrauenswürdigen Assembly enthalten.

  • Die Assembly wird nicht auf den Datenträger gespeichert.

  • Es werden keine Debugsymbole generiert. (Internet- und LocalIntranet-Berechtigungssätze enthalten nicht die notwendigen Berechtigungen.)

Anonym gehostete dynamische Methoden

Anonym gehostete dynamische Methoden werden mithilfe der zwei DynamicMethod-Konstruktoren erstellt, die kein zugeordnetes Modul und keinen zugeordneten Typ angeben, DynamicMethod(String, Type, Type[]) und DynamicMethod(String, Type, Type[], Boolean). Diese Konstruktoren fügen die dynamischen Methoden in eine vom System bereitgestellte, vollständig vertrauenswürdige, sicherheitstransparente Assembly ein. Es sind keine Berechtigungen erforderlich, um diese Konstruktoren zu verwenden oder Code für die dynamischen Methoden auszugeben.

Stattdessen wird, wenn eine anonym gehostete dynamische Methode erstellt wird, wird die Aufrufliste erfasst. Wenn die Methode erstellt wird, werden anhand der erfassten Aufrufliste Sicherheitsanforderungen aufgestellt.

Hinweis

Konzeptionell werden Anforderungen während der Erstellung der Methode gestellt. Das heißt, dass bei jeder Ausgabe einer CIL-Anweisung Anforderungen gestellt werden könnten. In der aktuellen Implementierung werden alle Forderungen gestellt, wenn die DynamicMethod.CreateDelegate-Methode aufgerufen wird oder wenn der JIT-Compiler (Just-in-Time) aufgerufen wird, falls die Methode ohne Aufruf von CreateDelegate aufgerufen wird.

Wenn die Anwendungsdomäne es zulässt, können anonym gehostete dynamische Methoden JIT-Sichtbarkeitsprüfungen gemäß der folgenden Einschränkung überspringen: Die nicht öffentlichen Typen und Member, auf die durch eine anonym gehostete dynamische Methode zugegriffen wird, müssen sich in Assemblys befinden, deren Berechtigungssätze entweder mit den Berechtigungssätzen der ausgebenden Aufrufliste übereinstimmen oder Teilmengen davon sind. Diese eingeschränkte Fähigkeit zum Überspringen von JIT-Sichtbarkeitsprüfungen wird aktiviert, wenn die Anwendungsdomäne mit dem ReflectionPermissionFlag.RestrictedMemberAccess-Flag ReflectionPermission erteilt.

  • Wenn Ihre Methode nur öffentliche Typen und Member verwendet, sind während der Erstellung keine Berechtigungen erforderlich.

  • Wenn Sie angeben, dass JIT-Sichtbarkeitsprüfungen übersprungen werden sollen, enthält die Anforderung, die gestellt wird, wenn die Methode erstellt wird, ReflectionPermission mit dem ReflectionPermissionFlag.RestrictedMemberAccess-Flag und dem Berechtigungssatz der Assembly, die den nicht öffentlichen Member enthält, auf den zugegriffen wird.

Da der Berechtigungssatz des nicht öffentlichen Members berücksichtigt wird, kann teilweise vertrauenswürdiger Code, dem ReflectionPermissionFlag.RestrictedMemberAccess gewährt wurde, seine Rechte nicht durch die Ausführung nicht öffentlicher Member vertrauenswürdiger Assemblys erhöhen.

Wie bei jedem anderen ausgegebenen Code auch, erfordert die Ausführung der dynamischen Methode alle Berechtigungen, die von den Methoden angefordert werden, die die dynamische Methode verwendet.

Die Systemassembly, die anonym gehostete dynamische Methoden hostet, verwendet das Transparenzmodell SecurityRuleSet.Level1. Hierbei handelt es sich um das Transparenzmodell, das vor .NET Framework 4 im .NET Framework verwendet wurde.

Weitere Informationen finden Sie in den Ausführungen zur DynamicMethod-Klasse.

Generieren von anonym gehosteten dynamischen Methoden aus teilweise vertrauenswürdigem Code

Beachten Sie die Bedingungen, unter denen eine Assembly mit Internetberechtigungen eine anonym gehostete dynamische Methode generieren und ausführen kann:

  • Die dynamische Methode verwendet nur öffentliche Typen und Member. Wenn ihr Berechtigungssatz ReflectionPermissionFlag.RestrictedMemberAccess enthält, kann sie nicht öffentliche Typen und Member jeder Assembly verwenden, deren Berechtigungssatz mit dem Berechtigungssatz der ausgebenden Assembly übereinstimmt oder eine Teilmenge davon darstellt.

  • Die für alle von der dynamischen Methode verwendeten Typen und Member erforderlichen Berechtigungen sind in dem Berechtigungssatz der teilweise vertrauenswürdigen Assembly enthalten.

Hinweis

Dynamische Methoden unterstützen keine Debugsymbole.

Vorhandenen Assemblys zugeordnete dynamische Methoden

Um eine dynamische Methode einem Typ oder Modul in einer vorhandenen Assembly zuzuordnen, verwenden Sie einen der DynamicMethod-Konstruktoren, die den zugeordneten Typ bzw. das zugeordnete Modul angeben. Die Berechtigungen, die erforderlich sind, um diese Konstruktoren aufzurufen, variieren, da das Zuordnen einer dynamischen Methode zu einem vorhandenen Typ oder Modul der dynamischen Methode den Zugriff auf nicht öffentliche Typen und Member gewährt:

  • Eine dynamische Methode, die einem Typ zugeordnet ist, hat Zugriff auf alle Member dieses Typs, einschließlich privater Member, sowie auf alle internen Typen und Member in der Assembly, die den zugeordneten Typ enthält.

  • Eine dynamische Methode, die einem Modul zugeordnet ist, hat Zugriff auf alle internal-Typen und -Member (Friend in Visual Basic, assembly in Common Language Runtime-Metadaten) in dem Modul.

Darüber hinaus können Sie einen Konstruktor verwenden, der die Fähigkeit zum Überspringen der Sichtbarkeitsprüfungen des JIT-Compilers angibt. Auf diese Weise erhält Ihre dynamische Methode Zugriff auf alle Typen und Member in allen Assemblys, unabhängig von der Zugriffsebene.

Die vom Konstruktor angeforderten Berechtigungen sind davon abhängig, in welchem Umfang Sie Ihrer dynamischen Methode Zugriff erteilen möchten:

Obgleich die Elemente in dieser Liste unter dem Aspekt des Berechtigungssatzes der ausgebenden Assembly beschrieben werden, sollten Sie daran denken, dass die Anforderungen an die gesamte Aufrufliste, einschließlich der Grenze der Anwendungsdomäne, gestellt werden.

Weitere Informationen finden Sie in den Ausführungen zur DynamicMethod-Klasse.

Generieren von dynamischen Methoden aus teilweise vertrauenswürdigem Code

Hinweis

Die empfohlene Vorgehensweise zum Generieren dynamischer Methoden aus teilweise vertrauenswürdigem Code besteht in der Verwendung anonym gehosteter dynamischer Methoden.

Beachten Sie die Bedingungen, unter denen eine Assembly mit Internetberechtigungen eine dynamische Methode generieren und ausführen kann:

  • Entweder ist die dynamische Methode dem Modul oder Typ zugeordnet, das/den sie ausgibt, oder ihr Berechtigungssatz enthält ReflectionPermissionFlag.RestrictedMemberAccess und dieser ist einem Modul in einer Assembly zugeordnet, deren Berechtigungssatz mit dem Berechtigungssatz der ausgebenden Assembly übereinstimmt oder eine Teilmenge davon darstellt.

  • Die dynamische Methode verwendet nur öffentliche Typen und Member. Wenn ihr Berechtigungssatz ReflectionPermissionFlag.RestrictedMemberAccess enthält und dieser einem Modul in einer Assembly zugeordnet ist, deren Berechtigungssatz mit dem Berechtigungssatz der ausgebenden Assembly übereinstimmt oder eine Teilmenge davon darstellt, kann sie Typen und Member verwenden, die in dem zugeordneten Modul als internal (Friend in Visual Basic, assembly in Common Language Runtime-Metadaten) markiert sind.

  • Die für alle von der dynamischen Methode verwendeten Typen und Member angeforderten Berechtigungen sind in dem Berechtigungssatz der teilweise vertrauenswürdigen Assembly enthalten.

  • Die dynamische Methode überspringt keine JIT-Sichtbarkeitsprüfungen.

Hinweis

Dynamische Methoden unterstützen keine Debugsymbole.

Versionsinformationen

Ab .NET Framework 4 wurde die computerweite Sicherheitsrichtlinie beseitigt, und Sicherheitstransparenz wurde zum Standarderzwingungsmechanismus.

Ab .NET Framework 2.0 Service Pack 1 ist ReflectionPermission mit dem ReflectionPermissionFlag.ReflectionEmit-Flag nicht mehr erforderlich, wenn dynamische Assemblys und dynamische Methoden ausgegeben werden. Dieses Flag ist in allen früheren Versionen des .NET Framework erforderlich.

Hinweis

ReflectionPermission mit dem ReflectionPermissionFlag.ReflectionEmit-Flag ist standardmäßig in den benannten Berechtigungsätzen FullTrust und LocalIntranet enthalten, aber nicht im Internet-Berechtigungssatz. Aus diesem Grund kann in früheren Versionen des .NET Framework eine Bibliothek mit Internetberechtigungen nur dann verwendet werden, wenn sie Assert für ReflectionEmit ausführt. Diese Bibliotheken erfordern einen sorgfältigen Sicherheitsreview, da Codierungsfehler zu Sicherheitslücken führen können. In .NET Framework 2.0 SP1 ist es zulässig, Code in teilweise vertrauenswürdigen Szenarios ohne Sicherheitsanforderungen auszugeben, da das Generieren von Code keinen inhärent privilegierten Vorgang darstellt. Das bedeutet, dass der generierte Code nicht mehr Berechtigungen aufweist als die Assembly, die ihn ausgibt. Dies ermöglicht es, dass Bibliotheken, die Code ausgeben, sicherheitstransparent sein können, und beseitigt die Notwendigkeit der Assertion von ReflectionEmit, was das Schreiben einer sicheren Bibliothek vereinfacht.

Darüber hinaus wurde in .NET Framework 2.0 SP1 das ReflectionPermissionFlag.RestrictedMemberAccess-Flag für den Zugriff auf nicht öffentliche Typen und Member über teilweise vertrauenswürdige dynamische Methoden eingeführt. Frühere Versionen von .NET Framework erfordern das ReflectionPermissionFlag.MemberAccess-Flag für dynamische Methoden, die auf nicht öffentliche Typen und Member zugreifen. Diese Berechtigung sollte niemals teilweise vertrauenswürdigem Code erteilt werden.

Zu guter Letzt wurden in .NET Framework 2.0 SP1 anonym gehostete Methoden eingeführt.

Abrufen von Informationen zu Typen und Member

Ab .NET Framework 2.0 sind keine Berechtigungen erforderlich, um Informationen über nicht öffentliche Typen und Member abzurufen. Reflektion wird verwendet, um Informationen abzurufen, die zum Ausgeben dynamischer Methoden erforderlich sind. Beispielsweise werden MethodInfo-Objekte verwendet, um Methodenaufrufe auszugeben. Frühere Versionen des .NET Framework erfordern ReflectionPermission mit dem ReflectionPermissionFlag.TypeInformation-Flag. Weitere Informationen finden Sie unter Sicherheitsüberlegungen für die Reflektion.

Siehe auch