Entscheidungen zur Sicherheit sollten nicht auf Grundlage von Überprüfungen auf dem Client getroffen werden, sondern auf dem Server.

Die Website ist partitioniert in öffentlich zugängliche Bereiche und eingeschränkte Bereiche, für die eine Authentifizierung erforderlich ist. Bei der Navigation zwischen diesen Bereichen sollte keine Übertragung von wichtigen Anmeldeinformationen erfolgen.

Die Identitäten, mit denen ASP.NET-Webanwendungen auf Remoteressourcen zugreifen, sind eindeutig identifiziert.

Es wurden Mechanismen zum Schützen von Anmeldeinformationen, Authentifizierungstickets und anderen wichtigen Informationen für die Übertragung über das Netzwerk und die Speicherung in beständigen Speichern identifiziert.

Es ist ein sicherer Ansatz für die Ausnahmeverwaltung identifiziert. Die Anwendung schlägt auf sichere Weise fehl, wenn Ausnahmen auftreten.

Die Site verfügt über feinstufige Autorisierungsüberprüfungen für Seiten und Verzeichnisse.

Websteuerelemente, Benutzersteuerelemente und Ressourcenzugriffscode sind in eigenen Assemblys partitioniert, damit eine feinstufige Sicherheit erreicht wird.

Die Benutzereingabe wird auf Typ, Länge, Format und Bereich überprüft. Die Eingabe wird zuerst auf bekannte zulässige und sichere, anschließend auf böswillige und gefährliche Daten überprüft.

In Formularfelder eingegebene Zeichenfolgen werden mithilfe von regulären Ausdrücken überprüft (zum Beispiel durch das Steuerelement RegularExpressionValidator.)

Reguläre HTML-Steuerelemente, Abfragezeichenfolgen, Cookies und andere Formen der Eingabe werden mithilfe der Klasse Regex und/oder eines benutzerdefinierten Überprüfungscodes überprüft.

Bei der Dateneingabe wird das Steuerelement RequiredFieldValidator verwendet.

Bereichsüberprüfungen in Serversteuerelementen werden von RangeValidator-Steuerelementen durchgeführt.

Beliebige Eingaben werden überprüft, um bösartige Daten zu entfernen.

Eingabedateinamen sind wohlgeformt und innerhalb des Anwendungskontexts überprüfbar.

Eine Ausgabe, die Eingabedaten enthält, wird mit HtmlEncode und UrlEncode codiert.

Durch MapPath wird die anwendungsübergreifende Zuordnung eingeschränkt.

Die Zeichencodierung wird vom Server festgelegt (ISO-8859-1 wird empfohlen).

Die ASP.NET-Option (Version 1.1) validateRequest ist aktiviert.

URLScan ist auf dem Webserver installiert.

Die Option für HttpOnly-Cookies wird für die Tiefenverteidigung verwendet, um Cross-Site Scripting zu verhindern. (Dies gilt für Internet Explorer ab Version 6.1.)

Im Datenzugriffscode werden SQL-Parameter verwendet, um Länge und Typ von Daten zu überprüfen und SQL-Injektionen zu verhindern.

Die Site ist in eingeschränkte und öffentliche Bereiche partitioniert.

Für die Navigation werden absolute URLs verwendet, wenn die Site in sichere und nicht sichere Ordner partitioniert ist.

Anmeldeinformationen und Authentifizierungscookies werden mit SSL (Secure Sockets Layer) geschützt.

Das Attribut slidingExpiration ist auf "false" gesetzt und für eingeschränkte Authentifizierungscookies werden Zeitlimits gesetzt, wenn das Cookie nicht durch SSL geschützt wird.

Das Formularauthentifizierungscookie wird mit dem Attribut requireSSL oder der Cookieeigenschaft Secure auf HTTPS-Verbindungen beschränkt.

Das Authentifizierungscookie wird verschlüsselt und die Integrität wird überprüft (protection="All").

Authentifizierungscookies werden nicht beibehalten.

Anwendungscookies verfügen über eindeutige Pfad-/Namenskombinationen.

Personalisierungscookies sind getrennt von Authentifizierungscookies.

Kennwörter werden nicht direkt im Benutzerspeicher gespeichert, es werden stattdessen Kennwort-Digests mit einem Saltwert (Zufallszahlensequenz) gespeichert.

Die Anmeldeinformationen bei einem Identitätswechsel (wenn eine feste Identität verwendet wird) werden für die Konfigurationsdatei mit Aspnet_setreg.exe verschlüsselt.

Für die Authentifizierung sind Richtlinien für sichere Kennwörter implementiert.

Das Element

										<credentials>
									

										<forms>
									

Zugriffe auf Seiten und Verzeichnisse werden mit URL-Autorisierung gesteuert.

Die Dateiautorisierung wird mit der Windows-Authentifizierung verwendet.

Für die Sicherung des Zugriffs auf Klassen und Mitglieder werden Prinzipalberechtigungs-Anforderungen verwendet.

Wenn eine feinstufige Autorisierung erforderlich ist, werden explizite Rollenüberprüfungen verwendet.

Das Abrufen der Konfigurationsdatei wird durch HttpForbiddenHandler verhindert.

ASP.NET wird mit einem Konto mit geringsten Berechtigungen ausgeführt.

Benutzerdefinierte Kontoanmeldeinformationen werden (sofern verwendet) im Element

										<processModel>
									

Um für den gesamten Computer eine Richtlinie zu erzwingen, werden die Einstellungen in Web.config in Machine.config mit allowOveride="false" gesperrt.

Vertrauliche Daten werden im Netz mit SSL geschützt.

Es werden keine vertraulichen Daten zwischen Seiten weitergegeben, sie werden mithilfe einer Statusverwaltung auf dem Server verwaltet.

Es werden keine vertraulichen Daten in Cookies, ausgeblendeten Formularfeldern oder Abfragezeichenfolgen gespeichert.

Die Ausgabezwischenspeicherung wird für Seiten mit vertraulichen Daten ausgeschaltet.

In den Konfigurationsdateien Web.config und Machine.config werden Kennwörter im Klartext vermieden. (Anmeldeinformationen werden mit Aspnet_setreg.exe verschlüsselt.)

Auf allen Seiten mit authentifiziertem Zugriff wird das Sitzungscookie mit SSL geschützt.

Der Sitzungsstatusdienst ist deaktiviert, wenn er nicht verwendet wird.

Der Sitzungsstatusdienst (sofern verwendet) wird mit einem Konto mit geringsten Berechtigungen ausgeführt.

Um eine Verbindung zur Microsoft® SQL Server™-Statusdatenbank herzustellen, wird die Windows-Authentifizierung verwendet.

Der Zugriff auf die Statusdatenbank auf dem SQL-Server ist eingeschränkt.

Verbindungszeichenfolgen werden mit Aspnet_setreg.exe verschlüsselt.

Der Kommunikationskanal zum Statusspeicher wird (mit IPSec oder SSL) verschlüsselt.

Der Anzeigestatus wird mit Nachrichtenauthentifizierungscodes geschützt.

Für Abfragezeichenfolgen mit Serverschlüsseln wird ein Hashwert berechnet.

Alle Eingabeparameter werden überprüft.

Um One-Click-Angriffe entgegenzuwirken, wird Page.ViewStateUserKey verwendet.

Es wird eine strukturierte Ausnahmeverwaltung verwendet.

Die Ausnahmeinformationen werden auf dem Server protokolliert.

An den Client werden allgemeine Fehlerseiten mit harmlosen Meldungen zurückgegeben.

Fehlerbehandlungen werden auf Seitenebene und Anwendungsebene implementiert.

In der Anwendung wird zwischen Fehlern und Ausnahmebedingungen unterschieden.

Der ASP.NET-Prozess ist so konfiguriert, dass bei der Ausführung neue Ereignisquellen oder bei der Installation neue Anwendungsereignisquellen erstellt werden können.

<trace/>
Auf Produktionsservern ist die Ablaufverfolgung nicht aktiviert.

<trace enabled="false" />

<globalization>
Die Anforderungs- und Antwortcodierung ist entsprechend konfiguriert.

<httpRuntime>
maxRequestLength ist so konfiguriert, dass Benutzer am Upload sehr großer Dateien gehindert werden (optional).

<compilation>
Debugkompilierungen werden auf dem Produktionsserver deaktiviert mit
debug="false"

<compilation debug="false" . . ./>

<pages>
Wenn in der Anwendung der Anzeigestatus nicht verwendet wird, ist enableViewState auf "false" gesetzt.

<pages enableViewState="false" . . ./>

Wenn in der Anwendung der Anzeigestatus verwendet wird, sind enableViewState und enableViewStateMac auf "true" gesetzt, damit Änderungen des Anzeigestatus erkannt werden können.

<pages enableViewState="true" enableViewStateMac="true" />

<customErrors>
An den Client werden benutzerdefinierte Fehlerseiten zurückgegeben und die Rückgabe ausführlicher Ausnahmeinformationen wird verhindert, indem Sie mode="On" setzen.

<customErrors mode="On" />

Mit dem Attribut defaultRedirect wird eine allgemeine Fehlerseite angegeben.

<customErrors mode="On" defaultRedirect="/AnwFehlerseite.htm" />

<authentication>
Der Authentifizierungsmodus ist für die Unterstützung von Anwendungsanforderungen konfiguriert. Um die Verwendung eines bestimmten Authentifizierungstyps zu erzwingen, wird das Element

										<location>
									

									<location path="" allowOverride="false">  
  <system.web>    
    <authentication mode="Windows" />  
  </system.web></location>
								

<forms>
Die Website ist für öffentlichen und eingeschränkten Zugriff partitioniert.
Die Konfiguration der Formularauthentifizierung ist sicher:

<forms loginUrl="Eingeschränkt\Anmeldung.aspx"       
  protection="All"       
  requireSSL="true"       
  timeout="10"       
  name="AnwNameCookie"       
  path="/FormularAuth"       
  slidingExpiration="true" />

Das Authentifizierungscookie wird verschlüsselt und die Integrität wird überprüft (protection).
Für das Authentifizierungscookie ist SSL erforderlich (requireSSL).
Das Attribut (slidingExpiration) ist auf "false" gesetzt, wenn SSL nicht verwendet wird.
Die Gültigkeitsdauer der Sitzung ist beschränkt (timeout).
Cookienamen und -pfade sind eindeutig (name und path).
Das Element

										<credentials> wird nicht verwendet.
		

<identity>
Wechselidentitäten werden (sofern verwendet) für die Registrierung mit Aspnet_setreg.exe verschlüsselt:

<identity impersonate="true"          
   userName="registry:HKLM\SOFTWARE\IhreAnwendung\
identity\ASPNET_SETREG,userName"          
   password="registry:HKLM\SOFTWARE\IhreAnwendung\
identity\ASPNET_SETREG,password"/>

<authorization>
Das korrekte Format von Rollennamen wird überprüft.

<machineKey>
Wenn mehrere ASP.NET-Webanwendungen auf demselben Webserver bereitgestellt werden, wird mit der Einstellung IsolateApps die Erstellung eines getrennten Schlüssels für jede Webanwendung sichergestellt.

<machineKey validationKey="AutoGenerate,IsolateApps"
   decryptionKey="AutoGenerate,IsolateApps"      
   validation="SHA1" />

Wenn die ASP.NET-Webanwendung in einer Webfarm ausgeführt wird, werden bestimmte Computerschlüssel verwendet und auf alle Server der Farm kopiert.
Wenn der Anzeigestatus aktiviert ist, wird das Attribut validation auf SHA1 gesetzt.
Das Attribut validation wird auf 3DES gesetzt, wenn das Formularauthentifizierungscookie für die Anwendung verschlüsselt werden soll.

<sessionState>
Bei mode="StateServer" werden Anmeldeinformationen mit Aspnet_setreg.exe verschlüsselt in der Registrierung gespeichert.
Bei mode="SQLServer" wird die Windows-Authentifizierung verwendet, um eine Verbindung zur Statusspeicherdatenbank herzustellen, die Anmeldeinformationen werden mit Aspnet_setreg.exe verschlüsselt in der Registrierung gespeichert.

<httpHandlers>
Nicht genutzte Dateitypen werden HttpForbiddenHandler zugeordnet, um ein Abrufen von Dateien über HTTP zu verhindern. Beispiel:

<add verb="*" path="*.rem"            
   type="System.Web.HttpForbiddenHandler"/> 

<processModel>
Der ASP.NET-Prozess wird mit einem Konto mit geringsten Berechtigungen (wie ASPNET) ausgeführt.

<processModel userName="Machine" password="AutoGenerate"

Der ASP.NET-Prozess wird nicht mit dem Systemkonto ausgeführt.
Die Berechtigung Als Teil des Betriebssystems handeln wird dem Prozesskonto nicht gewährt.

<processModel  
   userName="registry:HKLM\SOFTWARE\MEINE_SICHERE_ANWENDUNG\  
   processmodel\ASPNET_SETREG,userName"  
   password="registry:HKLM\SOFTWARE\MEINE_SICHERE_ANWENDUNG\  
   processmodel\ASPNET_SETREG,password" . . ./>

Wenn die Anwendung Enterprise Services verwendet, sind comAuthenticationLevel und comImpersonationLevel entsprechend konfiguriert.
Mindestens die Authentifizierung der Ebene Aufruf ist gesetzt, um sicherzustellen, dass alle Methodenaufrufe von der Remoteanwendung authentifiziert werden können.
Ohne Schutz des Infrastrukturkanals (mit IPSec) wird PktPrivacy zur Verschlüsselung und Sicherung der Daten vor Manipulation im Netz verwendet.
PktIntegrity wird zur Sicherung der Daten vor Manipulation ohne Verschlüsselung verwendet (Personen, die das Netzwerk mit Netzwerkmonitoren abhören, können Ihre Daten einsehen.)

<webServices>
Nicht verwendete Protokolle sind deaktiviert.
Die automatische Generierung von WSDL (Web Services Description Language) ist deaktiviert (optional).

Sitzungsschlüssel. Um Serveraffinitäten zu vermeiden, wird der ASP.NET-Sitzungsstatus "Out-of-Process" in der ASP.NET-SQL Server-Statusdatenbank oder durch den auf dem Remotecomputer ausgeführten Out-of-Process-Statusdienst verwaltet.

Verschlüsselung und Überprüfung. Die zur Verschlüsselung und Überprüfung der Formularauthentifizierungscookies und der Statusanzeige verwendeten Schlüssel sind auf allen Servern einer Webfarm gleich.

DPAPI DPAPI kann nicht mit dem Computerschlüssel verwendet werden, um allgemeine Daten zu verschlüsseln, auf die alle Server in der Webfarm zugreifen müssen. Um freigegebene Daten auf einem Remoteserver zu verschlüsseln, verwenden Sie eine alternative Implementierung, zum Beispiel 3DES.

Anwendungen verfügen über unterschiedliche Computerschlüssel.
Verwenden Sie IsolateApps im Element

										<machineKey>
									

										<machineKey>
									

									<machineKey validationKey="AutoGenerate,IsolateApps"
    decryptionKey="AutoGenerate,IsolateApps" . . . />
								

Für Formularauthentifizierungscookies werden für jede Anwendung eindeutige Pfad-/Namenskombinationen aktiviert.

Für die Isolierung von Anwendungen werden unter Microsoft Windows® Server 2003 mehrere Prozesse (Anwendungspools in IIS 6.0) verwendet.

Für die Isolierung von Anwendungen werden unter Windows 2000 mehrere anonyme Benutzerkonten (und Identitätswechsel) verwendet.

Auf allen Servern in einer Webfarm werden allgemeine Computerschlüssel aktiviert.

Beim Hosten mehrerer Anwendungen auf einem einzigen Server werden für die einzelnen Anwendungen einzelne Computerschlüssel verwendet.

Für die Prozessisolierung und zur Einschränkung des Zugriffs auf Systemressourcen werden Sicherheitsvertrauensebenen für den Codezugriff verwendet (.NET Framework Version 1.1 erforderlich).

Temporäre ASP.NET-Dateien

%windir%\Microsoft.NET\Framework\{Version}\Temporary ASP.NET Files

ASP.NET-Prozesskonto und Wechselidentitäten: Vollzugriff

Temporäres Verzeichnis

(%temp%)

ASP.NET-Prozesskonto: Vollzugriff

.NET Framework-Verzeichnis

%windir%\Microsoft.NET\Framework\{Version}

ASP.NET-Prozesskonto und Wechselidentitäten:
Lesen und Ausführen
Ordnerinhalt

.NET Framework-Konfigurationsverzeichnis

%windir%\Microsoft.NET\Framework\{Version}\CONFIG

ASP.NET-Prozesskonto und Wechselidentitäten:
Lesen und Ausführen
Ordnerinhalt auflisten
Lesen

Websitestamm

C:\inetpub\wwwroot

oder der Pfad, auf den die standardmäßige Website verweist
ASP.NET-Prozesskonto: Vollzugriff

Systemstammverzeichnis

%windir%\system32

ASP.NET-Prozesskonto: Lesen

Globaler Assemblycache

%windir%\assembly

Prozesskonto und Wechselidentitäten: Lesen

Inhaltsverzeichnis

C:\inetpub\wwwroot\IhreWebanwendung

Prozesskonto:
Lesen und Ausführen
Ordnerinhalt auflisten
Lesen
Hinweis:Bei .NET Framework Version 1.0 sind außerdem für alle übergeordneten Verzeichnisse vom Inhaltsverzeichnis bis zum Stammverzeichnis des Dateisystems die oben aufgeführten Berechtigungen erforderlich. Zu den übergeordneten Verzeichnissen gehören:

C:\
C:\inetpub\
C:\inetpub\wwwroot\

Die IIS-Webberechtigungen sind konfiguriert.
Das Verzeichnis Bin verfügt nicht über Berechtigungen zum Lesen, Schreiben oder Durchsuchen von Verzeichnissen.
Die Ausführungsberechtigung wird auf Keine gesetzt.

Die Authentifizierungseinstellungen sind entfernt (so dass jeglicher Zugriff verweigert wird).