htaccess: Passwortschutz und Zugangsbeschränkung für Webseiten

Der Apache HTTP Server 2.4 erlaubt die Einrichtung von Authentifizierungs- und Autorisierungs-Verfahren für verschiedene Anwendungsfälle – von der Einschränkung des Zugangs nach bestimmten Kriterien bis hin zum Passwortschutz für ganze Websites, einzelne Seiten oder spezifische Inhalte. In diesem Blogartikel lesen Sie, wie Sie mit Hilfe von .htaccess-Dateien Ihre eigenen Zugriffsregeln für sensible Website-Bereiche festlegen können. (Einführende Infos zu .htaccess-Dateien finden Sie in diesem Beitrag.) 

Webseiten-Zugang beschränken mit Require 

In vielen Fällen kann auf ein aufwendiges passwortbasiertes Authentifizierungs- und Autorisierungsverfahren bei der Einrichtung einer Zugangskontrolle verzichtet werden. Im einfachsten Fall kann Apache (mit Hilfe der Basismodule mod_authz.core und mod_authz_host) Besuchern bereits in Abhängigkeit von Client-Domains, IP-Adressen oder genutzten HTTP-Request-Methoden den Zugang erlauben oder verwehren. Dazu nutzen Sie in der .htaccess-Datei des zu schützenden Verzeichnisses die Direktive Require, ggf. in Verbindung mit einer der Container-Direktiven RequireAll, RequireAny oder RequireNone. (Require ersetzt die mittlerweile veralteten Direktiven Allow, Deny, Order und Satisfy des Moduls mod_access_compat aus Apache 2.2, mit dem die Abwärtskompatibilität zu älteren Versionen gewährleistet werden sollte.) 

Soll beispielsweise der Zugriff auf die IP-Adresse 10.123.45.234 beschränkt werden, erreichen Sie das mit folgendem .htaccess-Eintrag: 

Require ip 10.123.45.234

Dabei können mehrere IP-Adressen durch Leerzeichen getrennt eingegeben werden. Auch umgekehrt – um Besucher auszusperren – lässt sich die Require-Direktive einsetzen: 

Require all granted 

Require not ip 10.123.45.234 

Schon wird der Besucher mit der IP-Adresse 10.123.45.234 – und nur dieser – den beschränkten Bereich nicht mehr betreten können.  
Achtung: Stellen Sie bei der Anwendung von Require not darauf stets ein Require all granted voran. So gewährleisten Sie, dass allen übrigen Besuchern der Zugang gewährt wird. 

Soll die Beschränkung nur für bestimmte Inhalte oder Zugriffsmethoden gelten, können Sie mit den Container-Direktiven Files, FilesMatch, Limit und LimitExcept dafür sorgen, dass die Require-Anweisungen entsprechend selektiv angewendet werden: 

# Nur das Video beispiel.mp4 wird geschützt: 

<Files beispiel.mp4> 
 Require 192.168.1 10.1.2.3 
</Files> 

# Nur HTTP-Zugriffsmethoden Post, Put und Delete werden geschützt: 

<Limit POST PUT DELETE> 
Require valid-user 
</Limit> 

Erweiterte Zugangsbeschränkung durch Passwortschutz 

Wie das letzte Beispiel schon andeutet, ist es auch möglich, den Zugriff zum Beispiel abhängig von Benutzernamen (mod_authz_user) oder Benutzergruppen (mod_authz_groupfile) zu beschränken. Damit erlauben Sie den Zugang zu sensitiven Bereichen nur einem festgelegten Kreis von Personen, die sich mittels Benutzernamen und Passwort identifizieren müssen. 

Die Informationen dafür holt sich Apache von einem „Authentifizierungsprovider“, der in der .htaccess-Datei angegeben werden muss. Sie spezifizieren dafür zunächst Authentifizierungstyp (AuthType, in der Regel „Basic“), Bereichsname (AuthName, der Titel des Login-Fensters) und Art des Providers (AuthBasicProvider): 

# Passwortschutz 

AuthType Basic 
AuthName "Geschützter Bereich" 
AuthBasicProvider file 
AuthUserFile /path-outside-protected-directory/.htpasswd 
Require valid-user 

Neben reinen Textdateien wie im Beispiel (file, das ist der Default) können auch Datenbankinhalte, LDAP-Verzeichnisse oder ein Cache als AuthBasicProvider fungieren. Die unter AuthUserFile angegebene Textdatei enthält die Nutzernamen und die verschlüsselten Hashes der Passwörter aller zugangsberechtigten Personen, jeweils getrennt durch Doppelpunkt:  

# Passwort-Datei 

hansmustermann:$apr1$v0er3naw$m6rptM7s4UluxaADaRjB01 
klaramusterfrau: $apr1$pgkx36cs$uRDauIah5V2Wt/FomBSI9. 

ie erstellen diese Datei manuell mit einem regulären Text-Editor und dem Verschlüsselungstool Ihrer Wahl (z. B. diesem) oder unter Zuhilfenahme des Apache-Hilfsprogramms htpasswd. Apache  unterstützt für Passwörter die Verschlüsselungsformate Bcrypt, MD5, SHA1 und CRYPT. Davon können aber nur bcrypt und mit Abstrichen MD5 als sicher gelten. 

Um den Zugriffsschutz scharf zu schalten, muss die Require-Direktive noch entsprechend angepasst werden. Sie kann die Benutzernamen einer oder mehrerer berechtigter Personen aus der Passwortdatei aufzählen, oder, wenn die Liste zu lang wird, mit „valid-user“ allen registrierten Nutzern den Zugriff gestatten. 

Zugang für Benutzergruppen 

Möchten Sie mit Benutzergruppen arbeiten, erstellen Sie zwei Textdateien, nämlich zusätzlich zur Benutzerdatei noch eine Datei mit den Gruppenzuordnungen (in der Form „Gruppe: user1 user2 user 3“). So geben Sie die Pfade zu beiden Dateien an und beschränken den Zugang auf Mitglieder der Gruppe admin: 

# Passwortschutz mit Benutzergruppen  

AuthType Basic 
AuthName "Geschützter Bereich" 
AuthBasicProvider file 
AuthUserFile /path-outside-protected-directory/.htusers 
AuthGroupFile /path-outside-protected-directory/.htgroups 
Require group admin 

Passwortsicherheit 

Passwortdateien sollten stets außerhalb des geschützten Bereiches in einem nicht öffentlich zugänglichen Verzeichnis gespeichert sein. Sie können auch eine zentrale Passwortdatei mit mehreren htaccess-Dateien verwenden. Übrigens: Ein Punkt vor dem Dateinamen versteckt sensible Dateien vor neugierigen Usern ohne entsprechende Rechte. 

Für AuthType stehen die Einstellungen Basic, Digest und Form zur Auswahl. Digest bietet eine höhere Sicherheit bei der Übertragung des Passworts vom Client zum Server, wird aber nicht von allen Browsern komplett unterstützt. Auch ist die Passwortspeicherung auf dem Server mit Basic sicherer, weil Digest starke Passwort-Hashes wie bcrypt nicht zulässt. Ein guter Kompromiss ist Basic in Kombination mit HTTPS. Die dritte Variante, Form, erlaubt die Verwendung von benutzerfreundlichen HTML-Formularen. Sie ist aber aufwendiger zu konfigurieren und kann Angriffsflächen für Cross-Site-Scripting bieten. 

Hinweis: Wenn Sie Ihren Benutzern bei der Wahl eines wirklich sicheren Passworts helfen möchten, sollten Sie unseren Beitrag zur Passwortsicherheit [Link Neue Regeln für sichere Passwörter] lesen. 

Passwort-Datenbanken 

Wie schon erwähnt, können Sie Benutzer und Passwörter auch aus einer Datenbank abrufen. Das Durchsuchen umfangreicher Textdateien ist rechenintensiv; mit wachsender Zahl der registrierten Besucher verlangsamt eine einfache Text-Datei deshalb spürbar die Reaktionszeiten.  

Abhilfe schaffen kann hier der Einsatz einer DBM-Datei oder der Abruf  aus einer SQL-Datenbank. Zur Erstellung und Verwaltung einer DBM-Datenbank-Datei stellt Apache seinen Nutzern die Hilfsprogramme dbmmanage und htdbm zur Verfügung. 

Sollte es bei der SQL-Datenbank-Nutzung zu Performance-Problemen kommen, etwa bei umfangreichen HTML-Seiten mit Hunderten von Objekten, können Anmeldedaten auch gecacht werden, um die Datenbank zu entlasten. Der Client muss dann nicht bei jeder Anfrage eines geschützten Bereichs, für den er bereits authentifiziert wurde, erneut Nutzername und Passwort an den Server senden.  

Wie Sie sehen, können bei Apache auch mehrere Authentifizierungsverfahren kombiniert zum Einsatz kommen, etwa file, dbd und socache. Die gewünschten Verfahren müssen hierzu lediglich in der richtigen Reihenfolge in der Direktive AuthBasicProvider – durch Leerzeichen getrennt – angegeben werden. Apache arbeitet sie nacheinander ab, bis ein Match für den anfragenden Benutzernamen gefunden wird.  

:idea: Ein letzter Hinweis: Die hier vorgestellten Passwortverfahren sind zwar deutlich sicherer als solche mit CGI-Scripts oder JavaScript. Aber auch sie sind nicht unproblematisch. So fehlt der HTTP-Authentifizierung eine standardisierte Methode zum Ausloggen. Zugangsdaten werden vom Browser bis zum Ende einer Sitzung und häufig sogar dauerhaft gespeichert, was Dritten Missbrauchsmöglichkeiten eröffnet. Ziehen Sie daher bei hochsensiblen Daten den Einsatz eines Login/Logout-Systems oder einer Benutzerverwaltung (wie sie jedes gängige CMS bietet) in Erwägung.