ASP.NET-Codezugriffssicherheit
Aktualisiert: November 2007
Einer der Vorteile der Verwendung von ASP.NET zum Hosten von mehreren Websites besteht in der Unterstützung der Codezugriffssicherheit durch die CLR (Common Language Runtime), die dem Schutz von Serveranwendungen dient. Dabei wird dem Code eine Sicherheitszonenklassifizierung zugewiesen, die anhand von Beweisen für den Ursprung des Codes bestimmt wird. Dies kann z. B. der starke Name einer Assembly oder der Ursprungs-URL sein.
Anwendungen, die als voll vertrauenswürdig ausgeführt werden, können mithilfe des Windows-Kontos (die ASP.NET-Prozessidentität), unter dem sie ausgeführt werden, durch NTFS-Dateiberechtigungen, Datenbankberechtigungen usw. eingeschränkt werden. Weitere Informationen finden Sie unter Konfigurieren der Prozessidentität in ASP.NET.
Grundsätzlich können Sie die Codezugriffssicherheit für eine einzelne Assembly konfigurieren, indem Sie sie als Assembly mit starkem Namen festlegen und Sicherheitsrichtlinien für diese Assembly hinzufügen. Viele ASP.NET-Assemblys werden allerdings während der Seitenkompilierung dynamisch erzeugt und verfügen deshalb über keinen starken Namen, sodass Sie die Sicherheitsrichtlinien für diese Assemblys indirekt konfigurieren müssen. Zudem werden assemblybasierte Beweise nicht unterstützt, da ASP.NET Anwendungen ohne Kompilierung unterstützt. Weil in ASP.NET-Anwendungen das Konzept von Verzeichnisstrukturen integriert ist, kann Codezugriffssicherheit weitaus leichter anhand der Kategorien von ASP.NET-Anwendungen konfiguriert werden. Daher muss .NET Framework nicht manuell so konfiguriert werden, dass es für jede ASP.NET-Anwendung auf einem Computer gesondert ausgeführt wird.
Mit ASP.NET können Sie jeder einzelnen Anwendung eine konfigurierbare Vertrauensebene zuweisen, die einem vordefinierten Satz von Berechtigungen entspricht. Standardmäßig wird Anwendungen basierend auf den in ihnen enthaltenen Sicherheitsinformationen eine Vertrauensebene zugewiesen. Um eine Webanwendung mit einem anderen Berechtigungssatz als Full auszuführen, müssen Sie eine der in ASP.NET-Vertrauensebenen und Richtliniendateien definierten Vertrauensebenen mit Richtlinien für teilweise Vertrauenswürdigkeit verwenden.
Mit den folgenden Konfigurationseinstellungen in der Datei Web.config einer Anwendung können Sie das Standardverhalten überschreiben und der Anwendung bestimmte Sicherheitsrichtlinien zuordnen:
<location path="SampleApp" allowOverride="false">
<trust level="High"
originUrl="https://www.contoso.com"/>
</location>
Das trust-Konfigurationselement kann auf Computerebene (in diesem Fall wird jede ASP.NET-Anwendung auf dieser Vertrauensebene ausgeführt) oder auf ein beliebiges Anwendungsstammverzeichnis in der Hierarchie angewendet werden (in diesem Fall gilt die Vertrauensebene für die entsprechende ASP.NET-Anwendung). Die Richtlinien für eine gesamte Site können Sie festlegen, indem Sie die Datei Web.config für die Stammanwendung der Site bearbeiten und das Stammverzeichnis der Site als Pfadspeicherort festlegen. Beispiel:
<location path="ContosoSite" allowOverride="false">
<trust level="High"
originUrl="https://www.contoso.com"/>
</location>
Für vertrauenswürdige Sites sollte das level-Attribut des trust-Konfigurationselements auf High festgelegt werden. Für nicht vertrauenswürdige Sites, z. B. einen Webserverhost von Sites, auf denen Code von einem externen Kunden ausgeführt wird, sollten Sie das level-Attribut des trust-Konfigurationselements auf Medium festlegen. Eine ausführliche Beschreibung der Ausführung von ASP.NET-Anwendungen mit mittlerer Vertrauenswürdigkeit finden Sie unter "How To: Use Medium Trust in ASP.NET 2.0" unter Patterns and Practices (PAG): Security Guidance for Applications.
Wenn Sie Vertrauenseinstellungen auf Computer- oder Siteebene konfigurieren, legen Sie i. d. R. das allowOverride-Attribut im location-Element auf false fest, damit für einzelne Anwendungen keine eigene Vertrauensebene angegeben werden kann. Dies ist die typische Vorgehensweise für freigegebene Serverinstallationen.
In der folgenden Tabelle sind die unterstützten Standardattribute für das trust-Konfigurationselement aufgelistet.
Attribut |
Beschreibung |
Unterstützte Werte |
|---|---|---|
level |
Gibt die Sicherheitszone an, in der die Anwendung ausgeführt wird. |
Full, High, Medium, Low und Minimal. |
originUrl |
Gibt einen URL oder ein URL-Muster an, der bzw. das für den Zugriff auf Verbindungen mithilfe von Klassen im System.Net-Namespace zulässig ist. Dieses Attribut kann ggf. zum Überprüfen von Berechtigungen für einige Objekte, z. B. die WebRequest-Instanz, verwendet werden, Konnektivität mit verschiedenen Netzwerkspeicherorten ermöglichen. Sie können dieses Attribut z. B. mit dem Hostnamen von Servern in einer Webfarm konfigurieren, sodass ASP.NET-Seiten Webdienste aufrufen können, die in derselben Webfarm wie die Webanwendung bereitgestellt werden. |
Wohlgeformte HTTP-URLs oder die Regex-basierte Syntax, die vom WebPermissionAttribute unterstützt wird. |
In der folgenden Tabelle sind die von der CLR unterstützten Berechtigungstypen sowie die Standardrichtlinien für die einzelnen Berechtigungen in unterschiedlichen Vertrauensebenen aufgelistet.
Berechtigung |
Full |
High |
Medium |
Low |
Minimal |
|---|---|---|---|---|---|
Full |
High |
Medium |
Low |
Minimal |
|
Uneingeschränkt |
Uneingeschränkt |
Keine Berechtigung |
Keine Berechtigung |
Keine Berechtigung |
|
Uneingeschränkt |
Uneingeschränkt |
Uneingeschränkt |
Keine Berechtigung |
Keine Berechtigung |
|
Uneingeschränkt |
Uneingeschränkt |
Read: TEMP, TMP, OS, USERNAME, COMPUTERNAME |
Keine Berechtigung |
Keine Berechtigung |
|
Uneingeschränkt |
Uneingeschränkt |
Read, Write, Append, PathDiscovery: Anwendungsverzeichnis |
Read, PathDiscovery: Anwendungsverzeichnis |
Keine Berechtigung |
|
Uneingeschränkt |
Uneingeschränkt |
AssemblyIsolationByUser, Uneingeschränkt UserQuota |
1 MB UserQuota (kann für einzelne Sites geändert werden), AssemblyIsolationByUser |
Keine Berechtigung |
|
Uneingeschränkt |
Keine Berechtigung |
Keine Berechtigung |
|||
Uneingeschränkt |
Keine Berechtigung |
Keine Berechtigung |
Keine Berechtigung |
||
Uneingeschränkt |
Uneingeschränkt |
Keine Berechtigung |
Keine Berechtigung |
Keine Berechtigung |
|
Uneingeschränkt |
Execution, Assertion, ControlPrincipal, ControlThread, RemotingConfiguration |
Execution, Assertion, ControlPrincipal, ControlThread, RemotingConfiguration |
|||
Uneingeschränkt |
Keine Berechtigung |
Keine Berechtigung |
|||
Uneingeschränkt |
Uneingeschränkt |
Keine Berechtigung |
Keine Berechtigung |
Keine Berechtigung |
|
Uneingeschränkt |
Uneingeschränkt |
Connect mit ursprünglichem Host (falls konfiguriert) |
Keine Berechtigung |
Keine Berechtigung |
|
Uneingeschränkt |
Uneingeschränkt |
Uneingeschränkt |
Keine Berechtigung |
Keine Berechtigung |
|
Ereignisprotokoll |
Uneingeschränkt |
Keine Berechtigung |
Keine Berechtigung |
Keine Berechtigung |
Keine Berechtigung |
Message Queue |
Uneingeschränkt |
Keine Berechtigung |
Keine Berechtigung |
Keine Berechtigung |
Keine Berechtigung |
Service Controller |
Uneingeschränkt |
Keine Berechtigung |
Keine Berechtigung |
Keine Berechtigung |
Keine Berechtigung |
Leistungsindikatoren |
Uneingeschränkt |
Keine Berechtigung |
Keine Berechtigung |
Keine Berechtigung |
Keine Berechtigung |
Verzeichnisdienst |
Uneingeschränkt |
Keine Berechtigung |
Keine Berechtigung |
Keine Berechtigung |
Keine Berechtigung |
Wenn eine Berechtigungsebene verfügbar ist, jedoch nicht explizit in den Sicherheitsrichtlinien erwähnt wird, kann diese von Anwendungen, die mit der Berechtigung Full ausgeführt werden, immer genutzt werden. Anwendungen, die mit geringerer Vertrauensebene ausgeführt werden, können Ressourcen nur verwenden, wenn Sie ihnen explizit Berechtigungen zuweisen, indem Sie die Sicherheitsrichtlinien ändern.
Wie der Tabelle zu entnehmen ist, haben Anwendungen mit dem Berechtigungssatz High Lese-/Schreibzugriff auf Dateien in ihren Anwendungsverzeichnissen, während Anwendungen mit der Vertrauensebene Low nur Leseberechtigung für Dateien in ihren Anwendungsverzeichnissen haben. Da der FileIOPermission-Typ einen physikalischen Pfad erfordert (z. B. c:\SampleAppPath), verwendet ASP.NET hier in den Richtliniendateien eine Anweisung mit Token, die zur Laufzeit durch die entsprechenden Pfadangaben für die Anwendung ersetzt wird.
Mithilfe des WebPermission-Typs kann die Anwendung unter Verwendung einer Klasse, z. B. System.Net.WebRequest, eine Verbindung mit dem vom ursprünglichen Hostattribut angegebenen Netzwerkspeicherort herstellen. In ASP.NET können Sie diese Berechtigung konfigurieren, indem Sie ein optionales originUrl-Attribut im trust-Abschnitt für eine bestimmte Anwendung einfügen. Das originUrl-Attribut ersetzt die $OriginHost$-Variable in Richtliniendateien, wie der folgende Abschnitt einer Datei Web_hightrust.config zeigt:
<IPermission class="WebPermission" version="1">
<ConnectAccess>
<URI uri="$OriginHost$"/>
</ConnectAccess>
</IPermission>