Codezugriffssicherheit für ASP.NET 4-Anwendungen

Codezugriffssicherheit (Code Access Security, CAS) ist der .NET Framework-Sicherheitsmechanismus (der "Sandkasten"), der von ASP.NET zum Erzwingen von Einschränkungen für die Ausführung von Code verwendet wird. In ASP.NET wird die Codezugriffssicherheit seit ASP.NET 1.1 mit dem Konzept von Vertrauensebenen implementiert.

In diesem Thema wird beschrieben, wie CAS in ASP.NET 4 funktioniert, wobei insbesondere erläutert wird, welche Änderungen es bei CAS im Vergleich zu den früheren Versionen gibt. Wenn Sie noch nicht mit ASP.NET vertraut sind, sind diese Änderungen für Sie wahrscheinlich nicht von Interesse. Dieses Thema enthält jedoch auch Informationen darüber, wie CAS in der aktuellen Version von ASP.NET funktioniert, und dies ist für den Entwurf neuer Anwendungen relevant.

In diesem Thema werden folgende Themen behandelt:

• Warum werden CAS-Richtlinienebenen nicht mehr verwendet und wie wirkt sich dies auf typische Szenarien aus? Beispielsweise auf das Aktivieren von teilweise vertrauenswürdigen ASP.NET-Anwendungen, die über UNC-Freigaben ausgeführt werden sollen.

• Vorgehensweise zum Anpassen des CAS-Verhaltens in ASP.NET 4.

• Kompatibilitätsprobleme, wenn vertrauenswürdiger Code für die Zusammenarbeit mit CAS in ASP.NET 4 konfiguriert wird.

In diesem Thema wird davon ausgegangen, dass Sie .NET Framework CAS- und ASP.NET-Vertrauensebenen verstehen. Weitere Informationen zu diesen Themen finden Sie in den folgenden Dokumenten:

• How to: Use Medium Trust in ASP.NET 2.0

• Verwenden der Codezugriffssicherheit mit ASP.NET

• Änderungen der Sicherheit in .NET Framework 4

• Blogserie zur CAS-Richtlinie und der CLR von Shawn Farkas

• Dieses Thema enthält folgende Informationen:

• Übersicht über das ASP.NET 4-Codezugriffssicherheit-Modell

• Homogene Anwendungsdomänen

• Bedingtes APTCA

• Sicherheitstransparenz und ihre Funktionsweise in ASP.NET 4

Übersicht über das ASP.NET 4-Codezugriffssicherheit-Modell

In ASP.NET 4 wurden im Vergleich zu ASP.NET 3.5 und früher mehrere wesentliche Änderungen an CAS vorgenommen. Hierzu gehören:

• Standardmäßig sind teilweise vertrauenswürdige ASP.NET 4-Anwendungsdomänen homogen. Hierdurch werden die möglichen Berechtigungssätze für Code eingeschränkt, der in einer teilweise vertrauenswürdigen Anwendungsdomäne ausgeführt wird. Dies bedeutet auch, dass die Vertrauensgrenze der Anwendungsdomäne selbst einem teilweise vertrauenswürdigen Berechtigungssatz zugeordnet ist. In homogenen Anwendungsdomänen überschneidet sich die Sicherheitsrichtlinie nicht mit CAS-Richtlinien auf Computer-, Benutzer- oder Unternehmensebene.

  Hinweis

  Das neue homogene Anwendungsdomänenmodell benötigt einen etwas anderen Satz deklarativer ASP.NET-Vertrauensrichtliniendateien als die in früheren Versionen von ASP.NET verwendeten Richtliniendateien.Nach der Installation von ASP.NET 4 enthält der Computer daher zwei Sätze mit ASP.NET-Richtliniendateien für teilweise Vertrauenswürdigkeit.Der eine Satz wird vom neuen CAS-Modell verwendet, und der andere Satz wird verwendet, wenn Anwendungen für die Verwendung eines älteren CAS-Modells (vor ASP.NET 4) konfiguriert wurden.

• In früheren Versionen von ASP.NET wurde das AspNetHostingPermission-Attribut für fast alle öffentlichen ASP.NET-bezogenen Klassen verwendet, um zu verhindern, dass ASP.NET-Typen in teilweise vertrauenswürdigen Nicht-Webumgebungen verwendet werden. Durch das Vorhandensein des AspNetHostingPermission-Attributs wurde z. B. die Verwendung der meisten ASP.NET-Klassen in einer teilweise vertrauenswürdigen ClickOnce-Anwendung verhindert. (Informationen zu CAS in ClickOnce-Anwendungen finden Sie unter Codezugriffssicherheit für ClickOnce-Anwendungen.) Statt sich auf das AspNetHostingPermission-Attribut zu verlassen, verwendet ASP.NET 4 eine andere CAS-Technologie, die als bedingtes APTCA (basierend auf dem AllowPartiallyTrustedCallersAttribute-Typ) bezeichnet wird, um das gleiche Ergebnis zu erzielen. Daher wurde das AspNetHostingPermission-Attribut aus den meisten ASP.NET-Typen und -Membern entfernt.

• In ASP.NET 4 wurden viele der Systemassemblys aktualisiert, damit das CLR-Sicherheitstransparenzmodell verwendet wird. Das Transparenzmodell in ASP.NET 4 ist dem in Silverlight verwendeten Transparenzmodell sehr ähnlich. Weitere Informationen zur Codetransparenz finden Sie unter Sicherheitstransparenter Code.

Sie werden die Auswirkungen dieser Änderungen bemerken, wenn Sie benutzerdefinierte CLR-CAS-Richtlinien verwendet haben, die mit Tools wie "caspol.exe" erstellt wurden. Die Änderungen wirken sich auch auf teilweise vertrauenswürdige Webanwendungen aus, die zum Ausführen privilegierter Vorgänge Assemblys benötigen, die im globalen Assemblycache (GAC) bereitgestellt sind, wenn nur ASP.NET- oder .NET Framework-Code in einer Aufrufliste aktiv ist. In den folgenden Abschnitten werden die CAS-Änderungen erläutert:

Homogene Anwendungsdomänen

In diesem Abschnitt werden homogene Anwendungsdomänen beschrieben. Sie erhalten Informationen zu Verhaltensänderungen seit ASP.NET 2.0, die sich auf homogene Anwendungsdomänen auswirken. Darüber hinaus werden auch die zur Auswahl stehenden Kompatibilitätsoptionen und die Codeänderungen erläutert, die Sie vornehmen können, um Code in homogenen Anwendungsdomänen auszuführen.

Reduzierte Anzahl möglicher Berechtigungssätze

Homogene Anwendungsdomänen sind teilweise vertrauenswürdige Anwendungsdomänen, die einen freigegebenen Berechtigungssatz zum Ausführen von Code definieren. In einer homogenen Anwendungsdomäne, die in ASP.NET 4 gehostet wird, ist der Code, der geladen werden kann, einem von zwei Berechtigungssätzen zugeordnet. Code wird entweder mit vollständiger Vertrauenswürdigkeit (Code aus dem GAC wird immer mit vollständiger Vertrauenswürdigkeit ausgeführt) oder mit dem Berechtigungssatz für teilweise Vertrauenswürdigkeit ausgeführt, der durch die die aktuelle trustLevel-Einstellung definiert wird. (Weitere Informationen finden Sie unter trustLevel-Element für securityPolicy (ASP.NET-Einstellungsschema).)

Hinweis

ASP.NET 4-Anwendungsdomänen sind standardmäßig voll vertrauenswürdig.Das homogene Verhalten in ASP.NET 4 tritt nur in Kraft, nachdem das name-Attribut des trustLevel-Elements auf einen anderen Wert als Full festgelegt wurde.

Dieses Verhalten unterscheidet sich von teilweise vertrauenswürdigen Anwendungen in früheren Versionen von ASP.NET. In früheren Versionen konnten Sie mehrere Berechtigungssätze erstellen, die jeweils verschiedene Berechtigungen und Mitgliedschaftsbedingungen umfassten. Homogene Anwendungsdomänen wurden in .NET Framework 4 eingeführt, da die Behandlung gemischter Berechtigungsszenarien schwierig war. Es war schwierig, mehrere Berechtigungssätze zu erstellen, die jeweils unterschiedliche Berechtigungsstufen aufwiesen, und dann sicherzustellen, dass die verschiedenen Berechtigungsstufen tatsächlich erzwungen wurden, nachdem alle Bedingungen, unter denen Code ausgeführt werden konnte, berücksichtigt wurden. Code konnte z. B. unter Reflektion ausgeführt werden. Vollständig vertrauenswürdiger Code konnte anderen vollständig vertrauenswürdigen Code im Auftrag eines teilweise vertrauenswürdigen Aufrufers ausführen usw. Der Berechtigungssatz musste sämtliche dieser Bedingungen berücksichtigen. Homogene Anwendungsdomänen vereinfachen CAS-Entscheidungen erheblich, indem sie die möglichen Ergebnisse reduzieren. Code hat entweder volle Vertrauenswürdigkeit oder einen einzelnen, gut definierten Berechtigungssatz für teilweise Vertrauenswürdigkeit. Für ASP.NET umfasst der gut definierte Berechtigungssatz für teilweise Vertrauenswürdigkeit die Berechtigungen, die für eine angegebene ASP.NET-Vertrauensebene gelten.

Es gibt einen dritten möglichen Zustand für Code, der versucht, sich in eine homogene Anwendungsdomäne zu laden. (Dies wird von der CLR nicht als ein separater Berechtigungssatz angesehen.) Der dritte Berechtigungssatz ist der leere Berechtigungssatz, der in allen in ASP.NET-Konfigurationsdateien für teilweise Vertrauenswürdigkeit als Nothing-Berechtigungssatz definiert wird. Sämtlicher Code, der als Nothing-Berechtigungssatz zugeordnet wird, wird als nicht ladbarer Code betrachtet. Daher führt jeder Versuch, Assemblys mit dem Nothing-Berechtigungssatz in eine homogene Anwendungsdomäne zu laden, zu einer SecurityException-Ausnahme.

Nur ASP.NET-Richtlinie für teilweise Vertrauenswürdigkeit wird anwendet

Der Berechtigungssatz für teilweise Vertrauenswürdigkeit einer homogenen Anwendungsdomäne wird nur vom Host, der für das Erstellen der Anwendungsdomäne zuständig ist, festgelegt. In ASP.NET 4 bedeutet dies, dass der Berechtigungssatz für teilweise Vertrauenswürdigkeit nur durch den Inhalt einer Konfigurationsdatei für teilweise Vertrauenswürdigkeit definiert wird, die sich im Unterverzeichnis CONFIG der .NET Framework-Installation befindet. Standardmäßig überschneiden sich die ASP.NET-Richtlinieninformationen für teilweise vertrauenswürdige ASP.NET-Anwendungsdomänen nicht mehr mit den CAS-Richtlinieneinstellungen auf Unternehmens-, Computer- oder Benutzerebene.

Globale CAS-Richtlinieninformationen (die Richtlinie, die Entwickler zuvor mit Tools wie "caspol.exe" oder dem MMC-Konfigurationstool "Mscorcfg.msc" verwaltet haben) haben keinen Einfluss mehr auf homogene ASP.NET 4-Anwendungsdomänen. (Sie können ASP.NET zum Verwenden eines früheren CAS-Modells konfigurieren, in dem sich ASP.NET-Einstellungen mit der Unternehmens-, Computer- und Benutzerrichtlinie überschneiden. Dieses Legacyverhalten wird in einem späteren Abschnitt erklärt.)

Die offensichtlichste Änderung betrifft die teilweise vertrauenswürdigen UNC-gehosteten ASP.NET 4-Anwendungen. In vorherigen Versionen mussten Sie UNC-Freigaben mithilfe von "caspol.exe" zu voller Vertrauenswürdigkeit heraufstufen, damit die ASP.NET-Richtlinien für teilweise Vertrauenswürdigkeit wirksam wurden. Dies war nötig, da in früheren Versionen von ASP.NET die CLR-CAS-Standardrichtlinie auf Computerebene zuerst wirksam wurde. Daher verfügten UNC-gehostete Anwendungen über einen eingeschränkten Berechtigungssatz, der mit der Intranetzone verknüpft war. Da teilweise vertrauenswürdige ASP.NET 4-Anwendungsdomänen die Richtlinie nur aus ASP.NET-Richtliniendateien erstellen, hat der physische Ort einer Webanwendung keinen Einfluss mehr auf den Berechtigungssatz, der einer teilweise vertrauenswürdigen Anwendung zugeordnet ist.

Ein Nebeneffekt dieser Änderung lässt sich anhand des folgenden Szenarios veranschaulichen: Ein Administrator möchte einen Webserver sperren, um für verwalteten Code standardmäßig keine Ausführungsberechtigungen zu erteilen und nur für ausgewählte ASP.NET-Anwendungen Ausführungsrechte zu gewähren. In früheren Versionen von ASP.NET erforderte dieses Szenario eine kaum bekannte Problemumgehung, die im folgenden KB-Artikel dokumentiert ist: FIX: Error message when you try to run an ASP.NET 2.0 Web application if you do not associate the My_Computer_Zone code group with the "full trust" permission set: "Server Application Unavailable. In ASP.NET 4 kann ein Administrator einen Webserver sperren, um mithilfe der folgenden Schritte Ausführungsberechtigungen zu verweigern oder zu erteilen:

1. Erstellen Sie eine benutzerdefinierte ASP.NET-Vertrauensebene, deren Richtliniendatei sämtlichen Code dem Nothing-Berechtigungssatz zuordnet (ein leerer Berechtigungssatz), und legen Sie dann in der Konfiguration aller ASP.NET-Anwendungen fest, dass standardmäßig diese Vertrauensebene verwendet wird. (Verwenden Sie hierzu die Web.config-Datei im Stammverzeichnis.)

2. Ordnen Sie einzelnen ASP.NET-Anwendungen selektiv entweder integrierte oder benutzerdefinierte Vertrauensebenen zu, die Ausführungsberechtigungen (und andere erforderliche Berechtigungen) für verwalteten Code gewähren. Zur computerweite Erzwingung können Sie Vertrauensebenen selektiv mit location-Elementen in der Web.config-Datei im Stammverzeichnis zuweisen.

Speicherort und Namenskonventionen für Vertrauensrichtliniendateien

Der Speicherort und die Namenskonvention von CAS-Richtliniendateien sind identisch mit früheren Versionen von ASP.NET. Die Standardvertrauensebenen lauten Full, High, Medium, Low und Minimal. Die Richtliniendateien, die die Berechtigungssätze für teilweise Vertrauenswürdigkeit für High bis Minimal definieren, befinden sich im Unterverzeichnis CONFIG des .NET Framework-Installationsverzeichnisses.

Die Richtliniendateien werden nach dem folgenden Muster benannt:

web_[trustlevelname]trust.config

Der Berechtigungssatz für teilweise Vertrauenswürdigkeit für die Vertrauensebene Medium befindet sich z. B. in der Datei mit dem Namen web_mediumtrust.config.

Änderungen bei den Vertrauensrichtliniendateien für ASP.NET 4

Größtenteils stimmen die Informationen in ASP.NET 4-CAS-Richtliniendateien mit den Informationen in den Richtliniendateien der Vorgängerversionen überein. Es gab jedoch geringfügige Ergänzungen für sowohl .NET Framework 3.5- als auch .NET Framework 4-Funktionen. Der Name des Berechtigungssatzes für teilweise Vertrauenswürdigkeit, der einer homogenen Anwendungsdomäne zugeordnet ist, lautet ASP.Net. Zudem werden dem gesamten Code, der sich entweder in der Verzeichnisstruktur einer Webanwendung oder in der Verzeichnisstruktur zur Codegenerierung befindet, standardmäßig die Berechtigungen aus dem benannten ASP.Net-Berechtigungssatz gewährt.

An den früheren Versionen der Richtliniendateien für teilweise Vertrauenswürdigkeit wurden zwei Änderungen vorgenommen:

• Am Ende jeder ASP.NET 4-CAS-Richtliniendatei gibt es kein CodeGroup-Element mehr, das einem Microsoft-Signaturschlüssel und dem ECMA-Signaturschlüssel volle Vertrauenswürdigkeit zuordnet. Diese Einträge wurden in ASP.NET 4 entfernt, da sie nur in früheren Versionen nötig waren, in denen nicht immer implizit angenommen wurde, dass der GAC volle Vertrauenswürdigkeit besitzt.

• Der Assertion-Teil des SecurityPermission-Attributs wurde aus allen ASP.NET 4-CAS-Richtliniendateien entfernt. Eine wesentliche in .NET Framework 4 von der CLR vorgenommene Änderung ist, dass der Code für teilweise Vertrauenswürdigkeit keine Berechtigungen bestätigen kann. Dies bedeutet, dass teilweise vertrauenswürdiger Code scheitert, auch wenn dieser versucht, Berechtigungen zu bestätigen, über die er bereits verfügt.

Bereich der teilweisen Vertrauenswürdigkeit

Sind Anwendungsdomänen homogen, bedeutet dies, dass ASP.NET 4-Anwendungsdomänengrenzen teilweise vertrauenswürdig sind. Wenn eine Anwendung in teilweiser Vertrauenswürdigkeit ausgeführt wird, führen Sicherheitsanforderungen zu einem Stackwalk. Sämtlicher Code im Stapel wird anhand der angeforderten Berechtigungen ausgewertet. In Anwendungsdomänen für ASP.NET 3.5 und früher war es üblich, dass Codepfade zu einem Stackwalk bis zur Anwendungsdomänengrenze führten. Da Anwendungsdomänengrenzen in früheren Versionen von ASP.NET 4 implizit voll vertrauenswürdig waren, sind die Stackwalks für einige Codepfade erfolgreich. In homogenen ASP.NET 4-Anwendungsdomänen werden alle Stackwalks, die die Anwendungsdomänengrenze erreichen, anhand des Berechtigungssatzes für teilweise Vertrauenswürdigkeit ausgewertet, der derzeit für die Anwendungsdomäne gültig ist.

Die Tatsache, dass die Anwendungsdomänengrenze jetzt teilweise vertrauenswürdig ist, ist die häufigste CAS-Änderung. Sie erfordert normalerweise, dass der voll vertrauenswürdige Code geändert wird, damit er in ASP.NET 4 funktioniert. Das ASP.NET-Entwicklungsteam musste z. B. zahlreichen internen Codepfaden gezielte Sicherheitsassertions hinzufügen, um Sicherheitsanforderungen zu unterdrücken und zu verhindern, dass diese die Anwendungsdomänengrenze erreichen. Wenn das Entwicklungsteam nicht so vorgegangen wäre, könnten grundlegende Aufgaben wie Seitenkompilierung nicht durchgeführt werden, da die Sicherheitsanforderungen für solche Vorgänge (z. B. Datei-E/A-Berechtigungen für die Kompilierung) scheitern, wenn diese mit dem Berechtigungssatz für teilweise Vertrauenswürdigkeit für Vertrauensebenen wie Medium verglichen werden.

Es gibt Erweiterungspunkte innerhalb von ASP.NET, die bewirken können, dass voll vertrauenswürdiger Code geladen und ausgeführt wird, wenn sich ASP.NET-Code im Stapel befindet. In diesen Szenarien befindet sich anfänglich nur ASP.NET-Code im Stapel, wenn ASP.NET einen benutzerdefinierten Typ aufruft, der eine Art von Erweiterungspunkt implementiert. Wenn der benutzerdefinierte Typ voll vertrauenswürdig ist (dies sollte nur der Fall sein, wenn der Typ im GAC bereitgestellt wird), bedeutet dies, dass die ganze Aufrufliste aus voll vertrauenswürdigem Code besteht. Wenn in einer homogenen Anwendungsdomäne ein beliebiger Code in einem voll vertrauenswürdigen Erweiterbarkeitstyp eine Sicherheitsanforderung auslöst, erreicht diese Forderung schließlich die Anwendungsdomänengrenze. Der Vorgang scheitert dann, wenn die Sicherheitsüberprüfung basierend auf dem Berechtigungssatz für teilweise Vertrauenswürdigkeit durchgeführt wird.

In Folgenden werden einige ASP.NET-Erweiterungspunkte aufgelistet, für die diese Situation eintreten kann:

• Benutzerdefinierter HTTP-Handler Ein benutzerdefinierter Handler wird während der Handlerausführungsphase der Pipeline aufgerufen.

• Benutzerdefiniertes HTTP-Modul Ein benutzerdefiniertes HTTP-Modul wird während der Pipelineereignisse aufgerufen, für die das Modul registriert wurde.

• Benutzerdefinierte Buildanbieter und Ausdrucks-Generatoren Diese Typen werden von ASP.NET beim Analysieren und Kompilieren von ausführbarem Inhalt, z. B. ASPX-Dateien, aufgerufen.

• Rollen-Manager-Anbieter Ein benutzerdefinierter Anbieter kann während des AuthorizeRequest-Ereignisses in der Pipeline aufgerufen werden.

• Profilanbieter Ein benutzerdefinierter Anbieter kann aufgerufen werden, um Profildaten während des EndRequest-Ereignisses automatisch zu speichern.

• Systemüberwachungsanbieter Ein benutzerdefinierter Anbieter kann jederzeit aufgerufen werden, um angesammelte Systemüberwachungsdaten zu speichern.

Mit einem einfachen Beispiel für einen benutzerdefinierten HTTP-Handler wird das geänderte CAS-Verhalten veranschaulicht. Im folgenden Beispiel versucht der Handlercode, eine Textdatei zu lesen, die sich im Stammverzeichnis von Laufwerk "C:\" befindet.

Public Class CustomHandler 
    Implements IHttpHandler 
    Public Sub ProcessRequest(ByVal context As HttpContext) 
        Dim data As String = File.ReadAllText("c:\testfile.txt") 
        context.Response.Write(data) 
    End Sub 
    
    Public Sub New() 
    End Sub 
    
    Public ReadOnly Property IsReusable() As Boolean 
        Get 
            Return False 
        End Get 
    End Property 
End Class

public class CustomHandler : IHttpHandler

{

public void ProcessRequest(HttpContext context)

{

string data = File.ReadAllText("c:\\testfile.txt");

context.Response.Write(data);

}

public CustomHandler() { }

public bool IsReusable { get { return false; } }

}

Wenn der Handler signiert, mit dem AllowPartiallyTrustedCallersAttribute-Attribut gekennzeichnet und im GAC bereitgestellt ist, ist der Code erfolgreich, falls der Handler in einer Anwendung mit mittlerer Vertrauensebene in ASP.NET 3.5 oder früher verwendet wird. Für dieses Beispiel wird die mittlere Vertrauensebene ausgewählt, da der Berechtigungssatz für teilweise Vertrauenswürdigkeit E/A-Lese- und -Schreibzugriffe auf die Datei nur in der Verzeichnisstruktur der Anwendung zulässt. Voll vertrauenswürdiger Code, z. B. der Beispielhandler, kann in ASP.NET 3.5 und früher auf andere Speicherorte zugreifen. Dies ist darauf zurückzuführen, dass sich bei der Ausführung des Handlers nur voll vertrauenswürdiger Code im Stapel befindet, und die Anwendungsdomänengrenze selbst ist voll vertrauenswürdig. Daher wird die Datei-E/A-Anforderung des ReadAllText-Aufrufs implizit dadurch erfüllt, dass die Anwendungsdomänengrenze voll vertrauenswürdig ist.

Wenn der gleiche Handlercode jedoch in einer ASP.NET 4-Anwendung mit mittlerer Vertrauensebene verwendet wird, scheitert der Code, da der Aufruf von ReadAllText zu einer Datei-E/A-Anforderung für den Lesezugriff auf die Textdatei führt. Die Datei-E/A-Anforderung bewirkt einen Stackwalk, der letztendlich die Anwendungsdomänengrenze erreicht. In ASP.NET 4 ist die Anwendungsdomänengrenze dem Berechtigungssatz für die mittlere Vertrauensebene zugeordnet, und dieser Berechtigungssatz gewährt keinen Zugriff auf das Stammverzeichnis von Laufwerk "C:\". Daher scheitert die Datei-E/A-Anforderung.

Für ASP.NET 4 müssen Sie den Stackwalk unterdrücken. Hierzu verwenden Sie das SecurityAction.Assert-Attribut des FileIOPermission-Attributs der ProcessRequest-Methode. Im folgenden Beispiel wird veranschaulicht, wie das FileIOPermission-Attribut zu diesem Zweck verwendet wird.

[Visual Basic]

Public Class CustomHandler 
    Implements IHttpHandler 

    <FileIOPermission(SecurityAction.Assert, Read = "c:\testfile.txt")> _ 
    Public Sub ProcessRequest(ByVal context As HttpContext) 
        Dim data As String = File.ReadAllText("c:\testfile.txt") 
        context.Response.Write(data) 
    End Sub 
    
    Public Sub New() 
    End Sub 
    Public ReadOnly Property IsReusable() As Boolean 
        Get 
            Return False 
        End Get 
    End Property 
End Class

[C#]

public class CustomHandler : IHttpHandler

{

[FileIOPermission(SecurityAction.Assert, Read = "c:\\testfile.txt")]

public void ProcessRequest(HttpContext context)

{

string data = File.ReadAllText("c:\\testfile.txt");

context.Response.Write(data);

}

public CustomHandler() { }

public bool IsReusable { get { return false; } }

}

Sie können entweder deklarative Asserts (wie im Beispiel gezeigt) oder programmgesteuerte Asserts verwenden. Die empfohlene Vorgehensweise ist, die geringstmöglichen Berechtigungen, die zum Ausführen eines Codeblocks erforderlich sind, mit deklarativen Asserts zu bestimmen. Obwohl es eine einfache Lösung zu sein scheint, überall uneingeschränkte Sicherheitsassertions hinzuzufügen, ist dieser Ansatz nicht empfehlenswert. Die Sicherheitsfehler, die auf das Verhalten der neuen homogenen Anwendungsdomäne zurückzuführen sind, sollen Sie veranlassen, vollständig vertrauenswürdigen Code zu analysieren und zu verstehen, welche privilegierten Vorgänge der vollständig vertrauenswürdige Code erfordert. Sie können dann den geringstmöglichen Satz von Berechtigungen, die zum erneuten Aktivieren des voll vertrauenswürdigen Codes erforderlich sind, selektiv mit einem Assert bestimmen.

Konfigurieren von ASP.NET 4-Anwendungen zum Verwenden des ASP.NET 2.0-CAS-Modells

Es ist möglich, ASP.NET 4-Anwendungen für die Verwendung der ASP.NET 1.0- und ASP.NET 2.0-CAS-Verhaltensweisen zu konfigurieren. In ASP.NET 4 stellt das trust-Element ein neues legacyCasModel-Attribut bereit, das standardmäßig auf false festgelegt ist. Durch Festlegen dieses Attributs auf true wird eine ASP.NET 4-Anwendung so konfiguriert, dass der Großteil des ASP.NET CAS-Verhaltens aus früheren Versionen verwendet wird.

Wenn das LegacyCasModel-Attribut auf true festgelegt wird, treten die folgenden Verhaltensweisen auf:

• Teilweise vertrauenswürdige Anwendungsdomänengrenzen verwenden volle Vertrauenswürdigkeit. Das bedeutet, dass in Szenarien, in denen vollständig vertrauenswürdiger Code nur mit vollständig vertrauenswürdigem Code im Stapel ausgeführt wird, keine Assertions verwendet werden müssen, um Sicherheitsanforderungen zu unterdrücken.

• Einstellungen für CAS-Richtlinien auf Unternehmens-, Computer- und Benutzerebene, die für das .NET Framework 4 definiert sind, überschneiden sich mit der ASP.NET-CAS-Richtlinie. Dies bedeutet, dass alle benutzerdefinierten Berechtigungen, die mit dem .NET Framework 4-Tool "caspol.exe" oder mit "Mscorcfg.msc" erstellt werden, wirksam werden.

  Hinweis

  Da die Richtliniendateien für die Basissicherheit und das caspol.exe-Tool für .NET Framework 4 sich in einem anderen Verzeichnis als diejenigen für .NET Framework 2.0 befinden, muss jede benutzerdefinierte Sicherheitsrichtlinie, die für .NET Framework 2.0 erstellt wurde, für .NET Framework 4 mit der .NET Framework 4-Version von "caspol.exe" neu erstellt werden.

• Sie können mehrere benutzerdefinierte Berechtigungssätze angeben, die für verschiedene Assemblys gelten.

Die folgenden CAS-bezogenen Verhaltensweisen bleiben sogar im Legacy-CAS-Modus unverändert:

• ASP. NET 4-Assemblys sind immer noch als bedingtes APTCA gekennzeichnet. (Bedingtes APTCA wird weiter unten in diesem Thema beschrieben.) Bedingtes APTCA kann nicht auf den Legacymodus zurückgesetzt werden, da hierzu das AspNetHostingPermission-Attribut aus den meisten öffentlichen ASP.NET 4-APIs entfernt werden müsste. Es kann nicht effizient festgelegt werden, dass diese Berechtigung zwar für öffentliche ASP.NET-APIs gilt, wenn diese im Legacy-CAS-Modus ausgeführt werden, aber nicht gültig ist, wenn die Assemblys im neuen CAS-Modell ausgeführt werden.

• Eine Berechtigung darf nicht mehr von teilweise vertrauenswürdigem Code bestätigt werden. Der Code, dem zuvor teilweise Vertrauenswürdigkeit gewährt wurde, kann die Assert-Methode aufrufen und erfolgreich eine beliebige Berechtigung bestätigen, die dem teilweise vertrauenswürdigen Code bereits gewährt wurde. In .NET Framework 4 ist die Ausführung von Sicherheitsasserts durch teilweise vertrauenswürdigen Code nicht mehr zulässig (unabhängig vom CAS-Modell, das für eine ASP.NET-Anwendung gültig ist).

In ASP.NET 4 wird die CAS-Richtlinie aus einem anderen Satz von Konfigurationsdateien für teilweise Vertrauenswürdigkeit gelesen. Dies ist notwendig, um die Berechtigungssätze, die im Legacy-CAS-Modell gültig sind, vom einzelnen Berechtigungssatz zu unterscheiden, der im neuen CAS-Modell gültig ist, wenn das LegacyCasModel-Attribut des trust-Elements auf true festgelegt ist. Für jede Vertrauensrichtliniendatei, die für die in ASP.NET integrierten Vertrauensebenen vorhanden ist, sind zwei Versionen der Datei vorhanden. In ASP.NET wird eine Version für das neue CAS-Modell und die andere Version für das Legacy-CAS-Modell gelesen. Wenn ASP.NET 4 beispielsweise für die mittlere Vertrauensebene im Legacymodus ausgeführt wird, wird die Richtliniendatei mit dem Namen "legacy.web_mediumtrust.config" gelesen. Beachten Sie, dass der Dateiname mit "legacy" beginnt. ASP.NET 4 verwendet die gleiche Namenskonvention für alle CAS-Richtliniendateien und die integrierten ASP.NET-Vertrauensebenen. Der primäre Unterschied zwischen dem Legacy- und Nicht-Legacy-CAS-Richtliniendateien ist, dass die Legacydateien die CodeGroup-Definition enthalten, die auf den Microsoft-Signaturschlüssel und den ECMA-Signaturschlüssel verweist.

Da Sie eine Anwendung zur Verwendung des alten CAS-Modells konfigurieren können, sollten Sie für vorhandene Anwendungen ggf. die LegacyCasModel-Option auf true festlegen, um mögliche Änderungen zu vermeiden. Es ist jedoch wichtig zu verstehen, dass die Legacyoption in erster Linie vorhanden ist, um die Umstellung vorhandener Anwendungen auf das ASP.NET 4-CAS-Modell zu erleichtern. In der Zukunft konzentrieren sich CLR- und ASP.NET-Teams auf den Entwurf und die Codierung mit dem neuen CAS-Modell.

Silverlight 2 war der erste Funktionsbereich von .NET Framework, der auf das neue Modell umgestellt wurde. Das Ziel für .NET Framework ist, dass alle Desktop- und Serverszenarien mit teilweiser Vertrauenswürdigkeit mit dem neuen CAS-Modell ausgeführt werden können. Daher wird empfohlen, sich die Mühe zu machen, Anwendungen so zu konfigurieren, dass sie das CAS-Modell unterstützen. Entsprechend sollten Administratoren, die sich zuvor auf "caspol.exe" und "Mscorcfg.msc" verlassen haben, stattdessen die ASP.NET-Vertrauensrichtliniendateien und Berechtigungszuweisungen anpassen.

Anpassen der Berechtigungssatzzuweisung im ASP.NET 4-CAS-Modell

Obwohl die homogenen ASP.NET 4-Anwendungsdomänen Code entweder auf volle Vertrauenswürdigkeit oder auf den benannten ASP.NET-Berechtigungssatz für teilweise Vertrauenswürdigkeit beschränken, können Entwickler und Administratoren die Zuordnung eines Berechtigungssatzes zu einer Assembly beeinflussen. Mit den folgenden Ansätzen können Sie den Prozess anpassen, mit dem ein Berechtigungssatz einem Teil des ausgeführten Codes zugeordnet wird:

• Sie können die Richtliniendatei für teilweise Vertrauenswürdigkeit für eine einzelne Vertrauensebene anpassen. (Dieser Ansatz war in früheren Versionen von ASP.NET möglich.)

• Sie können voll vertrauenswürdige ASP.NET 4-Assemblys statisch konfigurieren.

• Sie können den ASP.NET 4-Typ HostSecurityPolicyResolver verwenden, um auf eingeschränkte Weise auf die Funktionen der CLR-Klasse HostSecurityManager zuzugreifen.

Die ersten zwei dieser Ansätze erlauben deklarative Anpassungen, und die dritte Option erlaubt Anpassungen im Code.

Anpassen von Richtliniendateien für eine Vertrauensebene

Der erste Ansatz zum Ändern von ASP.NET-Richtliniendateien für teilweise Vertrauenswürdigkeit ist der Gleiche wie in früheren Versionen von ASP.NET: Sie können den Satz von Berechtigungen im benannten ASP.NET-Berechtigungssatz ändern. Sie können auch mehr CodeGroup-Definitionen hinzufügen, die benutzerdefinierte Mitgliedschaftsbedingungen enthalten. Wie zuvor erwähnt, müssen die neuen CAS-Anpassungen in Richtliniendateien für teilweise Vertrauenswürdigkeit vorgenommen werden, z. B. "web_mediumtrust.config". Die Dateien, deren Name mit "legacy" beginnt, werden analysiert und verwendet, wenn das LegacyCasModel-Attribut des trust-Elements auf true festgelegt ist.

Für ASP.NET 4 müssen alle benutzerdefinierten CodeGroup-Definitionen einem von drei möglichen Berechtigungssätzen zugeordnet werden: FullTrust, ASP.Net (d. h. dem Berechtigungssatz für teilweise Vertrauenswürdigkeit) oder Nothing. Da teilweise vertrauenswürdige ASP.NET 4-Anwendungsdomänen standardmäßig homogen sind, müssen die benutzerdefinierten Richtlinieneinträge mit einem eingeschränkten Satz von Berechtigungssätzen ausgewertet werden. Es mag so aussehen, dass Sie verschiedene benannte Berechtigungssätze definieren können, wenn Sie das ASP.NET 4-CAS-Modell verwenden. Aber jeder Code, der mit einem anderen Berechtigungssatz als FullTrust, ASP.Net oder Nothing ausgeführt wird, führt zu einer SecurityException-Laufzeitausnahme. Hiermit wird angegeben, dass die CLR den ausgewerteten Berechtigungssatz nicht erkannt hat.

Der FullTrust-Berechtigungssatz gibt an, dass Code mit voller Vertrauenswürdigkeit ausgeführt wird. Der ASP.Net-Berechtigungssatz ist der benannte Berechtigungssatz für teilweise Vertrauenswürdigkeit, der in der Regel für teilweise vertrauenswürdige Anwendungsdomänen verwendet wird. Wie zuvor beschrieben, ist Nothing kein tatsächlicher von der CLR erkannter Berechtigungssatz; stattdessen handelt es sich um den leeren Berechtigungssatz. Wenn die CLR feststellt, dass eine Assembly einem leeren Berechtigungssatz zugeordnet ist, löst die CLR eine SecurityException-Ausnahme aus und lädt die Assembly nicht.

Zudem können Sie in ASP.NET 4 den Namen des ASP.Net-Berechtigungssatzes mithilfe des PermissionSetName-Attributs des trust-Elements ändern. Sie können einen anderen Namen für das PermissionSetName-Attribut festlegen. Zur Laufzeit sucht ASP.NET 4 in der Richtliniendatei für teilweise Vertrauenswürdigkeit nach einem PermissionSet-Element gleichen Namens. Dieser benannte Berechtigungssatz wird dann für eine homogene Anwendungsdomäne als Berechtigungssatz für teilweise Vertrauenswürdigkeit verwendet. Es ist unwahrscheinlich, dass dies notwendig ist. Die Möglichkeit, den Namen des Berechtigungssatzes für teilweise Vertrauenswürdigkeit in einen anderen Namen als ASP.Net zu ändern, wurde geschaffen, um Hostingumgebungen wie SharePoint integrieren zu können, die im Unterschied zum ASP.NET-Standardberechtigungssatz einen eigenen benannten Berechtigungssatz als Entität definieren. (Denken Sie daran, dass es im neuen CAS-Modell nicht mehr möglich ist, mehrere benannte Berechtigungssätze zu haben, die Berechtigungen für teilweise Vertrauenswürdigkeit definieren.) Obwohl Sie den Namen des Berechtigungssatzes für teilweise Vertrauenswürdigkeit in einen anderen Namen als ASP.Net ändern können, kann dennoch immer nur jeweils ein Berechtigungssatz für teilweise Vertrauenswürdigkeit für eine Anwendung gültig sein.

Angeben von Assemblys, denen volle Vertrauenswürdigkeit gewährt wird

Die zweite deklarative Richtlinienanpassung ist in ASP.NET 4 neu. Sie ermöglicht es Ihnen, explizit eine Liste von Assemblyidentitäten festzulegen, denen immer volle Vertrauenswürdigkeit gewährt wird. Die securityPolicy-Konfiguration enthält einen neuen untergeordneten fullTrustAssemblies-Konfigurationsabschnitt. Der Abschnitt FullTrustAssembliesSection ist eine Standardauflistung, die Vorgänge zum Hinzufügen, Entfernen und Löschen unterstützt und in der Sie eine oder mehrere Assemblyidentitäten angeben können, denen zur Laufzeit volle Vertrauenswürdigkeit gewährt wird. Das folgende Beispiel zeigt einen fullTrustAssemblies-Konfigurationsabschnitt.

<system.web>

<securityPolicy>

<fullTrustAssemblies>

<add assemblyName="MyCustomAssembly"

version="1.0.0.0"

publicKey="a 320 hex character representation

of the public key blob used with a

signed assembly"

/>

</fullTrustAssemblies>

</securityPolicy>

</system.web>

Jeder Eintrag im fullTrustAssemblies-Element identifiziert eine Assembly durch den Assemblynamen und die Assemblyversion und durch eine Zeichenfolge mit 320 Zeichen, die die Hexadezimalzeichendarstellung der öffentlichen Hälfte des Signaturschlüssels ist.

Hinweis

In den künftigen, neuen .NET Framework-Assemblys können ggf. 2048-Bit-Signaturschlüssel verwendet werden.Wenn neue Assemblys freigegeben werden, die 2048-Bit-Signaturschlüssel verwenden, führt dies zu Hexadezimalzeichenfolgen mit einer Länge von 576 Zeichen.

In der Definition ist kein Assemblyspeicherort angegeben. Für das Suchen und Laden von Assemblys ist die jeweilige Hostingumgebung (z. B. ASP.NET 4) zuständig. Wenn eine geladene Assembly mit den Informationen übereinstimmt, die in einem der add-Elemente in fullTrustAssemblies enthalten sind, wird der Assembly volle Vertrauenswürdigkeit gewährt.

Sie sollten fullTrustAssemblies für Assemblys verwenden, die nicht im GAC bereitgestellt werden, die aber immer mit voller Vertrauenswürdigkeit ausgeführt werden sollen. Da in fullTrustAssemblies aufgeführte Assemblys an jeder Stelle in der Konfigurationshierarchie angepasst werden können (von der Web.config-Datei im Stammverzeichnis bis zu den einzelnen Web.config-Dateien auf Anwendungsebene), ist das Verwenden dieser Einstellung einfacher und flexibler als das Verwenden einer Mitgliedschaftsbedingung und einer Codegruppe in einer Richtliniendatei für teilweise Vertrauenswürdigkeit. Sie können die fullTrustAssemblies-Listen für einzelne Anwendungen anpassen, indem Sie unterschiedliche Informationen für verschiedene Anwendungen angeben. Dies kann entweder in Web.config-Dateien auf Anwendungsebene oder in der Web.config-Datei im Stammverzeichnis mit location-Elementen erfolgen.

Der Satz voll vertrauenswürdiger Assemblys wird sofort festgelegt, wenn eine teilweise vertrauenswürdige Anwendungsdomäne erstellt wird. Dies bewirkt Folgendes: Wenn eine Richtliniendatei für teilweise Vertrauenswürdigkeit Informationen enthält, die dazu führen, dass für eine im fullTrustAssemblies-Element aufgeführte Assembly ein anderer Berechtigungssatz gewährt wird, werden die Informationen ignoriert, und der Assembly wird volle Vertrauenswürdigkeit erteilt.

Programmgesteuertes Anpassen von Berechtigungen

Sie können die Zuordnung eines Berechtigungssatzes zu einer Assembly auch programmgesteuert ändern, indem Sie eine benutzerdefinierte Implementierung vom ASP.NET 4-Typ HostSecurityPolicyResolver erstellen. Zur Laufzeit verwendet ASP.NET 4 eine eigene Implementierung des CLR-Typs HostSecurityManager. Ein HostSecurityManager-Objekt wird von der CLR jedes Mal aufgerufen, wenn eine Assembly geladen wird. Eine der Funktionen der HostSecurityManager-Eigenschaft ist, ein PermissionSet-Objekt zurückzugeben, das einer angegebenen Assembly und als Beweis zugeordnet werden sollte. In ASP.NET 4 können Sie diesen Prozess anpassen, indem ein benutzerdefiniertes HostSecurityPolicyResolver-Objekt jedes Mal aufgerufen wird, wenn die CLR von ASP.NET 4 eine Berechtigungssatzentscheidung anfordert.

Sie können ein benutzerdefiniertes HostSecurityPolicyResolver-Objekt mithilfe des HostSecurityPolicyResolverType-Attributs des trust-Elements konfigurieren. Wenn ASP.NET 4 feststellt, dass ein benutzerdefiniertes HostSecurityPolicyResolver-Objekt für eine Anwendung konfiguriert ist, wird jedes Mal die ResolvePolicy-Methode des benutzerdefinierten Resolvers aufgerufen, wenn die CLR eine Berechtigungssatzentscheidung anfordert. Im Gegensatz zu einem HostSecurityManager-Objekt kann ein HostSecurityPolicyResolver-Objekt jedoch nur einen beschränkten Satz möglicher Entscheidungen an ASP.NET 4 zurückgeben. Der Rückgabewert der ResolvePolicy-Methode muss einem der folgenden gültigen Werte aus der HostSecurityPolicyResults-Enumeration entsprechen:

• DefaultPolicy. Hiermit wird angegeben, dass ASP.NET 4 eine eigene Logik verwenden sollte, um den richtigen Berechtigungssatz für die Assembly zu ermitteln. Sie sollten DefaultPolicy für Assemblys zurückgeben, für die das HostSecurityPolicyResolver-Objekt keine Entscheidung zum Berechtigungssatz treffen soll. Durch die Rückgabe von DefaultPolicy wird veranlasst, dass ASP.NET den Berechtigungssatz einer Assembly auf Grundlage der deklarativen Codegruppen und der Mitgliedschaftsbedingungen bestimmt, die in der Richtliniendatei für teilweise Vertrauenswürdigkeit für die aktuelle ASP.NET-Vertrauensebene definiert sind.

• FullTrust. Der Assembly sollte volle Vertrauenswürdigkeit gewährt werden.

• AppDomainTrust. Zudem sollte der Assembly der Berechtigungssatz für teilweise Vertrauenswürdigkeit gewährt werden, der der Anwendungsdomäne zugeordnet ist. Normalerweise bedeutet dies, dass der Assembly die Berechtigungen erteilt werden, die im benannten ASP.Net-Berechtigungssatz definiert sind.

• None. Der Berechtigungssatz für die Assembly wird auf den Nothing-Berechtigungssatz festgelegt.

Da die HostSecurityPolicyResolver-Basisklasse über eine Vererbungsanforderung für eine uneingeschränkte Sicherheitsberechtigung verfügt und es möglich sein muss, ein benutzerdefiniertes HostSecurityPolicyResolver-Objekt zu laden, ohne dass einem anderen HostSecurityPolicyResolver-Objekt volle Vertrauenswürdigkeit gewährt werden muss, sollten konkrete Implementierungen einer HostSecurityPolicyResolver-Klasse immer signiert und im GAC bereitgestellt werden.

Im folgenden Beispiel wird ein benutzerdefiniertes HostSecurityPolicyResolver-Objekt veranschaulicht, das allen Assemblys, die aus einem bestimmten Verzeichnis geladen werden, volle Vertrauenswürdigkeit gewährt. Dies ist ein denkbares Szenario für Organisationen, die kompilierte Assemblys an einen bestimmten Speicherort auf einem Datenträger (nicht im GAC) einfügen und möchten, dass alle Dateien aus diesem Speicherort automatisch mit voller Vertrauenswürdigkeit ausgeführt werden. Damit ASP.NET-Anwendungen Assemblys von außerhalb der Verzeichnisstruktur einer Webanwendung laden können, müssen Sie explizite Umleitungen der Assemblybindung hinzufügen, die Assemblyidentitäten anderen physischen Speicherorten auf einem Datenträger zuordnen.

[Visual Basic]

Public Class MyCustomResolver 
    Inherits HostSecurityPolicyResolver 
    Public Overloads Overrides Function ResolvePolicy(ByVal evidence _
            As Evidence) As HostSecurityPolicyResults 
        Dim urlEvidence As Url = evidence.GetHostEvidence(Of Url)() 
        
        If (urlEvidence IsNot Nothing) AndAlso _
            (urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll")) Then 
            Return HostSecurityPolicyResults.FullTrust 
        End If 
        
        ' Specify that ASP.NET should perform its own logic.
        Return HostSecurityPolicyResults.DefaultPolicy 
    End Function 
End Class

public class MyCustomResolver : HostSecurityPolicyResolver
{ 
  public override HostSecurityPolicyResults 
                              ResolvePolicy(Evidence evidence)
  {
            Url urlEvidence = evidence.GetHostEvidence<Url>();
            if ( (urlEvidence != null)  && 
                 (urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll"))
               )
                return HostSecurityPolicyResults.FullTrust;

            // Specify that ASP.NET should perform its own logic.
            return HostSecurityPolicyResults.DefaultPolicy;
  }
}

Bedingtes APTCA

In Versionen vor .NET Framework 4 wurden viele voll vertrauenswürdige Assemblys (einschließlich ASP.NET-Assemblys) mit dem Attribut AllowPartiallyTrustedCallersAttribute (APTCA) gekennzeichnet. Dieses Attribut erteilt teilweise vertrauenswürdigen Aufrufern Zugriff auf öffentliche Typen und Member, die in Assemblys definiert sind, die mit dem APTCA-Attribut gekennzeichnet wurden. In .NET Framework 4 umfasst die CLR eine Variation von APTCA, die als bedingtes APTCA bezeichnet wird. (Die Kurzform für bedingtes APTCA ist C-APTCA.) C-APTCA ermöglicht Assemblys, die mit dem APTCA-Attribut gekennzeichnet sind, die APTCA-Eigenschaften nur in bestimmten gehosteten Umgebungen beizubehalten. Durch C-APTCA kann in ASP.NET 4 also einfacher gesteuert werden, in genau welchen teilweise vertrauenswürdigen Hostumgebungen teilweise vertrauenswürdige Aufrufer öffentliche ASP.NET 4-APIs erfolgreich aufrufen können.

Funktionsweise von C-APTCA

Sowohl teilweise vertrauenswürdige Hostumgebungen als auch voll vertrauenswürdige Assemblys sind für die Funktionsweise von C-APTCA relevant. Teilweise vertrauenswürdige Hostumgebungen, in denen Berechtigungssätze wichtig sind, können der CLR eine Liste von Assemblys bereitstellen, deren APTCA-Einstellung berücksichtigt werden sollte. Sollen die APTCA-Eigenschaften von voll vertrauenswürdigen Assemblys nur in bestimmten Hostumgebungen aktiviert werden, wird dies mit der folgenden Variation des APTCA-Attributs auf Assemblyebene angegeben:

[assembly: AllowPartiallyTrustedCallers(PartialTrustVisibilityLevel=NotVisibleByDefault)]

Zur Laufzeit, wenn die CLR zum Laden einer Assembly aufgefordert wird, die als C-APTCA gekennzeichnet ist, überprüft die CLR die von der Hostumgebung bereitgestellte Liste der gültigen C-APTCA-Assemblys. Wenn die Assembly in der Liste vorhanden ist, behandelt die CLR den gesamten öffentlich verfügbar gemachten Code in der Assembly so, als ob die Assembly in früheren Versionen von .NET Framework mit dem APTCA-Attribut gekennzeichnet worden wäre.

Wenn eine C-APTCA-Assembly nicht in der von der Hostumgebung bereitgestellten Liste von Assemblys aufgeführt ist, die als APTCA behandelt werden sollen, wird die Assembly dennoch geladen, aber ohne APTCA-Eigenschaften. Die tatsächliche Verfügbarkeit öffentlicher APIs für teilweise vertrauenswürdigen Benutzercode in einer solchen Assembly ändert sich abhängig davon, ob die Assembly zu 100 % sicherheitstransparent ist oder nicht. Das heißt, es hängt davon ab, ob die Assembly mit einem SecurityTransparentAttribute-Attribut auf Assemblyebene gekennzeichnet ist. (Sicherheitstransparenz in ASP.NET 4 wird in einem späteren Abschnitt in diesem Thema beschrieben.)

Zusammenfassend lässt sich sagen, dass öffentliche APIs in ASP.NET 4 sich auf eine der folgenden Arten verhalten können:

• Für die meisten ASP.NET-Assemblys sind alle öffentlichen APIs für teilweise vertrauenswürdige Aufrufer nicht verfügbar. Hierdurch wird praktisch verhindert, dass die Mehrheit der öffentlichen APIs in ASP.NET 4 in beliebigen teilweise vertrauenswürdigen Umgebungen außer Webanwendungen verwendet werden können.

• Eine Handvoll ASP.NET-Assemblys, die als 100 % sicherheitstransparent gekennzeichnet sind, können dennoch von teilweise vertrauenswürdigen Aufrufern aufgerufen werden. Wenn die Codepfade in diesen Assemblys schließlich den Rest der ASP.NET-CodeBase erreichen, scheitern die Aufrufe jedoch. Das Ergebnis ist das gleiche Verhalten wie in früheren Versionen von ASP.NET, mit dem kleinen Unterschied, dass API-Aufrufe in ASP.NET 4-Assemblys weiter fortschreiten, bevor sie scheitern.

  Beachten Sie Folgendes zu Assemblys, die als sicherheitstransparent gekennzeichnet sind:

  • Es gibt nur zwei ASP.NET-Assemblys, die auf Assemblyebene als sicherheitstransparent gekennzeichnet werden: "System.Web.DynamicData.dll" und "System.Web.RegularExpressions.dll".

  • "System.Web.Routing.dll" wird in ASP.NET 4 nicht als 100 % sicherheitstransparent angesehen, da alle Typen, die in früheren Versionen von ASP.NET in dieser Assembly definiert wurden, zu "System.Web.dll" verschoben wurden. In ASP.NET 4 ist "System.Web.Routing.dll" eine reine Metadatenassembly.

In ASP.NET 4 wird die C-APTCA-Attributvariation in den folgenden Assemblys gefunden:

• System.Web.dll

• System.Web.Extensions.dll

• System.Web.DynamicData.dll

• System.Web.DataVisualization.dll

• System.ComponentModel.DataAnnotations.dll

• System.Web.ApplicationServices.dll. Diese Assembly ist in ASP.NET 4 neu.

• System.Web.Abstractions.dll. Typen in dieser Assembly wurden nicht zu "System.Web.dll" für ASP.NET 4 verschoben.

• System.Web.Routing.dll. Typen in dieser Assembly wurden nicht zu "System.Web.dll" für ASP.NET 4 verschoben.

C-APTCA im Vergleich zu ASP.NET-Hosting-Berechtigungsattributen

Durch C-APTCA ist es möglich, das AspNetHostingPermission-Attribut in ASP.NET 4 aus 99 % der öffentlichen APIs zu entfernen. Das AspNetHostingPermission-Attribut wird immer noch an einigen Stellen in ASP.NET 4 verwendet, aber nur dort, wo der Zweck der Berechtigung wirklich sinnvoll ist. Überall sonst sind die zwei folgenden Verwendungen des AspNetHostingPermission-Attributs verschwunden:

<AspNetHostingPermission(SecurityAction.LinkDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)>
<AspNetHostingPermission(SecurityAction.InheritanceDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)>

[AspNetHostingPermission(SecurityAction.LinkDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)]
[AspNetHostingPermission(SecurityAction.InheritanceDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)]

Diese Berechtigungsdefinitionen wurden in früheren Versionen von ASP.NET verwendet, um zu verhindern, dass ASP.NET-Assemblys in teilweise vertrauenswürdige Nicht-Webumgebungen geladen werden. Die größten Bedenken gab es bei teilweise vertrauenswürdigen verwalteten Steuerelementen und verwalteten Anwendungen, die in Browsern wie Microsoft Internet Explorer und Mozilla Firefox geladen wurden. Durch Verwenden von C-APTCA wird effektiv der gleiche Schutz erzwungen, da ClickOnce-Anwendungen und browserbasierte verwaltete Steuerelemente keine C-APTCA-Assemblys zur Behandlung als vollständiges APTCA definieren.

Anpassen der ASP.NET 4-Liste für C-APTCA

Wie zuvor erwähnt, können einzelne Hostumgebungen der CLR eine Liste von bedingten C-Assemblys bereitstellen, deren APTCA-Eigenschaften berücksichtigt werden sollen. ASP.NET 4 stellt der CLR eine hartcodierte Liste bereit, die alle ASP.NET 4-Assemblys enthält. Stellt ASP.NET 4 diese Liste nicht bereit, würden Webanwendungen sofort scheitern, wenn versucht wird, die erste Zeile des internen ASP.NET-Codes in einer teilweise vertrauenswürdigen Anwendungsdomäne auszuführen.

In .NET Framework 4 ist C-APTCA ein neues CAS-Konzept, das noch nicht in andere Teile von .NET Framework implementiert wurde. Daher ist es wahrscheinlich, dass künftige Versionen von .NET Framework mehr C-APTCA-Assemblys enthalten. Zudem wächst die Gruppe der C-APTCA-Assemblys, je mehr Sie sich mit C-APTCA vertraut machen und für eigene vollständig vertrauenswürdige Assemblys verwenden. Da es unmöglich ist, dass ASP.NET 4 alle möglichen C-APTCA-Assemblys im Voraus kennt, umfasst ASP.NET 4 einen Konfigurationsabschnitt, dem C-APTCA-Assemblys hinzugefügt werden können.

Der vorhandene securityPolicy-Abschnitt umfasst einen untergeordneten Konfigurationsabschnitt mit dem Namen partialTrustVisibleAssemblies. Dies ist eine Standardauflistung, die Vorgänge zum Hinzufügen, Entfernen und Löschen unterstützt und in der Sie eine oder mehrere Assemblyidentitäten angeben können, die als APTCA behandelt werden sollen (sofern diese auch für C-APTCA gekennzeichnet sind). Das folgende Beispiel zeigt einen partialTrustVisibleAssemblies-Abschnitt.

<system.web>
  <securityPolicy>
    <partialTrustVisibleAssemblies>

      <add assemblyName="MyCustomAssembly"
           publicKey="a 320 hex character representation 
                      of the public key blob used with a 
                      signed assembly"
      />

    </partialTrustVisibleAssemblies>
  </securityPolicy>
</system.web>

Jeder Eintrag im partialTrustVisibleAssemblies-Abschnitt identifiziert eine Assembly anhand des Assemblynamens. Jeder Eintrag wird auch durch eine Zeichenfolge mit einer Länge von 320 Zeichen identifiziert (z. B. 0x03FA4D...), die die Hexadezimalzeichendarstellung der öffentlichen Hälfte des Signaturschlüssels ist, der für die C-APTCA-Assembly verwendet wird. Sie müssen kein Versionsattribut angeben. Nur der Assemblyname und ein öffentliches Schlüsseltoken sind für die CLR erforderlich.

Wenn Sie eine C-APTCA-Assembly aktivieren, sollten Sie auch den transitiven Abschluss von C-APTCA-Assemblys aktivieren, da sich dies erheblich auf die Leistung auswirkt. Wenn z. B. C-APTCA-Assembly A von der APTCA-Assembly B abhängt, und die APTCA-Assembly B wiederum von der C-APTCA-Assembly C abhängt, sollten Sie bedingtes APTCA sowohl für A als auch für C aktivieren. Andernfalls kann die Leistung der Anwendung beeinträchtigt werden. Beispielsweise werden Codefreigabe und NGen-Images deaktiviert, wenn der vollständige C-ATPCA-Abschluss nicht aktiviert wird.

Einfluss von C-APTCA auf teilweise vertrauenswürdige Nicht-Webanwendungen

In ASP.NET-Versionen vor ASP.NET 4 waren einige Typen und Namespaces nicht mit dem AspNetHostingPermission-Attribut gekennzeichnet. Daher konnten diese Typen von teilweise vertrauenswürdigen Nicht-ASP.NET-Umgebungen wie ClickOnce-Anwendungen aufgerufen werden. Zu den Typen und Namespaces, die auf diese Weise aufgerufen werden konnten, gehörten folgende:

• Typen im System.Web.ClientServices-Namespace.

• Typen im System.Web.ClientServices.Providers-Namespace.

• Der HttpUtility-Typ.

Die System.Web.ClientServices-Typen können nicht in teilweise vertrauenswürdigen .NET Framework 4-Umgebungen, z. B. ClickOnce, verwendet werden. Da die enthaltene Assembly ("System.Web.Extensions.dll") eine ASP.NET 4-Assembly ist, die für C-APTCA gekennzeichnet ist, und APTCA in ClickOnce für keine C-APTCA-Assemblys zulässig ist, kann keiner der Clientdiensttypen von teilweise vertrauenswürdigen ClickOnce-Anwendungen aufgerufen werden.

Für dieses Verhalten gibt es mehrere Gründe. Erstens, .NET Framework 4 wurde in einen Client und eine erweiterte SKU aufgeteilt, und die Annahme ist, dass viele ClickOnce-Anwendungen für die Client-SKU entwickelt werden. Es würde einen beträchtlichen Aufwand erfordern, ASP.NET-Clientdiensttypen für die Client-SKU umzugestalten.

Zweitens, es ist schwierig zu bestimmen, wie die Clienttypen umgestaltet werden sollen, während die erforderlichen C-APTCA-Grenzen beibehalten werden. Daher sind in .NET Framework 4 die Clientdiensttypen nur für voll vertrauenswürdige Nicht-ASP.NET-Umgebungen verfügbar, einschließlich ClickOnce-Anwendungen, die für die Ausführung mit voller Vertrauenswürdigkeit mithilfe der erweiterten .NET Framework 4 SKU konfiguriert sind.

Für den HttpUtility-Typ hängt die Auswirkung von C-APTCA von den Methoden ab, die Sie verwendet haben, so wie in den folgenden Szenarien veranschaulicht:

• Der teilweise vertrauenswürdige Code ruft entweder die HtmlEncode-Methode oder HtmlDecode-Methode der WebUtility-Klasse auf. Der WebUtility-Typ enthält die ASP.NET-HTML-Codierungs- und Decodierungsimplementierungen, aber diese wurden umgestaltet und in den System.Net-Namespace verschoben, der in "System.dll" enthalten ist. Da "System.dll" in allen teilweise vertrauenswürdigen Hostumgebungen verfügbar ist, gibt es kein Problem mit den Methoden vom Typ WebUtility, die auf teilweise vertrauenswürdige Nicht-ASP.NET-Anwendungen zugreifen.

• Der teilweise vertrauenswürdige Code ruft eine beliebige der anderen Methoden der WebUtility-Klasse auf. In diesem Fall tritt das gleiche Problem auf, das weiter oben für die Clientdienste beschrieben wurde. Das heißt, WebUtility steht nur für vollständig vertrauenswürdige Nicht-ASP.NET-Aufrufer in .NET Framework 4 zur Verfügung.

Sicherheitstransparenz in ASP.NET 4

Mithilfe der Sicherheitstransparenz können Sie die CLR darüber informieren, ob ein Codeblock jemals einen sicherheitsrelevanten Vorgang ausführt. Transparenter Code kann nie verwendet werden, um Berechtigungen zu bestätigen, einen Linkaufruf zu erfüllen oder systemeigenen Code bzw. sicherheitskritischen Code aufzurufen. Zudem kann er keinen nicht überprüfbaren Code enthalten. Dies gilt unabhängig davon, ob transparenter Code voll vertrauenswürdig (z. B. im GAC) oder teilweise vertrauenswürdig ist.

Sicherheitstransparenz ist eine leistungsstarke Funktion für .NET Framework-Funktionen wie ASP.NET. Mithilfe der Sicherheitstransparenz kann ASP.NET die CLR beispielsweise darüber informieren, dass Teile des ASP.NET-Codes nie Berechtigungen bestätigen werden und dass der Code nie sicherheitsrelevante Vorgänge, z. B. PInvoke-Aufrufe, im systemeigenen Code implementiert oder durchgeführt. Auf diese Weise kann der .NET Framework-Code das Sicherheitsrisiko für eine große Anzahl öffentlicher und interner APIs erheblich reduzieren, obwohl der .NET Framework-Code sich im voll vertrauenswürdigen GAC befindet.

Sicherheitstransparenz kann entweder auf eine ganze Assembly oder nur auf eine Teilmenge des Codes in der Assembly angewendet werden. Obwohl idealerweise die gesamte Assembly für die Sicherheitstransparenz gekennzeichnet werden sollte, besteht für bestimmte Teile des .NET Framework-Codes die gerechtfertigte Notwendigkeit, sicherheitsrelevante Aufgaben auszuführen. Assemblys, die 100 % sicherheitstransparenten Code enthalten, werden mit einem SecurityTransparentAttribute-Attribut auf Assemblyebene gekennzeichnet.

Assemblys, die eine Mischung aus transparentem und nicht transparentem Code enthalten, besitzen kein Transparenzattribut auf Assemblyebene. Stattdessen können einzelne Klassen in der Assembly entweder mit dem SecuritySafeCriticalAttributel-Attribut oder dem SecurityCriticalAttribute-Attribut gekennzeichnet werden.

Das Verhalten von Klassen ohne Attribut ist komplex. Einfach ausgedrückt werden Typen ohne Attribut in ASP.NET 4-Assemblys, die auf dem neuen Transparenzmodell basieren, als sicherheitstransparent angesehen. Typen in ASP.NET 4-Assemblys, die keine Attribute aufweisen und nicht auf dem neuen Transparenzmodell basieren, werden als sicherheitsgeschützt betrachtet.

Sicherheitstransparenz in der Praxis und Sicherheitsregelsätze

Da ein so großer Teil der ASP.NET 4-CodeBase in "System.Web.dll" enthalten ist, war es nicht praktikabel, den gesamten ASP.NET 4-Code in das neue Transparenzmodell zu konvertieren. Stattdessen kann ASP.NET 4-Code in die folgenden Kategorien gruppiert werden:

• Code, in dem das neue Transparenzmodell nicht übernommen wurde. Hierzu gehört Code in den folgenden Assemblys:

  • System.Web.dll

  • System.Web.ApplicationServices.dll

  • System.Web.Mobile.dll. Die Typen in dieser Assembly wurden in ASP.NET 4 als veraltet gekennzeichnet. Obwohl die Assembly immer noch vorhanden ist, wird angenommen, dass die Typen in dieser Assembly bald nicht mehr verwendet werden.

• Code, in dem das neue Transparenzmodell verwendet wird. Hierzu gehört Code in den folgenden Assemblys:

  • System.Web.Extensions.dll

  • System.Web.DynamicData.dll (100 % sicherheitstransparent)

  • System.Web.RegularExpressions.dll (100 % sicherheitstransparent)

  • System.ComponentModel.DataAnnotations.dll

  • System.Web.DataVisualization.dll

• Assemblys, die nur Metadaten umfassen und deren Typen zu einer anderen ASP.NET-Assembly verschoben wurden, einschließlich der folgenden Assemblys:

  • System.Web.Abstractions.dll. Die Typen, die in früheren Versionen von ASP.NET in dieser Assembly enthalten waren, wurden zu "System.Web.dll" verschoben. Daher ist "System.Web.Abstractions.dll" in ASP.NET 4 eine reine Metadatenassembly.

  • System.Web.Routing.dll. Die Typen, die in früheren Versionen von ASP.NET in dieser Assembly enthalten waren, wurden zu "System.Web.dll" verschoben. Daher ist "System.Web.Routing.dll" in ASP.NET 4 eine reine Metadatenassembly.

Im .NET Framework 4 wurde für die CLR ein neues Konzept eingeführt, das als Sicherheitsregelsatz bezeichnet wird. Es gibt zwei Ebenen von SecurityRuleSet-Konfigurationen: Ebene eins und Ebene zwei. Die SecurityRuleSet-Konfiguration für alle Typen wird mit dem SecurityRulesAttribute-Attribut auf Assemblyebene angegeben. ASP.NET 4-Assemblys, für die das neue Transparenzmodell übernommen wurde, werden mit dem folgenden Attribut auf Assemblyebene gekennzeichnet:

System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level2)

ASP.NET 4-Assemblys, für die das Transparenzmodell von .NET Framework 2.0 verwendet wird (das bedeutet für ASP.NET praktisch keine Transparenz, da ASP.NET vor ASP.NET 4 nie Transparenzkonzepte verwendet hat), werden mit dem folgenden Attribut auf Assemblyebene gekennzeichnet:

System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level1)

Für ASP.NET-Assemblys, die das neue Transparenzmodell (und die öffentlichen Typen, die sich in den Assemblys befinden) übernommen haben, wird der Großteil des Codes als sicherheitstransparent angesehen. Ein kleine Menge von Code in diesen Assemblys führt sicherheitsrelevante Vorgänge aus, und dieser Code wird entweder als sicherheitsgeschützter oder kritischer Code gekennzeichnet.

Für ASP.NET-Assemblys, die das neue Transparenzmodell nicht übernommen haben (abgesehen von veralteten Assemblys oder Assemblys mit Typumleitung) können alle öffentlichen APIs von teilweise vertrauenswürdigem Benutzercode aufgerufen werden und intern sicherheitsrelevante Vorgänge ausführen. Die Kombination aus offenem Zugriff, teilweise vertrauenswürdigen Aufrufern und der Möglichkeit sicherheitsrelevanter Vorgänge bedeutet, dass älterer ASP.NET 4-Code eine genauere Untersuchung erfordert. Da die meisten neuen ASP.NET-Funktionen jedoch in neueren Assemblys wie "System.Web.Extensions.dll" und "System.Web.DynamicData.dll" oder in separaten Versionen wie ASP.NET MVC implementiert sind, ist der größte Teil des neuen ASP.NET-Codes sicherheitstransparent und daher standardmäßig sicherer als älterer Code.

Standardmäßig behandelt die CLR die öffentlichen APIs aller ASP.NET 4-Assemblys, die als SecurityRuleSet.Level1 gekennzeichnet sind, als sicherheitsgeschützt (äquivalent zur Kennzeichnung mit dem SecuritySafeCriticalAttribute-Attribut), sofern die Hostumgebung das APTCA-Attribut berücksichtigt. Wenn APTCA nicht unterstützt wird, löst die CLR einen Linkaufruf für volle Vertrauenswürdigkeit aus. Dieser scheitert, wenn sich im Stapel ein beliebiger teilweise vertrauenswürdiger Benutzercode befindet. Anders ausgedrückt, wenn APTCA für eine ASP.NET-Assembly, die als SecurityRuleSet.Level1 gekennzeichnet ist, nicht berücksichtigt wird, ist das Verhalten mit dem in vorherigen Versionen von .NET Framework identisch, wenn teilweise vertrauenswürdiger Code versucht hat, eine vollständig vertrauenswürdige Assembly anzurufen, die nicht mit dem APTCA-Attribut gekennzeichnet war.

Standardmäßig behandelt die CLR die öffentlichen APIs aller ASP.NET 4-Assemblys, die als SecurityRuleSet.Level2 gekennzeichnet sind, als sicherheitstransparent (äquivalent zur Kennzeichnung mit dem SecurityTransparentAttribute-Attribut), sofern die Hostumgebung das APTCA-Attribut berücksichtigt. Andernfalls wird das folgende Verhalten definiert:

• Wenn APTCA nicht berücksichtigt wird und eine Assembly, die als Level2 gekennzeichnet ist, nicht zu 100 % sicherheitstransparent ist, behandelt die CLR die öffentliche Oberfläche als sicherheitskritisch. Daher scheitern alle teilweise vertrauenswürdigen Aufrufer, die versuchen, die öffentliche Oberfläche zu verwenden, wahrscheinlich mit einer MethodAccessException-, TypeAccessException- oder FieldAccessException-Ausnahme.

• Wenn APTCA nicht berücksichtigt wird und eine Assembly, die als Level2 gekennzeichnet ist, zu 100 % sicherheitstransparent ist, können teilweise vertrauenswürdige Aufrufer öffentliche APIs in dieser Assembly erfolgreich aufrufen. In der Praxis bedeutet dies, dass im weiteren Verlauf des Aufrufpfads eine SecurityException-Ausnahme auftritt, wenn im Code in der zu 100 % sicherheitstransparenten Assembly schließlich entweder eine ASP.NET-Assembly der Ebene 1 oder eine ASP.NET-Assembly der Ebene 2 aufgerufen wird, die nicht zu 100 % sicherheitstransparent ist.

Transparenz und ASP.NET-Kompilierung

Die vom ASP.NET-Kompilierungssystem erstellte Ausgabe ist auch von der ASP.NET 4-Übernahme sowohl des neuen CAS-Modells als auch des neuen Sicherheitstransparenzmodells betroffen. Dies schließt Elemente wie Seitenassemblys, vorkompilierte Assemblys und die kompilierten Ergebnisse des Verzeichnisses "App_Code" ein. Das Verhalten des Kompilierungssystems variiert abhängig von der Einstellung des LegacyCasModel-Attributs des trust-Elements.

In der folgenden Tabelle wird beschrieben, wie dynamisch kompilierte Objekte in sowohl dem Legacy-CAS-Modell als auch dem neueren CAS-Modell gekennzeichnet werden.

legacyCasModel-Attributeinstellung	Website-Vertrauensebene	Attribute, die auf kompilierte Assemblys angewendet werden
False (neues CAS-Modell)	Volle Vertrauenswürdigkeit	SecurityRules(SecurityRuleSet.Level2)
	Hohe Vertrauenswürdigkeit oder niedriger	SecurityRules(SecurityRuleSet.Level2)
SecurityRules(SecurityRuleSet.Level2)
True (altes CAS-Modell)	Volle Vertrauenswürdigkeit	SecurityRules(SecurityRuleSet.Level1)
	Hohe Vertrauenswürdigkeit oder niedriger	SecurityRules(SecurityRuleSet.Level1)

Da das Verhalten des ASP.NET 4-Kompilierungssystems je nach den Einstellungen des LegacyCasModel-Attributs des trust-Elements variiert, können in Bezug auf die Freigabe von kompiliertem Code für verschiedene teilweise vertrauenswürdige ASP.NET 4-Anwendungen ggf. Einschränkungen bestehen. Im Allgemeinen sollten Sie keine Änderung am Anwendungsverhalten feststellen. In einigen Szenarien funktionieren kompilierte Artefakte, die aus einer teilweise vertrauenswürdigen Anwendung erstellt wurden, deren LegacyCasModel-Attribut auf false festgelegt ist(die also das neue CAS-Modell verwendet), jedoch nicht wie erwartet, wenn sie mit anderen Anwendungen verwendet werden. Daher müssen Sie für einige Szenarien (z. B. eine freigegebene Bibliothek von kompilierten ASCX-Steuerelementen, die signiert, als ATPCA gekennzeichnet und im GAC bereitgestellt sind) die sicherheitsgeschützten und kritischen Attribute ggf. explizit auf einen Teil des Codes anwenden, wenn die Bibliothek mit Level2 gekennzeichnet wird.

Siehe auch

Weitere Ressourcen

ASP.NET-Anwendungssicherheit in Hostumgebungen