Inhalt
Vorwort
1 Wie .NET und ASP.NET funktionieren
2 Installation
3 Hinweise zu VB.NET
4 »Hallo, Welt!« – Ein ASP.NET-Crashkurs
5 Die Page-Klasse
6 HTML-Serversteuerelemente
7 Validierung von Anwendereingaben
8 Webserversteuerelemente
9 Webserversteuerelemente für die Darstellung von Listen
10 Webserversteuerelemente selbst erstellen
11 Der Status von Seiten, Sitzungen und Applikationen
12 ASP.NET und Datenbanken
13 »Wer darf was?« ASP.NET und Sicherheit
14 Webanwendungen erstellen und konfigurieren
15 Leistungssteigerung durch Caching
16 Web Services
A Anhang
Index
Download (ca 14,3 MB)
Buch bestellen (29,90 EUR)
Ihre Meinung?@
<< zurück | Galileo Computing / <openbook> / Einstieg in ASP.NET | vor >>
Einstieg in ASP.NET von Matthias Lohrer
| Kapitel 13 »Wer darf was?« ASP.NET und Sicherheit
|  | 13.1 »Wer darf was?« mit Windows-Bordmitteln entscheiden
|  |  | 13.1.1 Windows, Standardauthentifizierung
|  |  | 13.1.2 Windows, Digestauthentifizierung
|  |  | 13.1.3 Integrierte Windows-Authentifizierung
|  |  | 13.1.4 Beispiel für die Verwendung der Windows-Standardauthentifizierung
|  |  | 13.1.5 Dateibasierte Autorisierung über ACL verwenden
|  |  | 13.1.6 Kriterien für die Auswahl einer Authentifizierungsmethode
|  | 13.2 »Wer darf was?« innerhalb von ASP.NET entscheiden
|  |  | 13.2.1 Die IIS für formularbasierte Authentifizierung einrichten
|  |  | 13.2.2 Eine zu schützende Datei erstellen
|  |  | 13.2.3 In der Datei web.config die formularbasierte Authentifizierung einrichten
|  |  | 13.2.4 In einer weiteren web.config-Datei die Autorisierung einrichten
|  |  | 13.2.5 Die Datei mit dem Login-Formular erstellen
|  |  | 13.2.6 Die Zugangsdaten in der web.config speichern
|  |  | 13.2.7 Den authentifizierten Anwender erkennen und ein Logout ermöglichen
|  |  | 13.2.8 Passwörter in der web.config in verschlüsselter Form speichern
# Kapitel 13 »Wer darf was?« ASP.NET und Sicherheit In der realen Welt schützen verschließbare Türen alles Wertvolle und Wichtige. Wer den passenden Schlüssel hat, erhält Zugang. Mittels Authentifizierung und Autorisierung erstellen Sie in der Webentwicklung ähnliche Mechanismen. »Wer darf was?« Das ist die zentrale Frage aller Überlegungen zum Thema Sicherheit von IT-Applikationen. »Wer darf was?« fragt offenkundig nach zwei Bereichen: Die Frage nach dem Wer zielt auf die Authentifizierung. Anwender müssen sich dem System gegenüber ausweisen, identifizieren, authentifizieren. Irgendwie müssen sie nachweisen, dass sie wirklich der Administrator oder der Anwender x oder y sind. In der Regel geschieht das durch die Angabe eines Passwortes, das jeweils nur dem einzelnen Anwender bekannt ist. Die Frage nach dem Was zielt auf die Autorisierung. Durch die Authentifizierung weiß das System, dass hier der Anwender x eine Anforderung gestellt hat. Aber darf dieser Anwender wirklich diese bestimmte Datei im Verzeichnis Geschäftsführung öffnen? Vielleicht, aber vielleicht auch nicht. Im Rahmen der Autorisierung überprüft das System, ob der einzelne Anwender berechtigt ist, eine bestimmte Ressource zu nutzen. Wenn Sie Webapplikationen unter ASP.NET entwickeln, gibt es im Wesentlichen zwei unterschiedliche Strategien, die Frage »Wer darf was?« zu beantworten. Die eine Möglichkeit bildet die Option, sich möglichst weit gehend auf diejenigen Features zu verlassen, die das NTFS-Dateisystem, das Windows-Betriebssystem und die Internet Information Services von Haus aus mitbringen. Diese Perspektive bietet sich an, wenn Sie beispielsweise das Intranet eines Unternehmens administrieren und einzelne Mitarbeiter des Unternehmens zusätzlich die Möglichkeit bekommen sollen, über den Browser auf Dateien zuzugreifen. Bei diesem Szenario müssen Sie fast überhaupt keinen ASP.NET-spezifischen Code schreiben. Für die Authentifizierung verwenden Sie die Windows-eigenen Benutzerkonten und bei der Autorisierung verlassen Sie sich auf die ACL (Access-Control-Listen) des NTFS-Dateisystems. Ach ja: Die Verwendung von NTFS als Dateisystem ist bei diesem Szenario eine unerlässliche Voraussetzung. Diese Methode bietet sich an, wenn die Windows-Benutzerkonten bereits existieren und die entsprechenden Zugriffsrechte bereits gesetzt sind. Die zweite Methode besteht darin, die beiden Bereiche Authentifizierung und Autorisierung unter ASP.NET komplett neu zu erstellen. Wenn die Anwender der Webanwendung in der Regel nicht über Windows-Benutzerkonten verfügen und dementsprechend auch keine Rechte auf Dateisystemebene vergeben sind, dann bietet sich diese zweite Strategie an. Die beiden Wege schließen sich nicht unbedingt gegenseitig aus. In einigen Bereichen kann man Merkmale der einen Methode mit Möglichkeiten der anderen Methode mischen. Mehr dazu erfahren Sie auf den folgenden Seiten. ## 13.1 »Wer darf was?« mit Windows-Bordmitteln entscheiden Dieser Abschnitt erläutert die Strategie, sich bei der Sicherheitspolitik möglichst weit gehend auf Windows-Features zu stützen. Am Anfang steht die Authentifizierung. Sich bei der Authentifizierung auf Windows zu stützen bedeutet, dass jeder Anwender über ein Windows-Zugangskonto verfügen muss. Der Anwender kann sich dann quasi über den Internet Explorer einloggen, so wie er es sonst nach dem Einschalten seines PCs macht. Für die Windows-Authentifizierung gibt es drei Varianten:
| die Standardauthentifizierung,
| die Digestauthentifizierung und
| die integrierte Windows-Authentifizierung.
### 13.1.1 Windows, Standardauthentifizierung Die einfachste Variante nennt sich Standardauthentifizierung. Bei dieser Variante werden Anwendername und Passwort unverschlüsselt über das Netzwerk übertragen, so dass sich nur geringe Sicherheitsanforderungen erfüllen lassen. Der Vorteil dieser Methode besteht darin, dass sie nur geringe Anforderungen an den Browser stellt. So gut wie jeder Browser kommt mit dieser Methode klar. Um die Sicherheit zu erhöhen, kann außerdem die Kommunikation SSL-verschlüsselt werden. ### 13.1.2 Windows, Digestauthentifizierung Bei der Digestauthentifizierung wird das Passwort verschlüsselt, bevor es über das Netzwerk übertragen wird. Das klingt gut, aber leider erfordert die Methode zahlreiche Voraussetzungen sowohl auf der Seite des Browsers als auch auf der Seite des Servers. Die Digestauthentifizierung steht nur zur Verfügung, wenn Sie an eine Domäne angeschlossen sind. Die Anwender müssen über ein Benutzerkonto in einem Active Directory verfügen. Das Passwort der Anwender muss außerdem mit Hilfe einer umkehrbaren Verschlüsselung gespeichert werden, was bei Optionen zum Benutzerkonto eingestellt werden kann. Der Anwender muss für die Digestauthentifizierung außerdem auf jeden Fall einen Internet Explorer ab Version 5.x verwenden. Die Digestauthentifizierung steht auf der Seite des Servers erst ab Windows 2000 zur Verfügung. ### 13.1.3 Integrierte Windows-Authentifizierung Im Unterschied zu den beiden anderen Methoden der Windows-Authentifizierung erscheint bei der integrierten Windows-Authentifizierung kein Dialogfeld zur Eingabe von Anwendername und Passwort. Statt dessen kommunizieren Browser und Server in verschlüsselter Form miteinander, wobei das Passwort selbst nicht übertragen wird. Dabei werden der Anwendername und das Passwort verwendet, mit dem sich der Anwender ohnehin bereits am PC angemeldet hat. Für den Anwender ist das also ein sehr bequemer Weg. Die Tatsache, dass im Hintergrund eine Authentifizierung stattfindet, bleibt ihm dabei völlig verborgen. Diese Methode funktioniert nur dann, wenn der Anwender einen Internet Explorer unter einem Windows-Betriebssystem verwendet. ### 13.1.4 Beispiel für die Verwendung der Windows-Standardauthentifizierung Folgendes Beispiel soll durchgespielt werden. Unterhalb des Anwendungsverzeichnisses ASPdotNETBuch befindet sich ein Verzeichnis projekt73. Die Inhalte dieses Verzeichnisses sollen nur Besuchern zugänglich gemacht haben, die sich authentifiziert haben. Dabei soll es zunächst noch keine Rolle spielen, wer sich authentifiziert hat. Zugang sollen nur solche Benutzer erhalten, die überhaupt über ein Windows-Benutzerkonto verfügen. Das wird mit Hilfe der Standardauthentifizierung überprüft. Die Auswahl dieser Methode ist hier rein praktisch begründet. Die Digest-Methode steht wegen der zahlreichen Voraussetzungen nicht so leicht zur Verfügung und bei der integrierten Windows-Authentifizierung fällt das Testen schwerer, weil man sich jeweils erst komplett ausloggen und neu in Windows anmelden muss. So gehen Sie vor: Erstellen Sie zunächst das Verzeichnis projekt73 unterhalb des Anwendungsverzeichnisses ASPdotNETBuch. In dieses Verzeichnis legen Sie eine einfache aspx-Datei, anhand derer Sie einen Test durchführen können, z. B. die Datei projektinfo.aspx:
    <!-- projektinfo.aspx -->
    <%@ Page Language="VB" Debug="True" Strict="True" %>
    <html><head><title>Projektinfo</title></head>
    <body><h3>Vertrauliche Projektinformationen</h3>
    <p>Diese Informationen sind nur für
    Mitarbeiter des Unternehmens und nicht für die Öffentlichkeit bestimmt ...</p>
    </body></html>
Im Stammverzeichnis der Webapplikation ASPdotNETBuch erstellen Sie eine web.config-Datei mit diesem Inhalt:
    <configuration>
       <system.web>
          <authentication mode="Windows">
          </authentication>
       </system.web>
    </configuration>
Auf diese Weise verwenden Sie für die Authentifizierung die Windows-Methode. Andere gültige Werte für das Attribut mode sind Forms, Passport und None.
Achtung Den authentication-Eintrag kann eine web.config-Datei nur im Stammverzeichnis einer Webanwendung enthalten.
Welche der drei unterschiedlichen Windows-Authentifizierungsmethoden zum Einsatz kommt, stellen Sie bei den IIS direkt ein. Das Verzeichnis projekt73 möchten Sie über die Standardauthentifizierung zugänglich machen. So geht's: Öffnen Sie die Management-Konsole für die Internet-Informationsdienste: Start • Einstellungen • Systemsteuerung • Verwaltung • Internetdienste-Manager. Erweitern Sie die Anzeige der Standardwebsite und anschließend den Zweig von ASPdotNETBuch. Überprüfen Sie zunächst, ob ein anonymer Zugang zur Anwendung ASPdotNETBuch möglich ist. Klicken Sie mit der rechten Maustaste den Eintrag ASPdotNETBuch an und wählen Sie Eigenschaften. Im Dialogfeld Eigenschaften von ASPdotNETBuch wählen Sie die Registerkarte Verzeichnissicherheit und klicken im Bereich Steuerung des anonymen Zugriffs und der Authentifizierung die Schaltfläche Bearbeiten ... an. Im Dialogfeld Authentifizierungsmethoden muss die Option Anonyme Anmeldung selektiert sein. Die übrigen Optionen sollen nicht ausgewählt sein. Abbildung 13.1 zeigt die gewählten Dialogfelder. Klicken Sie zweimal OK an. Hier klicken, um das Bild zu Vergrößern Abbildung 13.1 Die IIS bieten drei verschiedene Authentifizierungsmethoden, die Sie bei den Eigenschaften auswählen. Auf dem gleichen Weg stellen Sie für das Verzeichnis projekt73, das sich unterhalb des Anwendungsverzeichnisses ASPdotNETBuch befindet, die Option Standardauthentifizierung ein. Bei der Wahl dieser Einstellung erhalten Sie eine Warnmeldung, die Sie durch die Wahl von Ja bestätigen (siehe Abbildung 13.2). Deaktivieren Sie alle anderen Optionen im Dialogfeld Authentifizierungsmethoden. Hier klicken, um das Bild zu Vergrößern Abbildung 13.2 Die Standardauthentifizierung versendet das Passwort im Klartext, wenn die Kommunikation nicht mit HTTPS verschlüsselt wird. Jetzt können Sie einen Test durchführen. Wählen Sie im Browser zunächst eine aspx-Datei aus der Anwendung ASPdotNETBuch, die nicht im Verzeichnis projekt73 liegt. Die Seite wird ohne Authentifizierung angezeigt. Geben Sie im Browser jetzt den URL zur Seite projektinfo.aspx im Verzeichnis projekt73 ein. Anschließend erscheint das Dialogfeld Netzwerkkennwort eingeben. Geben Sie hier einen gültigen Namen und das Passwort ein (siehe Abbildung 13.3). Anschließend wird die Seite aus dem geschützten Bereich angezeigt. Wenn Name und Passwort ungültig sind, wird das Fenster Netzwerkkennwort eingeben erneut eingeblendet. Nach dem dritten gescheiterten Versuch erscheint die Fehlermeldung Sie sind nicht berechtigt, diese Seite anzuzeigen, und es ist keine weitere Eingabe der Zugangsdaten möglich. Hier klicken, um das Bild zu Vergrößern Abbildung 13.3 Beim Zugriff auf Dateien, für die eine Authentifizierung erforderlich ist, erscheint dieses Dialogfeld.
Tipp Wenn Sie mehrere Tests mit den Zugangsdaten unterschiedlicher Benutzer durchführen, müssen Sie zwischendurch den Browser schließen. Die IIS erkennen am Browser, ob sich mit Hilfe dieses Browsers bereits ein Anwender eingeloggt hat, und erinnern sich daran. Ein neuer Anwender kann sich nur mit einem neuen Browser einwählen. Es reicht nicht aus, im Internet Explorer die Option Datei • Neu • Browser zu wählen. Dadurch wird lediglich ein neues Browserfenster geöffnet, das die Authentifizierungsmerkmale übernimmt. Also: Browser komplett schließen und anschließend neu öffnen. Dann können Sie sich unter einem anderen Namen neu einloggen.
Wenn Sie nicht die Standardauthentifizierung verwenden möchten, können Sie über das Dialogfeld Authentifizierungsmethoden auch die beiden anderen Authentifizierungsmethoden (Digest und integriert) einstellen, die Windows anbietet. Als Nächstes soll das Beispiel so erweitert werden, dass nur bestimmte Anwender die Seiten aus dem Verzeichnis projekt73 einsehen können. ### 13.1.5 Dateibasierte Autorisierung über ACL verwenden Es gibt zwei unterschiedliche Methoden für die Autorisierung:
| dateibasiert und
| URL-basiert.
Bei der dateibasierten Autorisierung verwenden Sie die Zugriffsrechte, die Sie über die Dateieigenschaften setzen können. Das ist die Strategie, die Sicherheit mit Windows-Bordmitteln zu erreichen. Bei der URL-basierten Autorisierung vergeben Sie die Berechtigungen innerhalb der web.config-Datei. Das ist die Strategie für selbst erstellte Sicherheits-Lösungen. Hier interessiert zunächst nur die dateibasierte Autorisierung. Die dateibasierte Autorisierung können Sie einsetzen, wenn alle Anwender über ein Windows-Konto verfügen. Die dateibasierte Autorisierung wird oft in Kombination mit der Windows-Authentifizierung eingesetzt. Der Vorteil der Verwendung der dateibasierten Autorisierung besteht darin, dass Sie die Zugriffsrechte nur an einer Stelle, nämlich im Dateisystem, festlegen müssen. Anschließend spielt es für die Autorisierung keine Rolle mehr, ob sich ein Anwender lokal an einem PC anmeldet oder ob er über einen Browser den Zugang erhält. Da das System den Anwender identifiziert hat, weiß es, welche Rechte dieser Anwender hat. Das Dateisystem NTFS, das unter Windows NT, Windows 2000 und Windows XP zur Verfügung steht, verwaltet die Zugriffsrechte auf Verzeichnisse und Dateien mit Hilfe der NTFS-Access-Control-Listen (ACL). Die Zugriffsrechte für ein einzelnes Objekt stellen Sie ein, indem Sie im Explorer mit der rechten Maustaste auf das Objekt klicken, Eigenschaften und die Registerkarte Sicherheitseinstellungen selektieren. Abbildung 13.4 zeigt die Einstellungen beispielhaft für das Verzeichnis projekt73. Hier klicken, um das Bild zu Vergrößern Abbildung 13.4 NTFS verwaltet die Zugriffsrechte mit Hilfe der Access-Control-Listen, die Sie über das Eigenschaftenfenster erreichen. Den Zugriff auf das Verzeichnis projekt73 möchten Sie beispielsweise nur denjenigen Anwendern gestatten, die Mitglied der Gruppe Projekt73 sind. Zunächst stellen Sie über die Verwaltung der Benutzer und Gruppen sicher, dass Sie über eine entsprechende Gruppe mit zugehörigen Anwendern verfügen: Start • Einstellungen • Systemsteuerung • Verwaltung • Computerverwaltung. Im Zweig System finden Sie den Eintrag Lokale Benutzer und Gruppen. Hier können Sie Benutzer und Gruppen hinzufügen. Erstellen Sie testweise drei neue Benutzer und eine Gruppe Projekt73. Zwei davon weisen Sie der neu erstellten Gruppe zu. Diese Gruppe darf auf das Verzeichnis projekt73 zugreifen. Der dritte Benutzer soll keinen Zugang erhalten. Abbildung 13.5 zeigt die Eigenschaften der Gruppe Projekt73. Ihr sind die beiden Mitarbeiter UlrichP und WernerM zugeordnet. Hier klicken, um das Bild zu Vergrößern Abbildung 13.5 Die Einrichtung von Benutzergruppen erleichtert die Verwaltung der Zugriffsrechte. So schränken Sie den Zugriff auf das Verzeichnis projekt73 auf die Mitglieder der Gruppe Projekt73 ein: Klicken Sie im Explorer mit der rechten Maustaste das Verzeichnis projekt73 an. Wählen Sie Eigenschaften und selektieren Sie die Registerkarte Sicherheitseinstellungen. Da nicht mehr jeder auf diese Ressource zugreifen können soll, müssen Sie aus der Liste Name den Eintrag Jeder entfernen. Dazu müssen Sie zunächst das Kontrollkästchen Vererbbare übergeordnete Berechtigungen übernehmen deaktivieren. Anschließend erscheint ein Informationshinweis zu den Sicherheitseinstellungen. Wählen Sie hier die Schaltfläche Entfernen. Anschließend ist der Eintrag Jeder aus der Liste gelöscht. Hier klicken, um das Bild zu Vergrößern Abbildung 13.6 Die vererbbaren Berechtigungen Fügen Sie anschließend zwei Konten hinzu: Projekt73 enthält die Namen der Anwender mit Zugangsberechtigung. Das Konto ASPNET muss ebenfalls eine Zugangsberechtigung haben, damit ASP.NET selbst zugreifen kann. Ein erneuter Test funktioniert wie erwartet. Anwender, die zur Gruppe Projekt73 gehören, können die Seite anzeigen. Alle anderen Anwender werden abgewiesen. ### 13.1.6 Kriterien für die Auswahl einer Authentifizierungsmethode Die Entscheidung für oder gegen eine bestimmte Authentifizierungsmethode hängt davon ab, welche Voraussetzungen die Anwendung erfüllen muss. Tabelle 13.1 listet die diversen Kriterien in tabellarischer Form auf.
Authentifizierungs-methode | Arbeitsweise | Voraussetzungen für den Browser | Voraussetzungen auf dem Server | Höhe der gebotenen Sicherheit | Typisches Einsatzszenario
--- | --- | --- | --- | --- | ---
Windows, Standard, | Anwendername und Passwort werden in einem Formular abgefragt und im Klartext übertragen. | Mit fast allen Browsern kompatibel | Der Anwender benötigt ein Benutzerkonto auf dem Domänenserver. | Gering. Bei zusätzlicher Verwendung von HTTPS hoch | Internetapplikation mit geringen Sicherheitsanforderungen. Bei Verwendung von HTTPS auch für hohe Sicherheitsanforderungen geeignet
Windows, Digest | Anwendername und Passwort werden vom Anwender abgefragt und vor der Übertragung vom Browser verschlüsselt. | Nur Internet Explorer ab Version 5.x | Erst ab Windows 2000. Benutzerkonto im Active Directory erforderlich. Das Passwort muss mit der Option »umkehrbare Verschlüsselung« gespeichert werden. | mittel | Intranetlösungen
Windows, Integriert (NTLM/Kerberos) | Anwendername und Passwort, mit denen der Anwender sich bei Windows angemeldet hat, werden automatisch verschlüsselt überprüft. Keine erneute Eingabe erforderlich | Ab Internet Explorer 3.01 | Benutzerkonto auf dem Domänenserver nötig | hoch | Intranetlösungen
Formularbasiert | Anwendername und Passwort werden in einem Formular abgefragt und im Klartext übertragen. | Keine besonderen Voraussetzungen | Keine besonderen Voraussetzungen | Gering. Bei zusätzlicher Verwendung von HTTPS hoch | Internetapplikation mit geringen Sicherheitsanforderungen. Bei Verwendung von HTTPS auch für hohe Sicherheitsanforderungen geeignet
Tabelle 13.1 Kriterien für die Auswahl einer Authentifizierungsmethode
<< zurück | <top> | vor >>
Zum Katalog
Einstieg in ASP.NET bestellen
Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen? Ihre Meinung

.NET-Bibliothek
| Einstieg in VB.NET
| VB.NET
| Einstieg in C#
| Visual C#
| VB.NET und Datenbanken

Empfehlung
| Einstieg in XML

Shopping
Versandkostenfrei bestellen in Deutschland und Österreich Info

MyGalileo
Der Service für registrierte Leser: Info

Copyright © Galileo Press GmbH 2003
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

[Galileo Computing]
Galileo Press GmbH, Gartenstraße 24, 53229 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de