Verwenden der Deny-Methode

Wichtig

In .NET Framework, Version 4 wurde die Laufzeitunterstützung für die Erzwingung von Anforderungen für die Berechtigungen Deny, RequestMinimum, RequestOptional und RequestRefuse entfernt.Diese Anforderungen sollten nicht in Code verwendet werden, der auf .NET Framework 4 oder höher basiert.Weitere Informationen über diese und andere Änderungen finden Sie unter Änderungen der Sicherheit in .NET Framework 4.

Das Aufrufen von Deny verhindert den Zugriff auf die Ressource, die von der verweigerten Berechtigung angegeben wird. Wenn der Code Deny aufruft und ein nachgeschalteter Aufrufer später die verweigerte Berechtigung fordert, schlägt die Sicherheitsüberprüfung fehl, selbst wenn der Aufrufer über die Berechtigung für den Zugriff auf die Ressource verfügt. Die geforderte und die verweigerte Berechtigung müssen nicht genau übereinstimmen, damit Deny wirksam wird, und die geforderte Berechtigung muss keine Teilmenge der verweigerten Berechtigung sein. Wenn die Schnittmenge der beiden Berechtigungen jedoch leer ist, diese also keine gemeinsamen Elemente haben, bleibt der Aufruf von Deny wirkungslos. Beachten Sie, dass Deny keinen tieferen Code in der Aufrufliste überschreiben kann, wenn dieser ein Assert ausführt. Wenn tieferer Code in der Aufrufliste Assert ausführt, kann der tiefere Code auf die Ressource zugreifen, die durch höheren Code in der Aufrufliste verweigert wird.

Sie können Deny im Code aufrufen lassen, um Haftungsfälle zu verhindern, da Deny dem Code den Zugriff auf die verweigerte Ressource verwehrt. Das Aufrufen von Deny verhindert jedoch keine zukünftigen Sicherheitsassertionen durch nachgeschaltete Aufrufer.

Die folgende Abbildung veranschaulicht die Vorgänge bei der Verwendung von Deny. Angenommen, die folgenden Aussagen gelten für die Assemblys A, B, C, D und E sowie für Berechtigung B1:

• B1 stellt das Recht zum Lesen aller Dateien auf Laufwerk C dar.

• Den Assemblys A, B, C, D und E wurde B1 erteilt.

• Methode F platziert eine Forderung für Berechtigung B1.

• Methode C erstellt eine Instanz der B1-Klasse und ruft anschließend die Deny-Methode von B1 auf.

• Methode A ist in Assembly A enthalten, Methode B ist in Assembly B enthalten usw.

Verwenden von "Deny"

Der Aufruf von Deny durch Methode C kann sich auf die Ergebnisse von Forderungen für B1 auswirken. Angenommen, Methode A ruft B auf, B ruft C auf, C ruft E auf, und E ruft F auf. Da Methode F direkt auf die Ressource zugreift, die P1 schützt, führt Methode F eine Sicherheitsüberprüfung für P1 durch, indem sie die Demand-Methode von P1 aufruft (oder eine deklarative Anforderung verwendet). Diese Forderung bewirkt, dass die Laufzeit die Berechtigungen aller Aufrufer in der Aufrufliste überprüft, beginnend mit Assembly E. Da Assembly E die Berechtigung P1 gewährt wurde, fährt die Laufzeit mit dem Überprüfen der Berechtigungen von Assembly C fort. Da Methode C aber P1 verweigert, schlägt die von Methode E aufgerufene Sicherheitsüberprüfung an diesem Punkt fehl, und eine SecurityException wird ausgelöst. Die Sicherheitsüberprüfung schlägt unabhängig davon fehl, ob Assembly C und ihren Aufrufern (Assemblys A und B) B1 erteilt wurde;. Da Methode C Deny aufgerufen hat, kann Code in den Assemblys A und B nicht auf die von B1 geschützte Ressource zugreifen.

Der folgende Code veranschaulicht die deklarative Syntax zum Überschreiben von Sicherheitsüberprüfungen mithilfe der Deny-Methode. In diesem Beispiel gibt die ReflectionPermission-Syntax zwei Werte an: Eine SecurityAction-Enumeration und die Einstellung für die TypeInformation-Eigenschaft. TypeInformation wird auf true festgelegt, um anzugeben, dass diese Berechtigung das Recht darstellt, private Member durch Reflektion anzuzeigen. SecurityAction.Deny wird übergeben, um diese Berechtigung zu verweigern. Eine vollständige Liste der Werte, die angegeben werden können, finden Sie in der Beschreibung von ReflectionPermission. Mit dieser Sicherheitsdeklaration kann die Methode keine privaten Member eines Typs durch Reflektion lesen.

Option Strict
Option Explicit
Imports System
Imports System.Security.Permissions
<ReflectionPermissionAttribute(SecurityAction.Deny, TypeInformation = true ")> Public Class 
MyClass1
   Public Sub New()
   End Sub
   Public Sub GetPublicMembers ()
      ' Access public members through reflection.
   End Sub
End Class

using System;
using System.Security.Permissions;

[ReflectionPermissionAttribute(SecurityAction.Deny, TypeInformation = true)]
public class MyClass
{
   public MyClass()
   {    
   }   

   public void GetPublicMembers()
   {
      //Access public members through reflection.
   }  
}

Der folgende Code veranschaulicht die imperative Syntax zum Überschreiben von Sicherheitsüberprüfungen mithilfe der Deny-Methode. In diesem Beispiel wird das ReflectionPermission-Objekt deklariert, und seinem Konstruktor wird ReflectionPermissionFlag.TypeInformation übergeben, um die aktuelle Berechtigung zu initialisieren. Wenn die Deny-Methode aufgerufen wird, können weder der Code noch die Aufrufer dazu verwendet werden, private Felder durch Reflektion zu lesen.

Option Explicit
Option Strict
Imports System
Imports System.Security.Permissions
Public Class MyClass1
   Public Sub New()
   End Sub
   Public Sub ReadRegistry()
      Dim MyPermission As New ReflectionPermission (ReflectionPermissionFlag.TypeInformation)
      MyPermission.Deny()
      ' Access public members through reflection.
   End Sub 
End Class

using System;
using System.Security.Permissions;

public class MyClass {
   public MyClass() {    
   }   

   public void ReadRegistry() { 
      ReflectionPermission MyPermission = new ReflectionPermission (ReflectionPermissionFlag.TypeInformation);
      MyPermission.Deny();

      // Access public members through reflection.
   }  
}

Kanonisierungsprobleme beim Verwenden von "Deny"

Beim Verweigern von FileIOPermission, RegistryPermission, WebPermission, UrlIdentityPermission, SiteIdentityPermission und EnvironmentPermission sollten Sie sehr vorsichtig vorgehen, da einzelne Dateien, Registrierungseinträge, URLs und Systempfade mithilfe mehrerer Namen beschrieben werden können. Beispielsweise gibt es mehrere Möglichkeiten, um auf eine einzelne Datei, MyFile.log, zu verweisen. Dazu zählen "c:\MyFile.log" und "\\MyMachineName\c$\MyFile.log". Wenn Sie eine Berechtigung erstellen, die den Zugriff auf "c:\MyFile.log" darstellt, und dem Code dann diese Berechtigung verweigern, kann der Code u. U. weiterhin über den alternativen Pfad "\\MyMachineName\c$\MyFile.log" auf die Datei zugreifen.

Mit einer Verbindung aus PermitOnly und Deny können Sie Kanonisierungsprobleme vermeiden. PermitOnly bietet die Möglichkeit, nur einen von mehreren möglichen Namen für eine Ressource festzulegen. Außerdem wird als Nebeneffekt der Zugriff auf diese Ressource unter Verwendung anderer Namen verweigert. Nachdem Sie mit PermitOnly den einzigen zulässigen Namen für eine Ressource angegeben haben, müssen Sie mit Deny den Zugriff auf die Ressource mit diesem Namen verweigern.

Im folgenden Code wird mit einer Kombination aus Deny und PermitOnly verhindert, dass der Code auf die Ressource MyLog.log zugreift. Dieser Code sperrt außerdem den Zugriff auf die Ressource über alternative Namen oder Pfade.

<FileIOPermissionAttribute(SecurityAction.PermitOnly, All := "C:\ "), FileIOPermissionAttribute(SecurityAction.Deny, All := "C:\MyLog.log")>

[FileIOPermissionAttribute(SecurityAction.PermitOnly, All = @"C:\ ")]
[FileIOPermissionAttribute(SecurityAction.Deny, All = @"C:\MyLog.log")] 

Siehe auch

Referenz

SecurityAction

RegistryPermissionAttribute

Konzepte

Erweitern von Metadaten mithilfe von Attributen

Überschreiben von Sicherheitsüberprüfungen

Codezugriffssicherheit