Sicherheitsüberlegungen für die Reflektion

Artikel
08/10/2011

Die Reflektion bietet die Möglichkeit, Typ- und Memberinformationen abzurufen und auf Member zuzugreifen (d. h. Aufrufen von Methoden und Konstruktoren, Abrufen und Festlegen von Eigenschaftswerten, Hinzufügen und Entfernen von Ereignishandlern usw.). Die Verwendung der Reflektion, um Typ- und Memberinformationen abzurufen, ist nicht eingeschränkt. Sämtlicher Code kann mithilfe der Reflektion die folgenden Aufgaben ausführen:

Auflisten von Typen und Membern und Prüfen ihrer Metadaten
Auflisten und Prüfen von Assemblys und Modulen

Das Verwenden der Reflektion, um auf Member zuzugreifen, ist dagegen Einschränkungen unterworfen. Ab .NET Framework, Version 4 kann nur vertrauenswürdiger Code mithilfe der Reflektion auf sicherheitskritische Member zugreifen. Weiterhin kann nur vertrauenswürdiger Code mithilfe der Reflektion auf nicht öffentliche Member zugreifen, die in kompiliertem Code nicht direkt zugänglich sind. Code, der Reflektion für den Zugriff auf ein sicherheitskritisches Member verwendet, muss wie kompilierter Code über genau die Berechtigungen verfügen, die vom sicherheitskritischen Member verlangt werden.

Sofern die notwendigen Berechtigungen vorliegen, kann der Code mithilfe der Reflektion die folgenden Zugriffsarten ausführen:

Zugreifen auf öffentliche Member, die nicht sicherheitskritisch sind.
Zugreifen auf nicht öffentliche Member, auf die kompilierter Code zugreifen kann, wenn diese Member nicht sicherheitskritisch sind. Beispiele für solche nicht öffentliche Member:
- Geschützte Member der Basisklassen des aufrufenden Codes. (In Reflektion wird dies als Zugriff auf Familienebene bezeichnet.)
- internal-Member (Friend-Member in Visual Basic) in der Assembly des aufrufenden Codes. (In Reflektion wird dies als Zugriff auf Assemblyebene bezeichnet.)
- Private Member von anderen Instanzen der Klasse, die den aufrufenden Code enthält.

Zum Beispiel ist Code, der in einer Sandkastenanwendungsdomäne ausgeführt wird, auf den in dieser Liste beschriebenen Zugriff beschränkt, außer wenn die Anwendungsdomäne zusätzliche Berechtigungen gewährt.

Ab .NET Framework Version 2.0 Service Pack 1 wird beim Versuch, auf Member zuzugreifen, auf die normalerweise nicht zugegriffen werden kann, mit dem ReflectionPermissionFlag.MemberAccess-Flag eine Forderung nach dem Berechtigungssatz des Zielobjekts plus ReflectionPermission generiert. Code, der mit voller Vertrauenswürdigkeit ausgeführt wird (z. B. Code in einer Anwendung, die über die Befehlszeile gestartet wird), kann diese Berechtigungen immer erfüllen. (Dies unterliegt den Einschränkungen beim Zugriff auf sicherheitskritische Member, so wie weiter unten in diesem Artikel beschrieben.)

Optional kann eine Sandkastenanwendungsdomäne ReflectionPermission mit dem ReflectionPermissionFlag.MemberAccess-Flag gewähren, wie im Abschnitt Zugreifen auf Member, auf die normalerweise nicht zugegriffen werden kann weiter unten in diesem Artikel beschrieben.

Zugreifen auf sicherheitskritische Member

Ein Member ist sicherheitskritisch, wenn er das SecurityCriticalAttribute besitzt, wenn er zu einem Typ gehört, der das SecurityCriticalAttribute besitzt, oder wenn er sich in einer sicherheitskritischen Assembly befindet. Ab .NET Framework, Version 4 gelten folgende Regeln für den Zugriff auf sicherheitskritische Member:

Transparenter Code kann nicht mithilfe der Reflektion auf sicherheitskritische Member zugreifen, auch wenn der Code voll vertrauenswürdig ist. Eine MethodAccessException, FieldAccessException oder TypeAccessException wird ausgelöst.
Code, der mit teilweiser Vertrauenswürdigkeit ausgeführt wird, wird als transparent behandelt.

Diese Regeln gelten immer, ganz gleich, ob auf einen sicherheitskritischen Member direkt von kompiliertem Code oder mithilfe der Reflektion zugegriffen wird.

Anwendungscode, der über die Befehlszeile ausgeführt wird, wird mit voller Vertrauenswürdigkeit ausgeführt. Sofern der Code nicht als transparent gekennzeichnet ist, kann er mithilfe der Reflektion auf sicherheitskritische Member zugreifen. Wenn der gleiche Code mit teilweiser Vertrauenswürdigkeit ausgeführt wird (z. B. in einer Sandkastenanwendungsdomäne), bestimmt die Vertrauensebene der Assembly, ob auf sicherheitskritischen Code zugegriffen werden kann: Wenn die Assembly über einen starken Namen verfügt und im globalen Assemblycache installiert ist, handelt es sich um eine vertrauenswürdige Assembly, die sicherheitskritische Member aufrufen kann. Wenn die Assembly nicht vertrauenswürdig ist, wird sie transparent, obwohl sie nicht als transparent gekennzeichnet wurde, und kann nicht auf sicherheitskritische Member zugreifen.

Weitere Informationen zum Sicherheitsmodell in .NET Framework 4 finden Sie unter Änderungen der Sicherheit in .NET Framework 4.

Reflektion und Transparenz

Ab .NET Framework 4 bestimmt die Common Language Runtime (CLR) die Transparenzebene eines Typs oder Members anhand mehrerer Faktoren, einschließlich der Vertrauensebene der Assembly und der Vertrauensebene der Anwendungsdomäne. Die Reflektion stellt die Eigenschaften IsSecurityCritical, IsSecuritySafeCritical und IsSecurityTransparent bereit, um die Transparenzebene eines Typs zu ermitteln. In der folgenden Tabelle finden Sie eine Übersicht über die gültigen Kombinationen dieser Eigenschaften:

Sicherheitsebene	IsSecurityCritical	IsSecuritySafeCritical	IsSecurityTransparent
Kritisch	true	false	false
Sicherheitskritisch	true	true	false
Transparent	false	false	true

Die Verwendung dieser Eigenschaften ist deutlich einfacher als das Untersuchen der Sicherheitsanmerkungen einer Assembly und der zugehörigen Typen, das Überprüfen der aktuellen Vertrauensebene sowie das Duplizieren von Laufzeitregeln. Der gleiche Typ kann z. B. sicherheitskritisch sein, wenn er über die Befehlszeile ausgeführt wird, oder sicherheitstransparent, wenn er in einer Sandkastenanwendungsdomäne ausgeführt wird.

Die Klassen MethodBase, FieldInfo, TypeBuilder, MethodBuilder und DynamicMethod weisen ähnliche Eigenschaften auf. (Bei anderen Reflektionen und Reflektionsausgaben werden Sicherheitsattribute auf die zugeordneten Methoden angewendet; bei Eigenschaften werden sie z. B. auf Eigenschaftenaccessoren angewendet.)

Zugreifen auf Member, auf die normalerweise nicht zugegriffen werden kann

Um mit Reflektion Methoden aufzurufen, die nach den Zugriffsregeln der Common Language Runtime nicht zugänglich sind, muss Ihrem Code eine von zwei Berechtigungen gewährt werden:

Damit Code einen beliebigen nicht öffentlichen Member aufrufen kann: Dem Code muss ReflectionPermission mit dem ReflectionPermissionFlag.MemberAccess-Flag gewährt werden.

Hinweis
Standardmäßig verweigert die Sicherheitsrichtlinie diese Berechtigung für Code, der über das Internet bereitgestellt wurde.Code, der aus dem Internet stammt, sollte diese Berechtigung nie gewährt werden.

Damit Code einen beliebigen nicht öffentlichen Member aufrufen kann, wenn der Berechtigungssatz der Assembly, die den aufgerufenen Member enthält, mit dem Berechtigungssatz des aufrufenden Codes identisch ist oder eine Untermenge dieses Berechtigungssatzes darstellt: Dem Code muss ReflectionPermission mit dem ReflectionPermissionFlag.RestrictedMemberAccess-Flag gewährt werden.

Beispiel: Angenommen, Sie gewähren einer Anwendungsdomäne Internetberechtigungen plus ReflectionPermission mit dem ReflectionPermissionFlag.RestrictedMemberAccess-Flag und führen anschließend eine Internetanwendung mit den beiden Assemblys A und B aus.

Assembly A kann Reflektion verwenden, um auf private Member von Assembly B zuzugreifen, da der Berechtigungssatz von Assembly B keine Berechtigungen enthält, die A nicht gewährt wurden.
Assembly A kann Reflektion nicht verwenden, um auf private Member von .NET Framework-Assemblys wie "mscorlib.dll" zuzugreifen, da "mscorlib.dll" voll vertrauenswürdig ist und daher Berechtigungen besitzt, die Assembly A nicht gewährt wurden. Eine MemberAccessException wird ausgelöst, wenn Codezugriffssicherheit zur Laufzeit den Stapel durchläuft.

Serialisierung

Zum Serialisieren stellt SecurityPermission mit dem SecurityPermissionAttribute.SerializationFormatter-Flag die Möglichkeit bereit, Member von serialisierbaren Typen unabhängig vom Zugriff abzurufen und festzulegen. Mit dieser Berechtigung kann Code den privaten Status einer Instanz erkennen und ändern. (Der Typ muss nicht nur über die entsprechenden Berechtigungen verfügen, sondern auch in den Metadaten als serialisierbar markiert sein.)

Parameter des MethodInfo-Typs

Vermeiden Sie es, öffentliche Member zu schreiben, die MethodInfo-Parameter erhalten, besonders bei vertrauenswürdigem Code. Diese Member könnten anfälliger für böswilligen Code sein. Beispiel: Ein öffentlicher Member in vertrauenswürdigem Code erhält einen MethodInfo-Parameter. Angenommen, der öffentliche Member ruft die Invoke-Methode für den bereitgestellten Parameter auf. Ohne Überprüfen der Berechtigung durch den öffentlichen Member wäre der Aufruf der Invoke-Methode in jedem Fall erfolgreich, da das Sicherheitssystem feststellen würde, dass der Aufrufer hoch vertrauenswürdig ist. Auch wenn böswilliger Code nicht zum direkten Aufruf der Methode berechtigt ist, ist dies trotzdem indirekt über einen Aufruf des öffentlichen Members möglich.

Versionsinformationen

Ab .NET Framework, Version 4 kann transparenter Code nicht mithilfe der Reflektion auf sicherheitskritische Member zugreifen.
Das ReflectionPermissionFlag.RestrictedMemberAccess-Flag wird in .NET Framework Version 2.0 Service Pack 1 eingeführt. Frühere Versionen von .NET Framework erfordern das ReflectionPermissionFlag.MemberAccess-Flag für Code, der Reflektion verwendet, um auf nicht öffentliche Member zuzugreifen. Diese Berechtigung sollte in keinem Fall teilweise vertrauenswürdigem Code erteilt werden.
Ab .NET Framework 2.0 erfordert die Verwendung von Reflektion, um Informationen über nicht öffentliche Typen und Member abzurufen, keinerlei Berechtigungen. In früheren Versionen ist ReflectionPermission mit dem ReflectionPermissionFlag.TypeInformation-Flag erforderlich.