Mitgliederversammlung 2017


Die diesjährige Mitgliederversammlung des Vereins SELFHTML e.V. findet am 7.10.2017 um 10:00 Uhr in Berlin statt.

Die Adresse des Tagungsortes sowie die geplante Tagesordnung entnehmt ihr bitte der Seite Mitgliederversammlung 2017.

Interessierte Gäste sind gern gesehen.

Anmeldung: https://forum.selfhtml.org/events/2

Webserver/htaccess/Zugriffskontrolle

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche

Mit einer .htaccess-Datei können Sie eine benutzerdefinierte Zugriffskontrolle auf Dateien oder ganze http-Verzeichnisse einzuschränken.

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.

Beispiel: .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 überdecken 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


Beispiel: benutzer.txt
# (Demo: jeweils Passwort = Benutzerkennung, crypt()-salt = "IN")
chef:IN3WY1lATStaY
sekretae:INz8B568yvs7Y
schmidt:INQaGJBu4yljQ
meier:INqq3xgT4zpp6
huber:INT.EAmojNwN6
test:INnA1BztLIaac
Beispiel: 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.)

Quellen[Bearbeiten]

Weblinks[Bearbeiten]