Freigeben über

Sicherheitsaspekte bei der Reflektionsausgabe

  • Artikel

.NET Framework bietet drei Möglichkeiten, um Microsoft Intermediate Language (MSIL) auszugeben, wobei jede Methode eigene Sicherheitsaspekte aufweist:

  • Dynamische Assemblys

  • Anonym gehostete dynamische Methoden

  • Dynamische Methoden, die vorhandenen Assemblys zugeordnet sind

Unabhängig von der Methode, mit der Sie dynamischen Code generieren, erfordert die Ausführung des generierten Codes alle Berechtigungen, die gemäß den vom generierten Code verwendeten Typen und Methoden erforderlich sind.

HinweisHinweis

Die Berechtigungen, die zum Reflektieren und Ausgeben von Code erforderlich sind, haben sich mit den Nachfolgeversionen von .NET Framework geändert.Siehe Versionsinformationen weiter unten in diesem Thema.

Dynamische Assemblys

Dynamische Assemblys werden mit Überladungen der AppDomain.DefineDynamicAssembly-Methode erstellt. Die meisten Überladungen dieser Methode sind aufgrund der Beseitigung der computerweiten Sicherheitsrichtlinie in .NET Framework, Version 4 veraltet. (Siehe Änderungen der Sicherheit in .NET Framework 4.) Die verbleibenden Überladungen können unabhängig von der Vertrauensebene von jedem Code ausgeführt werden. Diese Überladungen lassen sich in zwei Gruppen unterteilen: Überladungen, die eine Liste von Attributen angeben, die beim Erstellen der dynamischen Assembly auf diese angewendet werden, und Überladungen, bei denen dies nicht der Fall ist. Wenn Sie beim Erstellen der Assembly das Transparenzmodell nicht anhand des SecurityRulesAttribute-Attributs angeben, wird das Transparenzmodell von der ausgebenden Assembly geerbt.

HinweisHinweis

Attribute, die Sie nach der Erstellung mit der SetCustomAttribute-Methode auf die dynamische Assembly anwenden, werden erst wirksam, wenn die Assembly auf 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.

HinweisHinweis

Dynamische Assemblys verwenden die Flags ReflectionPermissionFlag.MemberAccess und ReflectionPermissionFlag.RestrictedMemberAccess, die dynamischen Methoden den Zugriff auf nicht öffentliche Typen und Member ermöglichen, nicht.

Flüchtige dynamische Assemblys werden im Arbeitsspeicher erstellt und niemals auf der Festplatte gespeichert und erfordern daher keine Dateizugriffsberechtigungen. Zum Speichern einer dynamischen Assembly auf der Festplatte ist FileIOPermission mit den entsprechenden 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 kann, und führen Sie deren Code aus:

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

  • Die von diesen Typen und Membern geforderten Berechtigungen sind im Berechtigungssatz der teilweise vertrauenswürdigen Assembly enthalten.

  • Die Assembly wird nicht auf der Festplatte gespeichert.

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

Anonym gehostete dynamische Methoden

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

Wenn eine anonym gehostete dynamische Methode erstellt wird, wird stattdessen die Aufrufliste aufgezeichnet. Wenn die Methode erstellt wird, werden Sicherheitsanforderungen entsprechend der aufgezeichneten Aufrufliste gestellt.

HinweisHinweis

Konzeptionell werden Anforderungen während der Erstellung der Methode gestellt.Das bedeutet, dass bei jeder Ausgabe einer MSIL-Anweisung eine Forderung gestellt werden könnte.In der aktuellen Implementierung werden alle Forderungen gestellt, wenn die DynamicMethod.CreateDelegate-Methode aufgerufen wird oder wenn der JIT (Just-in-Time)-Compiler aufgerufen wird, falls die Methode ohne Aufrufen von CreateDelegate aufgerufen wird.

Wenn die Anwendungsdomäne dies 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 mit dem Berechtigungssatz der ausgebenden Aufrufliste identisch sind oder Untermengen dieses Berechtigungssatzes darstellen. Diese eingeschränkte Möglichkeit, JIT-Sichtbarkeitsprüfungen zu überspringen, ist aktiviert, wenn die Anwendungsdomäne ReflectionPermission mit dem ReflectionPermissionFlag.RestrictedMemberAccess-Flag gewährt.

  • Wenn die 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 beim Erstellen der Methode gestellt wird, ReflectionPermission mit dem ReflectionPermissionFlag.RestrictedMemberAccess-Flag und den 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 erteilt wurde, seine Berechtigungen nicht durch die Ausführung nicht öffentlicher Member vertrauenswürdiger Assemblys ausweiten.

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

Die Systemassembly, die anonym gehostete dynamische Methoden hostet, verwendet das SecurityRuleSet.Level1-Transparenzmodell. Dies ist das Transparenzmodell, das vor .NET Framework 4 im .NET Framework verwendet wurde.

Weitere Informationen finden Sie im Abschnitt 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 kann, und führen Sie sie aus:

  • Die dynamische Methode verwendet nur öffentliche Typen und Member. Wenn der Berechtigungssatz ReflectionPermissionFlag.RestrictedMemberAccess enthält, kann die Methode nicht öffentliche Typen und Member einer beliebigen Assembly verwenden, deren Berechtigungssatz mit dem Berechtigungssatz der ausgebenden Assembly identisch ist oder eine Untermenge dieses Berechtigungssatzes ist.

  • Die Berechtigungen, die von allen Typen und Membern gefordert werden, die von der dynamischen Methode verwendet werden, sind im Berechtigungssatz der teilweise vertrauenswürdigen Assembly enthalten.

HinweisHinweis

Dynamische Methoden unterstützen keine Debugsymbole.

Dynamische Methoden, die vorhandenen Assemblys zugeordnet sind

Um eine dynamische Methode einem Typ oder Modul in einer vorhandenen Assembly zuzuordnen, verwenden Sie einen der DynamicMethod-Konstruktoren, die den zugeordneten Typ oder das zugeordnete Modul angeben. Die Berechtigungen, die zum Aufrufen dieser Konstruktoren erforderlich sind, variieren, da die dynamische Methode durch das Zuordnen zu einem vorhandenen Typ oder Modul Zugriff auf nicht öffentliche Typen und Member erhält:

  • 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) im Modul.

Darüber hinaus können Sie einen Konstruktor verwenden, der die Möglichkeit zum Überspringen der Sichtbarkeitsprüfungen des JIT-Compilers angibt. Dadurch hat Ihre dynamische Methode unabhängig von der Zugriffsstufe Zugriff auf alle Typen und Member in allen Assemblys.

Welche Berechtigungen der Konstruktor erfordert, hängt davon ab, wie viel Zugriff Sie der dynamischen Methode erteilen möchten:

Auch wenn die Elemente in dieser Liste im Hinblick auf den Berechtigungssatz der ausgebenden Assembly beschrieben werden, sollten Sie beachten, dass die Anforderungen für den vollständigen Aufrufstapel 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

HinweisHinweis

Die empfohlene Methode zum Generieren von dynamischen Methoden aus teilweise vertrauenswürdigem Code besteht in der Verwendung von anonym gehosteten dynamischen Methoden.

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

  • Entweder wird die dynamische Methode dem Modul oder Typ zugeordnet, das bzw. der sie ausgibt, oder ihr Berechtigungssatz enthält ReflectionPermissionFlag.RestrictedMemberAccess, und die Methode wird einem Modul in einer Assembly zugeordnet, deren Berechtigungssatz mit dem Berechtigungssatz der ausgebenden Assembly identisch ist oder eine Untermenge dieses Berechtigungssatzes darstellt.

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

  • Die Berechtigungen, die von allen von der dynamischen Methode verwendeten Typen und Membern gefordert werden, sind im Berechtigungssatz der teilweise vertrauenswürdigen Assembly enthalten.

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

HinweisHinweis

Dynamische Methoden unterstützen keine Debugsymbole.

Versionsinformationen

Die computerweite Sicherheitsrichtlinie wurde beginnend mit .NET Framework 4 entfernt. Die Sicherheitstransparenz ist ab dieser Version der standardmäßige Erzwingungsmechanismus. Weitere Informationen finden Sie unter Änderungen der Sicherheit in .NET Framework 4.

Ab .NET Framework Version 2.0 Service Pack 1 ist ReflectionPermission mit dem ReflectionPermissionFlag.ReflectionEmit-Flag beim Ausgeben von dynamischen Assemblys und dynamischen Methoden nicht mehr erforderlich. Dieses Flag ist in allen früheren Versionen von .NET Framework erforderlich.

HinweisHinweis

ReflectionPermission mit dem ReflectionPermissionFlag.ReflectionEmit-Flag ist standardmäßig in den benannten Berechtigungssätzen FullTrust und LocalIntranet enthalten, jedoch nicht im Internet-Berechtigungssatz.Daher kann eine Bibliothek in früheren Versionen von .NET Framework nur mit Internetberechtigungen verwendet werden, wenn sie einen Assert für ReflectionEmit ausführt.Diese Bibliotheken erfordern eine sorgfältige Sicherheitsüberprüfung, da Codierungsfehler zu Sicherheitslücken führen können.In .NET Framework 2.0 SP1 ist es möglich, Code in teilweise vertrauenswürdigen Szenarios ohne Sicherheitsanforderungen auszugeben, da das Generieren von Code an sich keinen privilegierten Vorgang darstellt.Das bedeutet, dass der generierte Code nicht mehr Berechtigungen aufweist als die Assembly, die ihn ausgibt.Bibliotheken, die Code ausgeben, können somit sicherheitstransparent sein und setzen keine ReflectionEmit-Assertion voraus, sodass die Aufgabe zum Schreiben einer sicheren Bibliothek vereinfacht wird.

Darüber hinaus führt .NET Framework 2.0 SP1 das ReflectionPermissionFlag.RestrictedMemberAccess-Flag für den Zugriff auf nicht öffentliche Typen und Member aus teilweise vertrauenswürdigen dynamischen Methoden ein. 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 teilweise vertrauenswürdigem Code in keinem Fall erteilt werden.

Schließlich führt .NET Framework 2.0 SP1 anonym gehostete Methoden ein.

Abrufen von Informationen über Typen und Member

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

Siehe auch

Konzepte

Sicherheitsüberlegungen für die Reflektion

Weitere Ressourcen

Ausgeben von dynamischen Methoden und Assemblys