Webserver/htaccess/Zugriffskontrolle

Aus SELFHTML-Wiki
< Webserver‎ | htaccess(Weitergeleitet von Passwortschutz)
Wechseln zu: Navigation, Suche

Text-Info

Lesedauer
30min
Schwierigkeitsgrad
mittel
Vorausgesetztes Wissen
Grundkenntnisse in
Webserver


Mit einer .htaccess-Datei können Sie u. a. eine benutzerdefinierte Zugriffskontrolle für den Directory-Zweig ab der Position der Datei erreichen. Eine der häufigsten Verwendungen ist die Einrichtung eines Passwortschutzes, sodass bestimmte Seiten oder Inhalte nur nach Eingabe eines Passworts aufgerufen werden können und für andere Nutzer und auch für Suchmaschinen verborgen bleiben.

Dies können im Aufbau befindliche, noch nicht vorzeigbare Seiten oder interne Mitgliederbereiche wie ein Vertretungsplan nur für das Lehrerkollegium sein. Außerdem können z. B. MIME-Types zugewiesen werden, u. v. m.

Für die Funktion muss der Webserver nicht neu gestartet werden. Die Konfigurationsangaben werden bei jedem Zugriff auf den Pfad verarbeitet. Dauerhafte und/oder allgemeingültige Regelungen sollten daher nicht in einer .htaccess-Datei geregelt werden, sondern in der (Virt)Host-Konfiguration der Domain.

Verzeichnisse und Dateien mit Passwort schützen[Bearbeiten]

Speichern Sie in dem Verzeichnis, das Sie schützen wollen, eine .htaccess-Datei.

.htaccess-Datei für Passwortschutz
# .htaccess-Datei für Passwortschutz
AuthType Basic
AuthName "Geschützter Bereich - Bitte geben Sie ein Passwort ein!"
AuthUserFile /Individueller/Pfad/.htpasswd
Require valid-user

Um einen Passwortschutz einzurichten, brauchen Sie die Anweisungen AuthType, AuthName, AuthUserFile, und wenn Sie mit Benutzergruppen arbeiten, auch AuthGroupFile. Ferner benötigen Sie, wenn Sie den Zugriff auf bestimmte Benutzer oder Gruppen aus diesen Dateien festlegen (also einschränken) wollen, eine oder mehrere Angaben der Anweisung Require.

  • AuthType bezeichnet die Art der Authentifizierung.
    • Basic: sogenannte HTTP Basic Authentication (einfache Authentifizierung über HTTP). Dabei stehen die Benutzernamen und die zugehörigen Passwörter in einer noch anzugebenden Datei. Diese Methode verlangt aber, dass das Passwort unverschlüsselt vom Browser an den Webserver übermittelt wird. Sie ist daher nicht wirklich sicher.
    • Digest: Dabei werden Passwörter bereits in verschlüsselter Form abgefordert, allerdings beherrschen das nicht alle Browser. Sie müssen daher entscheiden, was für Sie Vorrang hat: höhere Sicherheit oder die Berücksichtigung der Browser und Clients, die nur die einfache Authentifizierung unterstützen.
  • AuthUserFile: gibt die Datei an, in der die Namen der autorisierten Benutzer und ihre Passwörter stehen. Es sollte der vollständige absolute Pfadname angegeben werden.
  • Require: Legt mit einem zweiten Schlüsselwort fest, für welche Benutzer, bzw. Benutzergruppen das Passwort gelten soll. Hinter diesem Schlüsselwort können ein oder mehrere Namen von Benutzern oder Benutzergruppen folgen. Alternativ können Sie auch das Schlüsselwort valid-user benutzen, um alle Benutzer zuzulassen, falls die Liste sonst zu lang werden würde.
    • user: gefolgt von einer Liste der Benutzer
    • group: gefolgt vom Namen der Gruppe

.htpasswd Datei erstellen[Bearbeiten]

Damit der Verzeichnisschutz mit Passwort funktioniert, genügt die .htaccess-Datei alleine allerdings nicht. Sie brauchen zusätzlich eine Text-Datei, in der (der Benutzername und) das zugehörige Passwort steht.

.htpasswd-Datei
# Passwort-Datei
name:$2y$05$MQ7RdCCRrKmBEDD/u4pks.9qAV8RCKy4YCP2pzgmc4lppfli41zC

Achtung!

Theoretisch können Sie Passwörter im Klartext notieren. Da sie so aber auch von Fremden ausgelesen werden können, sollten Sie sie immer verschlüsseln. Dabei sollten Sie folgendes berücksichtigen:
  • Verzichten Sie dabei auf die veraltete MD5-Verschlüsselung.
  • Benutzernamen dürfen nicht länger als 255 Bytes sein und weder den Punkt noch den Doppelpunkt als Zeichen enthalten.
  • Da der Apache Webserver Kommentare in den Passwortdateien unterstützt, ist es - obwohl mit htpasswd möglich - keine gute Idee, das Raute-Zeichen ("#") im Benutzernamen zu verwenden. Der Benutzer kann sich dann ganz einfach nicht anmelden.
  • Unter Windows werden Passwörter, die länger als 255 Bytes sind auf 255 Bytes gekürzt. Beachten Sie, dass deutsche Umlaute unter UTF-8 zwei Bytes benötigen.

Wenn nicht ausdrücklich vom Provider bzw. Webmaster anders bestimmt, sollten Sie außerdem für die Datei einen Namen wählen, der mit .ht beginnt, üblicherweise eben .htusers oder .htpasswd. In der Konfiguration des Apache-Servers sind solche Dateinamen als Grundeinstellung vorgegeben und werden, wie oben bereits erläutert, aufgrund des vorangestellten Punktes nicht zur Ansicht freigegeben, bleiben also vor Besuchern verborgen.

Zusammen mit dem Apache wird ein kleines Hilfsprogramm ausgeliefert, das die Erstellung solcher Passwortdateien vereinfacht. Es heißt htpasswd (unter Windows: htpasswd.exe) und ist über die Konsole (Eingabeaufforderung) zu bedienen. Rufen Sie es einfach mit dem Befehl htpasswd -h auf, um eine kurze Hilfe zu seiner Verwendung zu erhalten. Im einfachsten Fall geben Sie zum Beispiel

htpasswd -c .htusers smuenz 

oder, falls Sie einen Apache 2.4 oder neuer haben, sehr viel besser:

htpasswd -c -B .htusers smuenz

ein. Sie müssen für den neuen Benutzer smuenz ein Passwort angeben und bestätigen. Diese Passwortdatei können Sie dann in das vorgesehene Verzeichnis verschieben oder hochladen.

Bitte beachten Sie hinsichtlich der Option "-c": Es wird eine neue Passwortdatei angelegt! Wenn Sie das nicht wollen, weil das bestehende Einträge löscht, dann lassen Sie das "-c" weg, die Einträge werden dann angehängt oder ersetzt.)

Beispiel: Passwortschutz für mehrere Benutzer[Bearbeiten]

Sie können wahlweise das ganze Verzeichnis mit all seinen Unterverzeichnissen oder nur bestimmte Dateien oder Dateitypen schützen. Sie können den Passwortschutz außerdem wahlweise für einzelne Benutzer oder für ganze Benutzergruppen einrichten. Auch Kombinationen beider Formen sind möglich. Außerdem ist es auch möglich, den "oben" eingrichteten Schutz (egal welcher Art: Passwort, Dateityp, IP, ...) weiter unten im Verzeichnisbaum wieder aufzuheben. Und nicht vergessen: Verzeichnisbäume stehen in der Darstellung immer auf dem Kopf ;-)


.htaccess-Datei[Bearbeiten]

.htaccess-Datei für mehrere Benutzer
# .htaccess-Datei für Web-Verzeichnis /service
AuthType Basic
AuthName "Service-Bereich"
AuthUserFile /usr/verwaltung/web/.htusers
AuthGroupFile /usr/verwaltung/web/.htgroups
Require user  Werner Dieter Heidi
Require group Servicetechniker

Damit der Verzeichnisschutz mit Passwort funktioniert, genügt die .htaccess-Datei alleine allerdings nicht. Sie brauchen zusätzlich eine Datei, in der die Benutzernamen und die zugehörigen Passwörter stehen. Falls Sie mit Benutzergruppen arbeiten, benötigen Sie außerdem noch eine Datei, in der die Benutzergruppen definiert werden.

Benutzerdatei[Bearbeiten]

Im obigen Beispiel werden die drei Benutzer Werner, Dieter, Heidi sowie alle Benutzer der Gruppe Servicetechniker angegeben. Damit der Passwortschutz funktioniert, müssen nun die angegebenen Dateien mit den Benutzernamen und (falls benötigt) den Gruppen angelegt werden:

.htusers-Datei
# BenutzerDatei für Web-Projekt
Werner:$2y$05$MQ7RdCCRrKmBEDD/u4pks.9qAV8RCKy4YCP2pzgmc4lppfli41zC
Dieter:{SHA}i8xKRW2XJbkGN4UbpkXBfVjSKXs=
Heidi:$apr1$.P2k7JQX$dBcOPzzpEcQYcR0ZGw24Q0

Jede Zeile der Benutzerdatei enthält einen Benutzernamen, und gleich dahinter, durch einen Doppelpunkt getrennt, das "gehashte" (eine Art "Einwegverschlüsselung") Passwort (es wurde jeweils "hallo" verwendet).

  • Der erste Eintrag (Werner) wurde mit dem Befehl htpasswd -B .htusers Werner erzeugt (ab Apache 2.4).
  • Der zweite Eintrag (Dieter) wurde mit dem Befehl htpasswd -s .htusers Dieter erzeugt.
  • Der dritte Eintrag (Heidi) wurde – mit htpasswd .htusers Heidi erzeugt.
Beachten Sie: Die dritte (es handelt sich um den veralteten MD5-Algorithmus mit einem zusätzlichen 32-Bit-Salt) und die zweite Methode (sha1, ohne Salt) gelten beide als unsicher, wobei sha1 die schlechteste der vorgestellten Varianten ist! Wenn Sie mehr über die Hashfunktionen wissen wollen, dann lesen Sie in der Dokumentation des Apache 2.4. nach. Wenn die Passwörter durch ein PHP-Skript erzeugt werden sollen, dann sehen Sie sich die Funktion password_hash und das Manual an.

Gruppendatei[Bearbeiten]

Gruppendateien bestehen aus Einträgen, bei denen zunächst ein Gruppenname notiert wird und dahinter, nach einem Doppelpunkt, die Namen von Benutzern, die zu dieser Gruppe gehören. Es müssen Benutzernamen sein, für die in der Benutzerdatei ein Eintrag angelegt wurde.

.htgroups-Datei
# GruppenDatei für Web-Projekt
Servicetechniker: Andreas Karin Janine

Die Gruppendatei wird im Beispiel nur benötigt, weil in der .htaccess-Datei mit authGroupFile eine Benutzergruppe angegeben wurde; die Gruppendatei wird ausschließlich dann erforderlich, wenn Sie Gruppennamen benutzen. In einem Intranet ist auch eine Benutzerdatei nicht zwingend erforderlich, da Sie Zugriffserlaubnisse und -verbote über die Zulassung bzw. den Ausschluss der internen IP-Adresse regeln können.

Effekt:

Alle Besucher des Web-Projekts, die nun versuchen, auf das Verzeichnis mit der .htaccess-Datei zuzugreifen, bekommen von ihrem Browser einen Dialog angeboten, in dem sie Benutzernamen und Passwort eingeben müssen. Nur Besucher, die sich mit einer gültigen Kombination aus Benutzernamen und Passwort anmelden, haben Zugriff auf das Verzeichnis.

Beispiel: Schutz für bestimmte Dateitypen[Bearbeiten]

So wie im obigen Beispiel gezeigt, gilt der Zugangsschutz für das Verzeichnis, in dem die .htaccess-Datei liegt, und für alle Verzeichnisse unterhalb davon. Sie können den Schutz aber auch auf bestimmte Dateien, Dateitypen oder Zugriffsmethoden einschränken.

.htaccess-Datei für Web-Verzeichnis
# .htaccess-Datei für Web-Verzeichnis /service

AuthType Basic
AuthName "Service-Bereich"
AuthUserFile /usr/verwaltung/web/.htusers
AuthGroupFile /usr/verwaltung/web/.htgroups

<Files *.htm>
Require user  Werner Dieter Heidi
Require group Servicetechniker
</Files>

Um den Schutz einzuschränken, benutzen Sie ähnlich wie in HTML oder XML Tags mit spitzen Klammern. Im einleitenden Tag kann hinter der öffnenden spitzen Klammer entweder Files stehen, wie im obigen Beispiel. Dahinter können Sie genau eine einschränkende Angabe machen. Mit *.htm wie im Beispiel beschränken Sie den Schutz auf HTML-Dateien. Mit einer Angabe wie geheim.htm würde nur diese eine Datei geschützt. Anstelle von Files können Sie auch FilesMatch einsetzen. Dann sind Reguläre Ausdrücke möglich. Beispielsweise würden Sie mit <FilesMatch "\.(htm|php)$"> alle HTML-Dokumente und alle PHP-Scripts erfassen.

Eine weitere Möglichkeit besteht darin, anstelle von Files die Anweisung Limit, oder besser noch LimitExcept anzuwenden. Sie hat Auswirkungen auf HTTP-Methoden wie GET, POST, PUT, DELETE, CONNECT, OPTIONS usw. Mit <LimitExcept GET> können Sie für alle Zugriffsmethoden Bedingungen formulieren, mit Ausnahme von GET – und mit Mit <LimitExcept POST> würden Sie für alle Zugriffsmethoden mit Ausnahme von POST Zugriffsbedingungen formulieren können.

Beachten Sie: Falls es bei Ihnen einfach nicht mit dem Schützen von Verzeichnissen klappen will, dann könnte der Grund darin liegen, dass in der zentralen Konfiguration des Apache Webservers beim Eintrag AllowOverride der Wert None gewählt wurde.

Kombinierte Zugriffsschutzfilter[Bearbeiten]

Ab Apache 2.4 steht die Methode <require...> zur Verfügung mit ihren vielfältigen Möglichkeiten für Zugriffsschutz-Container.

Ein Beispiel für den kombinierten Zugriffsschutz über Username:Passwort und/oder passende Requestor-IP könnte folgendermaßen aussehen:

.htaccess-Datei für kombinierten Zugriffsschutz nebst weiterer Options
 
## .htaccess
AuthName "Bitte User und Passwort eingeben"
AuthUserFile /var/www/.htuserpasswd
AuthType Basic

<RequireAny>
    Require ip 192.168.178.
    Require ip 127.
    Require ip ::1
    Require valid-user
</RequireAny>

IndexOptions +NameWidth=80
IndexOptions +IgnoreCase
IndexOptions +FoldersFirst
IndexOptions +FancyIndexing


Hier wäre der Zugriff erlaubt aus dem LAN des Webservers (192.168.178.###), vom Host des Webservers selbst (via http/s) und für alle berechtigten Benutzer aus der Identifikationsdatei /var/www/.htuserpasswd. Weitere Anzeigeoptionen für das Verzeichnis sind möglich.

Fazit[Bearbeiten]

Schutzmechanismen, die Sie mit Hilfe von .htaccess-Dateien auf Server-Seite erstellen, sind auf HTTP-Ebene wesentlich sicherer als solche, die mit Hilfe von JavaScript, VBScript o. ä. auf Client-Seite erstellt werden. Dennoch sollten Sie beachten, dass .htaccess keinen Generalschutz bietet. Der Schutz gilt nur über das HTTP/s-Protokoll, also wenn z. B. per Web-Browser oder wget (Linux-Tool) beim HTTP-Server eine Anfrage gestellt wird.

Der Schutz gilt nicht, wenn der Zugriff mit einem anderen Protokoll, wie z. B. mit s/FTP, SSH, SMB, usw. direkt auf das Dateisystem des Hosts erfolgt. Die Umgehung des HTTP-Servers bedeutet auch die Umgehung des Schutzmechanismus.

Problematisch bei diesem HTTP-Authentication-Verfahren ist außerdem, dass es keine standardisierte Methode zum Ausloggen gibt. Der Browser speichert die erfolgreichen Zugangsdaten bis zum Ende der Sitzung und vergisst sie erst, wenn alle Browserfenster (das Programm) geschlossen wurden. Mittlerweile bieten alle gängigen Browser an, die Zugangsdaten dauerhaft zu speichern, was die Problematik mit dem Ausloggen nicht gerade vereinfacht.

Als Workaroud kann man zum "Ausloggen" eine falsche Anmeldung senden, also Username und falsches Passwort. Dies funktioniert z.B. auch per XML-HttpRequest (AJAX) und damit auch per vom Webseitengestalter vorgesehenen Button (/?logout). Hier sollte dann von der Serverseite die passend gestaltete Error-Page als Antwort kommen.

Generell wäre der Einsatz eines Token-basierten Login-Systems (Cookies) flexibler und eventuell etwas sicherer.

Beachten Sie: Die Übertragung von Credentials ("Login"-Daten) sollte immer nur über eine gesicherte Verbindung (TLS) erfolgen.


ToDo (weitere ToDos)

Artikel muss aktualisiert (und in oberen, bereits aktualisierten Teil integriert) werden.
Die Anweisungen "Allow", "Deny" und "Order", die von mod_access_compat bereitgestellt werden, sind veraltet und werden in einer zukünftigen Version verschwinden. Sie sollten es vermeiden, sie zu verwenden, und veraltete Tutorials, die ihre Verwendung empfehlen, meiden.
The Allow, Deny, and Order directives, provided by mod_access_compat, are deprecated and will go away in a future version. You should avoid using them, and avoid outdated tutorials recommending their use.[1] --Matthias Scharwies (Diskussion) 08:19, 27. Mär. 2021 (CET)


Außerdem kann der Webmaster in seiner zentralen Konfiguration detailliert festlegen, welche dieser vielen Möglichkeiten der benutzereigenen Konfigurationsdateien innerhalb welcher Verzeichnisbäume zur Verfügung stehen sollen und welche nicht. Die Anweisungssprache dieser Dateien ist identisch zur derjenigen in den zentralen Konfigurationsdateien – alles, was ein Benutzer lokal definieren kann, könnte auch der Webmaster in seiner zentralen Datei access.conf global definieren.

.htaccess
authType      basic
              # Schutzverfahren (Apache 1.2 kennt nur "basic")
authName      Web-Bereich_der_Abteilung_'Entwicklung'
              # Name des Berechtigungsbereichs)
authUserFile  /home/ms/httpzugriff/benutzer.txt
              # Datei für Benutzerbeschreibung (nicht im Dokumentbaum!)
authGroupFile /home/ms/httpzugriff/gruppen.txt
              # Datei für Gruppenbeschreibung  (nicht im Dokumentbaum!)
order         deny,allow
              # Genehmigungen überstimmen Verbote ...
deny from     all
              # ... aber erst einmal alles verbieten
satisfy       all
              # nur Rechneradresse PLUS Benutzerkennung berechtigen zum Zugriff!
allow from    153.46.90.
              # nur Rechner dieses IP-Adressenbereichs dürfen zugreifen
require group entwickler
              # alle Entwickler dürfen zugreifen
require user  chef sekretaer
              # Firmenchef und Sekretärin dürfen auch zugreifen


benutzer.txt
# (Demo: jeweils Passwort = Benutzerkennung, crypt()-salt = "IN")
chef:IN3WY1lATStaY
sekretae:INz8B568yvs7Y
schmidt:INQaGJBu4yljQ
meier:INqq3xgT4zpp6
huber:INT.EAmojNwN6
test:INnA1BztLIaac
gruppen.txt
# Liste aller Mitglieder der definierten Gruppen
entwickler:   meier huber schmidt

Den Zugriff auf Dokumente eines Verzeichnisses kann dessen Besitzer zunächst einmal auf Hostnamen, IP-Adressen und Präfixe dieser beiden (also IP-Netzmasken und Domains!) beschränken. Das ist ganz praktisch in einem großen Firmennetz mit mehreren Teilnetzen bzw. Subdomains, wo man Filialen, Abteilungen usw. einfach dadurch voneinander abgrenzen kann, indem man sich auf eine bestehende Netzstruktur bezieht.

Insbesondere müssen sich Besucher, die auf bestimmte Seiten zugreifen dürfen, dazu nicht explizit ausweisen – und merken ggf. gar nicht, dass diese Seiten für andere Besucher gesperrt sind.

Will man weitergehende Kontrollen verwenden, bei denen der Besucher sich beim ersten Zugriff seiner Browser-Sitzung (danach merkt sich der Webserver das Ergebnis) explizit ausweisen muss, definiert man zunächst einmal einen Berechtigungsbereich, indem man für sein Verzeichnis einen logischen Namen vergibt.

Betritt ein Besucher einen solchen Bereich, indem er eine URL innerhalb des geschützten Verzeichnisses anzusprechen versucht, dann schickt der Webserver zunächst eine Aufforderung zur Authentifizierung an den Client. Der Browser zeigt dann dem Besucher z. B. eine Dialogbox mit Eingabefeldern für Benutzerkennung und Kennwort an, in der auch der Name des Bereichs angezeigt wird, damit der Besucher erkennen kann, wofür er sich gerade ausweisen soll. Weist sich der Besucher (gemäß der definierten Berechtigungen) korrekt aus, dann darf er auf das Dokument zugreifen, andernfalls löst der Webserver einen HTTP-Fehler 403 aus.

Innerhalb seines Berechtigungsbereichs kann der Besitzer eines Verzeichnisses Genehmigungen bzw. Verbote auf Benutzer- bzw. Gruppenkennungen beziehen. Die Definition dieser Kennungen erfolgt in einer entsprechenden Benutzer- bzw. Gruppendatei: In der Benutzerdatei stehen Zeilen mit Benutzerkennung und verschlüsseltem (!) Passwort (mit der UNIX-Systemroutine crypt()), in der Gruppendatei stehen Zeilen mit Listen von Benutzern der einzelnen Gruppenkennungen.

Außerdem kann man angeben, ob der Besucher sowohl von einem berechtigten Host aus als auch mit einer gültigen Benutzerkennung auf die Seite zugreifen kann oder ob die Kombination dieser beiden Rechte für einen erfolgreichen Zugriff erforderlich ist.

Beispiel: Benutzer meier definiert den Zugriffsschutz auf die Seiten seiner Entwicklungsabteilung im IP-Netzsegment 153.46.90.*

Besucher von verschiedenen IP-Adressen unterschiedlich behandeln[Bearbeiten]

Die vollständige Fragestellung lautete:

"Wenn mein User von IP xx.yy.zz.* kommt (z. B. aus dem firmeneigenen Netz), dann soll er ohne irgendwelche Abfragen zugreifen dürfen; wenn er aber von einer anderen IP-Adresse aus zugreift, dann soll er sich mit Benutzerkennung und Passwort gegenüber der mit .htaccess definierten Benutzerliste ausweisen müssen."

Im Beispiel wurde der Fall beschrieben, dass nur die Kombination aus IP-Adresse, Benutzerkennung und Passwort den Zugriff ermöglichen sollen (satisfy=all – alle Anforderungen müssen erfüllt sein).

Alternativ gibt es auch die Möglichkeit satisfy=any – mindestens eine der Anforderungen muss erfüllt sein. Das bewirkt dann genau den hier gewünschten Effekt.

Fragetext des vom Browser angezeigten Authentifizierung-Dialogs beeinflussen[Bearbeiten]

Der Fragetext kann in der Webserver-Konfiguration (inklusive .htaccess) nicht spezifiziert werden und ist auch gar nicht Bestandteil des Authentifizierungsdialogs zwischen Webserver und Browser.

Es ist vielmehr eine Frage des verwendeten Browsers, wie der angezeigte Fragetext aussieht.

Nicht nur die Texte, sondern sogar der Informationsgehalt derselben ist also massiv abhängig vom verwendeten Browser.

Was die Sprache angeht, ist dieses individuelle Verhalten sogar sinnvoll: Ein Anwender eines für seine Landessprache konfigurierten Browsers bekommt den Fragetext in einer Form angeboten, die er verstehen kann. Damit muss sich der Webmaster des Servers also schon mal nicht befassen.

Passwörter mit crypt() verschlüsseln[Bearbeiten]

Beachten Sie: Anwender, die eine Homepage auf einem Apache- oder kompatiblen Server haben und .htaccess verwenden können, haben deshalb noch nicht unbedingt die Möglichkeit, sich selbst Kennworte nach dem Verfahren des crypt-Befehls zu verschlüsseln. In diesem Fall können Sie folgende Weblinks nutzen, um sich ein Kennwort mit crypt verschlüsseln zu lassen.

per crypt() verschlüsselte Passwörter wieder entschlüsseln?[Bearbeiten]

Das ist nicht möglich; zu crypt() gibt es keine Umkehrfunktion. (Gäbe es sie, dann wäre eine Passwortdatei ein lukratives Opfer für Angriffe.)

Der Webserver muss es aber auch nicht können, sondern lediglich prüfen, ob das bei der Authentifizierung eingegebene Passwort mit dem gespeicherten Passwort übereinstimmt. Dazu kann er das eingegebene Passwort ebenfalls verschlüsseln und anschließend vergleichen, ob dasselbe Ergebnis dabei herauskommt.

Aus dieser Aussage kann man auf die Sicherheit des Schutzverfahrens schließen: Solange es keinen besseren Weg als Raten gibt, müsste ein potentieller Angreifer alle Passworte einer Länge von bis zu 8 Zeichen ausprobieren, also 2568 oder etwa 1.8*1019 Kombinationen durchprobieren (und für jeden Versuch einen Eintrag in der Protokolldaten des Webservers hinterlassen ...). Längere Passworte als 8 Stellen sind zulässig, werden aber von crypt() abgeschnitten.

Die Verschlüsselung unter Verwendung von crypt() führt allerdings zu Ergebnissen, die nicht ausschließlich vom angegebenen Passwort alleine abhängen, sondern außerdem noch von einem der Funktion übergebenen salt, einem zwei Zeichen langen String (damit kann man dann wieder 65536 verschiedene Verschlüsselungsverfahren erhalten – insbesondere kann man zwei mit verschiedenen salts verschlüsselten Passworten nicht ansehen, ob sie identisch sind! Auf diese Weise kann man dasselbe Passwort an verschiedenen Stellen verwenden und verliert ggf. trotzdem nicht sämtliche Schutzmechanismen, falls ein einziger gebrochen wird.)

Trotzdem weiß der Webserver, wie er das angegebene Passwort verschlüsseln muss: Das salt ist nämlich Bestandteil des verschlüsselten Passworts, und zwar die ersten beiden Zeichen desselben. (Man kann also immerhin erkennen, dass zwei Passworte mit verschiedenen salts erzeugt wurden.)

IP-Adressen, IP-Bereiche oder Namensadressen zulassen/ausschließen[Bearbeiten]

Sie können bestimmte IP-Adressen oder IP-Bereiche davon ausschließen, auf Webseiten zuzugreifen. Ebenso können Sie alle IP-Adressen ausschließen und nur ganz bestimmten den Zugriff erlauben. Anwender, die über eine nicht autorisierte IP-Adresse zugreifen, erhalten dann eine HTTP-Fehlermeldung (den HTTP-Status-Code 403), und der Zugriff wird ihnen verweigert.

Sinnvoll ist das beispielsweise, wenn Ihr Web-Angebot nur den Mitarbeitern Ihrer Firma im firmeninternen Intranet zugänglich sein soll. In einem solchen Fall kennen Sie vermutlich die vorhandenen Netze, möglicherweise sogar alle im Intranet fest vergebenen IP-Adressen. Oder Sie möchten bestimmte Anwender, die mit festen IP-Adressen unterwegs sind, ausschließen.

.htaccess-Datei
# Datei zum Regeln von IP-Bereichen
Order deny,allow
Deny from .aol.com
Deny from 192.168
Allow from 192.168"0.102

Zunächst legen Sie mit Order die logische Interpretationsreihenfolge der nachfolgenden Angaben fest. Möglich ist die Angabe deny,allow wie im Beispiel, oder auch die umgekehrte Reihenfolge.

In Zeilen, die mit Deny from oder Allow from beginnen, geben Sie eine konkrete IP-Adresse, einen Teil davon, eine Namensadresse oder einen Teil davon an. Mit Deny from verbieten Sie den Zugriff für den oder die angegebenen Benutzer, und mit Allow from erlauben Sie den Zugriff. Auch in der zentralen Konfigurationsdatei können für <Directory>-Container bereits solche Regelungen getroffen worden sein, die Sie dann in der .htaccess-Datei erweitern oder bei Bedarf korrigieren können. Im obigen Beispiel werden alle Benutzer ausgesperrt, die mit einer AOL-Kennung surfen, (.aol.com), sowie alle Benutzer mit einer numerischen IP-Adresse des Bereichs 192.168. Das ist einer der „privaten“ IP-Bereiche, also Ihr Intranet. Um aber einem bestimmten Benutzer aus diesem Bereich doch den Zugriff zu erlauben, wird im Beispiel anschließend noch mit Allow from dessen spezifische IP-Adresse angegeben.

Die Angabe wird einfach als Teilzeichenkette interpretiert. Wenn ein Client eine Webseite in dem Verzeichnis mit der .htaccess-Datei aufruft, vergleicht der Webserver, ob eine der notierten Zeichenketten in derjenigen Zeichenkette vorkommt, die der aufrufende Client dem Server übermittelt. Um mehr über die möglichen Zeichenketten zu erfahren, die in der Praxis übermittelt werden, empfiehlt sich ein Blick in die Log-Dateien des Webservers.

Beachten Sie: Anstelle einer bestimmten Zeichenkette können Sie auch Allow from all bzw. Deny from all notieren, um eine generelle Erlaubnis oder ein generelles Verbot zu formulieren. Wenn Sie beispielsweise keinerlei Einschränkungen für nötig halten, geben Sie mit Allow from all Ihr Verzeichnis frei. Soll Ihr Webangebot dagegen lediglich Ihrem Firmennetz zur Verfügung stehen, so notieren Sie:
Order deny,allow
Deny from all
Allow from 192.168
Beim Aussperren und Einschließen bestimmter IP-Adressen, IP-Bereiche oder Namensadressen sind die gleichen nach oben erweiterten Möglichkeiten erlaubt wie beim Passwortschutz. Die Anweisungen mit Deny from und Allow from können dabei in entsprechende Tags eingeschlossen werden. So lässt sich z.B. das Aussperren bestimmter Benutzer oder Benutzerkreise auf bestimmte Dateien oder Zugriffsmethoden beschränken.


.htaccess-Datei
# .htaccess-Datei für Web-Verzeichnis /service
AuthType Basic
AuthName "Service-Bereich"
AuthUserFile /usr/verwaltung/web/.htusers
Require valid-user
Order deny,allow
Deny from all
Allow from 192.168
Satisfy any

In diesem Beispiel wird Require zusammen mit Allow from und Deny from verwendet. Die Anweisung Satisfy gibt an, welche der Bedingungen erfüllt sein müssen. Das Schlüsselwort any bedeutet, dass alle Benutzer mit einer numerischen IP im Bereich 192.168 automatisch zugelassen sind. Benutzer, die nicht von dort kommen, werden nach einem Benutzernamen und Passwort gefragt (Oder-Verknüpfung der beiden Bedingungen). Hingegen würde das Schlüsselwort all bedeuten, dass nur Benutzer mit einer IP aus dem Bereich 192.168 und einem gültigen Benutzernamen zugelassen sind (Und-Verknüpfung der beiden Bedingungen).


Quellen[Bearbeiten]

Weblinks[Bearbeiten]

  • apache.org