Sicherheitsaspekte bei der Reflektionsausgabe

  • Artikel

Aktualisiert: November 2007

.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.

Hinweis:

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. Welche Berechtigungen erforderlich sind, hängt von der verwendeten Überladung ab. Überladungen, die Beweise bereitstellen, erfordern z. B. SecurityPermission mit dem SecurityPermissionFlag.ControlEvidence-Flag. Einige Überladungen erfordern keine Berechtigungen und können über Code aufgerufen werden, der nur über Internetberechtigungen verfügt.

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

Hinweis:

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

Die Generierung von Code mit Debugsymbolen erfordert ReflectionPermission mit dem ReflectionPermissionFlag.ReflectionEmit-Flag.

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 DefineDynamicAssembly-Methodenüberladung, die zum Erstellen der dynamischen Assemblys verwendet wird, erfordert keine speziellen Berechtigungen (d. h. es werden keine Beweise bereitgestellt usw.).

  • Die Assembly wird nicht auf der Festplatte gespeichert.

  • Es werden keine Debugsymbole generiert. (Der Internet-Berechtigungssatz und der LocalIntranet-Berechtigungssatz schließen das ReflectionPermissionFlag.ReflectionEmit-Flag nicht ein.)

Festlegen von Berechtigungen für dynamische Assemblys

In der folgenden Liste ist "Emitter" die Assembly, die die dynamische Assembly generiert.

  • Ein Emitter, der SecurityPermission mit dem SecurityPermissionFlag.ControlEvidence-Flag enthält, kann Beweise für den generierten Code bereitstellen. Diese Beweise werden über eine Richtlinie zugeordnet, um die gewährten Berechtigungen festzulegen.

  • Ein Emitter kann auch den NULL-Beweis zur Verfügung stellen. In diesem Fall erhält die Assembly den Berechtigungssatz des Emitters. Dadurch wird sichergestellt, dass der generierte Code nicht über mehr Berechtigungen verfügt als sein Emitter.

  • Wenn Sie Berechtigungssätze mit SecurityAction.RequestMinimum, SecurityAction.RequestOptional oder SecurityAction.RequestRefuse angeben, werden diese Berechtigungssätze erst verwendet, wenn die Assembly auf der Festplatte gespeichert wurde und anschließend von der Festplatte geladen wird.

  • Wenn eine dynamische Assembly auf der Festplatte gespeichert wurde, wird sie wie jede andere Assembly behandelt, die von der Festplatte geladen wird.

  • Code, der von nur teilweise vertrauenswürdigen Emittern generiert wird, wird immer überprüft. Insbesondere wird zur Laufzeit immer Code überprüft, der nicht über SecurityPermission mit dem SecurityPermissionFlag.SkipVerification-Flag verfügt. Vollständig vertrauenswürdige Emitter können die Überprüfung überspringen oder die Überprüfung des generierten Codes anfordern.

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, array<Type[]) und DynamicMethod(String, Type, array<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.

Hinweis:

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.

Anonym gehostete dynamische Methoden können 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 Fähigkeit zum Überspringen von JIT-Sichtbarkeitsprüfungen erfordert ReflectionPermission mit dem ReflectionPermissionFlag.RestrictedMemberAccess-Flag.

  • 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.

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 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.

Hinweis:

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

Hinweis:

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.

Hinweis:

Dynamische Methoden unterstützen keine Debugsymbole.

Versionsinformationen

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.

Hinweis:

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.

Um diese Features zu verwenden, sollte die Anwendung für .NET Framework Version 3.5 ausgelegt sein. Weitere Informationen finden Sie unter Architektur von .NET Framework 3.5.

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