Bei Fragen zu diesem Beitrag bitte den Autor des Beitrags kontaktieren!
Das kommt auf die Konfiguration des Webservers an.
Das Konzept von .htaccess bedeutet, daß der Webmaster einen Teil seiner Kontrollmöglichkeiten an einen Benutzer abtritt. Bei den Massenanbietern von Homepages ist generell kaum zu erwarten, daß sie dazu bereit sind - und sei es nur aus Angst, einem Benutzer versehentlich das Recht zu geben, etwas zu tun, was ihren Betrieb mit tausenden von Homepages lahmlegen könnte.
Der Webmaster müßte auf jeden Fall wissen, was er tut - oder er müßte dem Anwender vertrauen. Deshalb wird eine Fähigkeit wie .htaccess vermutlich nur in den etwas teureren Paketen an Web-Speicher enthalten sein - was schade ist, denn wenn man das als Webmaster einmal richtig eingerichtet hat, könnten tausende von Benutzern davon profitieren.
Da bei bestimmten Einstellungen der Server-Konfiguration automatisch .htaccess-Dateien in übergeordneten Verzeichnissen mit geprüft werden müssen, könnte das Ganze bei wirklich hohen Zugriffszahlen auch eine Performance-Frage werden. Auch hier ist der Server für den Massenbetrieb der wahrscheinlichste Kandidat dafür, so eine Fähigkeit nicht anzubieten.
Falls der Provider tatsächlich einen solchen Service anbietet, dann sollte er auch angeben, welche der vielen features von .htaccess er freigeschaltet hat.
Abschließend ist ggf. noch zu beachten, daß der Name .htaccess in der Konfiguration des Webservers einstellbar ist. Im Zweifelsfalle also den Provider nach dem Namen der Datei fragen.
Grundsätzlich schon, allerdings ist die Standardserverkonfiguration des Apache so eingestellt, dass cgi-bin nicht durch .htaccess beeinflussbar ist. Falls es Probleme dabei gibt (insbesondere 500 Internal Server Error oder Ausbleiben der Funktionalität), sollte man seinen Provider darauf ansprechen.
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 Artikel wurde der Fall beschrieben, daß 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 muß erfüllt sein. Das bewirkt dann genau den hier gewünschten Effekt.
Er kann es gar nicht. Zu crypt() gibt es meines Wissens keine Umkehrfunktion. (Gäbe es sie, dann wäre eine Passwortdatei ein lukratives Opfer für Angriffe.)
Er muß es aber auch nicht können. Der Webserver muß lediglich prüfen können, 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üßte 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 muß: Das salt ist nämlich Bestandteil des verschlüsselten Passworts, und zwar die ersten beiden Zeichen desselben. (Man kann also immerhin erkennen, daß zwei Passworte mit verschiedenen salts erzeugt wurden.)
Meines Wissens nein. Der Fragetext kann in der Webserver-Konfiguration (inklusive .htaccess) nicht spezifiziert werden und ist offenbar gar nicht Bestandteil des Authentifizierungsdialogs zwischen Webserver und Browser.
Es ist vielmehr eine Frage des verwendeten Browsers, wie der angezeigte Fragetext aussieht. Eine kleine Stichprobe, ohne Anspruch auf Vollständigkeit:
| Kopfzeile |
Fragetext |
Browser |
| Username and Password Required |
Enter username for <realm> at <hostname> |
Netscape 3.0 Gold (Englisch) |
| Benutzername und Kennwort erforderlich |
Benutzernamen eingeben für <realm> bei <hostname> |
Netscape 4.05 und 4.5 (Deutsch) |
| Authentifizierung |
Der Zugriff auf diese Seite erfordert ein Kennwort. Ressource: <realm> |
Microsoft IE 2.0 (Deutsch) |
| Geben Sie Benutzernamen und Kennwort ein |
Si <URL>
Bereich: <realm> |
Microsoft IE 5.0 (Deutsch) |
| <url> (abgeschnitten, Box ist zu klein) |
The document is locked. Please enter username and password to unlock |
Opera 3.5 (Englisch) |
Nicht nur die Texte, sondern sogar der Informationsgehalt derselben ist also massiv abhängig vom verwendeten Browser. (Opera 3.5 zeigt nicht einmal den Namen des realms an.)
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 muß sich der Webmaster des Servers also schon mal nicht befassen.
Der Internet Explorer bietet in der Version 5.0 zusätzlich die Option an, die eingegebene Kombination von Benutzerkennung und Passwort lokal zu speichern. Bei einem erneuten Zugriff auf denselben realm werden die hierfür zuletzt verwendete Benutzerkennung (im Klartext) sowie das Passwort (angedeutet durch entsprechend viele Sternchen) bereits in den Authentifizierungsdialog eingetragen.
Das mag für den Anwender bequemer sein - aber es bedeutet natürlich auch, daß ein Eindringling diese Information ggf. irgendwo auf diesem lokalen PC ebenfalls finden könnte.
Das Kommando der (als Beispiel verwendeten) Apache-Konfiguration, welches den Funktionsumfang einer .htaccess-Datei regelt, heißt AllowOverride. Hierbei kann der Webmaster eine beliebige Teilmenge der folgenden Schlüsselworte angeben. Jedes Schlüsselwort schaltet die gesamte Gruppe an Rechten für die Verwendung in .htaccess-Dateien frei.
Da das Kommando zur Definition der Rechte eines URL-Baums gehört, kann man in verschiedenen URL-Bäumen problemlos unterschiedlich viele .htaccess-Rechte für seine Anwender freischalten.
AuthConfig |
- Definition einer Berechtigungsstruktur, wie im Artikel beschrieben (Definition von Realms, Benutzer- und Passwortdateien sowie Anforderungen für die Authentifizierung). Bewirkt erst zusammen mit
Limit die gewünschten Mechanismen.
|
FileInfo |
- Eigene Definition von MIME-Typen und deren Abbildungen auf Datei-Endungen,
- bedingte Verwendung sprachspezifischer Varianten von HTML-Dokumenten,
- Definition von Dokumenten als Reaktion auf http-Fehlercodes.
Natürlich wäre CGI-Fähigkeit gerade im Zusammenhang mit der Definition von Fehlerdokumenten schön, weil man dann über eine CGI-Anwendung die entsprechenden Zugriffe protokollieren lassen könnte ... aber statt dessen kann der Provider dem Anwender auch einen Auszug aus den zentralen Log-Dateien anbieten, was ihm die Vergabe des (gefährlichen) CGI-Rechtes erspart.
|
Indexes |
- Feineinstellung für intelligentes directory browsing, falls solches erlaubt ist:
- selbst definierbare Icons für Dateitypen
- eigene Beschreibungstexte für MIME-Typen
- Definition des Namens der Indexdatei (
index.html etc.)
- automatische Kopf- und Fußzeilen-Includedateien für directory-browsing
- Liste von nicht anzuzeigenden Dateien (regular expressions!)
Mit geeigneten Einstellungen kann man ganz ohne eigene HTML-Dokumente eine halbwegs komfortable Navigationsfunktion allein über die directory-browsing-Funktion des Webservers organisieren, die dennoch individuell aussieht.
|
Limit |
- Zugangskontrolle, wie im Artikel beschrieben (Freigabe der Kommandos
allow, deny und order).
Limit alleine ohne AuthConfig erlaubt die Zugangsbeschränkung auf Verzeichnisse nur anhand von durch den Webmaster vordefinierten Rechtestrukturen, nicht aber z. B. die Definition eigener Benutzerkennungen.
|
Options |
- XBitHack - damit kann man eine Art selbstprogrammierbarer Variante von SSI erzeugen
- Options - damit kann man Optionen für das Verhalten des Verzeichnisses setzen, und zwar:
Indexes - erlaubt die Verwendung oder Abschaltung von directory browsing (ansonsten gilt einfach die zentrale Voreinstellung des Servers).ExecCGI - erlaubt die Definition eigener CGI-Verzeichnisse.Includes - erlaubt die Verwendung oder Abschaltung von Server Side Includes im vollen Umfang (inklusive ExecCGI!).IncludesNoCGI- erlaubt die Verwendung oder Abschaltung von Server Side Includes im beschränktem Umfang (ohne ExecCGI!).MultiViews - erlaubt die Verwendung oder Abschaltung von dynamischen sprachabhänigen Dokumenten.SymLinks - erlaubt die Verwendung von symbolic links als Verweise auf Dokumente in anderen Verzeichnissen. Elegant, falls man auf Objekte zeigen will, die außerhalb des URL-Baums liegen (z. B. Protokolldateien des Webservers), unterläuft aber damit ggf. bewußt das Verbergen solcher Objekte durch eben diesen URL-Baum.SymLinksIfOwnerMatch - eingeschränkte Version, erlaubt nur den Verweis auf Objekte derselben Benutzerkennung.
Das hier ist die Einstellung, bei welcher der Webmaster wirklich aufpassen muß und besser erst mal nur die entsprechenden Rechte in seiner zentralen Konfiguration definieren sollte (IncludesNoCGI für sich genommen ist ungefährlich und sehr nützlich!).
Wenn man einem Benutzer erlaubt, diese Optionen selbst zu setzen, dann kann dieser alles aus dieser Liste selbst einstellen! Das ist sehr schade, denn es verhindert auch die Freigabe der ungefährlichen Rechte an alle Benutzer (etwa die Entscheidung, ob man directory browsing will oder nicht) und zwingt den Webmaster dazu, dies in seiner zentralen Konfiguration ggf. für verschiedene Benutzer selbst unterschiedlich zu definieren.
|
Der Provider muß in jedem Falle wissen, was er tut - je genauer er das weiß, desto eher kann er beurteilen, welche der dezentralisierten Rechte welchen Effekt auf seinen Server haben werden.
In der CGI-Spezifikation ist eine Environment-Variable REMOTE_USER beschrieben, welche die Benutzerkennung einer Authentifizierung der entsprechenden Realm speichern soll. Über diese Variable läßt sich z. B. der Name eines Benutzers protokollieren usw. Hat sich der Anwender nirgendwo anmelden müssen, um auf die URL der CGI-Anwendung zuzugreifen, dann ist der Inhalt dieser Variable natürlich leer.
Der Apache-Webserver hält sich an diese Spezifikation. Leider aber lehrt die Erfahrung, daß sich keineswegs alle Webserver strikt an die CGI-Spezifikation halten. Der Webserver WebSite1.1 für Windows32 nennt diese Variable beispielsweise AUTH_USER!
Da hilft im Zweifelsfalle nur, ein CGI-Skript zur Ausgabe sämtlicher CGI-Variablen zu installieren und nachzusehen - oder über die CGI-Variable SERVER_SOFTWARE den Namen des Webservers abzufragen, um herauszufinden, welche Environment-Variable man abfragen muß ...
Hat sich ein Anwender innerhalb eines realms erfolgreich angemeldet, dann bleibt ihm seine Identität für die Dauer seiner Browser-Sitzung erhalten - sofern er diese nicht bewußt ändert.
Wie kann man seine Identität ändern? Indem man auf eine URL desselben realms zugreift, für welche die bisherige Identität kein Zugriffsrecht hat. In diesem Moment wird wieder der ursprüngliche Authentifizierungsdialog gestartet, und der Anwender kann nun eine andere Benutzerkennung und ein passendes Kennwort eingeben - sofern er solches besitzt. In diesem Moment verliert er seine alte Identität - greift er also wieder auf die ursprüngliche URL zu, erfolgt erneut ein Authentifizierungsdialog ...
Ganz allgemein gesagt: So, wie der Webmaster sie in der Direktive AccessFileName genannt hat.
Vielleicht ist es gar nicht erwünscht, daß der Name einer so wichtigen Datei mit einem Punkt beginnt, also bei bestimmten Verzeichnislisten auf UNIX-Servern ggf. gar nicht angezeigt wird, wenn man etwa beim UNIX-Kommando ls nicht explizit den Operand -a angibt (wie das manche FTP-Clients tun).
.htaccess ist lediglich der voreingestellte Defaultwert in der Apache-Konfiguration.
SELFHTML aktuell Artikel Serverkonfiguration
© 2007 
Impressum
