Tag-Archiv „mod_rewrite“
Möchte man ein Verzeichnis – zum Beispiel ein einfaches Administrationsmenü – mit einem Passwortschutz versehen ohne dabei eine überdimensionierte ACL zu bemühen, bieten sich die meist mitgelieferten Möglichkeiten des Apache-HTTP-Servers an. Allerdings ist es durch den Einsatz von CMS, Frameworks und mod_rewrite mittlerweile fast der Regelfall, dass vermeintliche Verzeichnishierarchien im URL nicht mit einer „physischen“ Verzeichnisstruktur im Dateisystem des HTTP-Servers korrespondieren und somit nicht möglich einfach eine entsprechende .htaccess-Datei in ein Verzeichnis zu legen. Wie man einen derartigen Passwortschutz dennoch relativ einfach realisiert, möchte ich nachfolgend kurz beschreiben.
Der gute alte Passwortschutz
Möchte man den URL http://example.com/admin/ mit einem Passwortschutz versehen und das Verzeichnis existiert tatsächlich im Dateisystem, reicht es eine .htaccess-Datei mit dem folgenden Inhalt in diesem Verzeichnis anzulegen (Vorausgesetzt eine entsprechende Passwort-Datei existiert):
AuthType Basic
AuthName "Anmeldung erforderlich"
AuthUserFile /Pfad/zu/Passwort-Datei
Require valid-user
Dies ist eine leichte Übung und die Vorgehensweise lässt sich auch in der Dokumentation des Apache-HTTP-Servers nachlesen.
Zugriffs-URI-basierter Passwortschutz
Gibt es das vermeintliche Verzeichnis allerdings gar nicht im Dateisystem, sondern existiert dieses nur in Rewriting-Regeln, dann fehlt schlichtweg der Ort um die entsprechende .htaccess-Datei abzulegen. Dies ist aber auch nicht zwingend notwendig, da man den Apachen mithilfe des Moduls SetEnvIf trotzdem dazu überreden kann, das „Geisterverzeichnis“ über die Abfrage von Zugangsdaten zu schützen. Dazu legt man eine .htaccess-Datei mit dem folgenden Inhalt im Wurzelverzeichnis an, auf das http://example.com zeigt, bzw. ergänzt die gegebenenfalls schon Vorhandene:
AuthType Basic
AuthName "Anmeldung erforderlich"
AuthUserFile /Pfad/zu/Passwort-Datei
Require valid-user
SetEnvIf Request_URI "/admin" req_auth=1
Order Allow,Deny
Allow from all
Deny from env=req_auth
Satisfy any
Über die SetEnvIf-Direktive weist man den HTTP-Server zunächst dazu an, die Umgebungsvariable req_auth (diese kann auch anders genannt werden) zu setzen, sofern der Zugriffs-URI „/admin“ lautet. Im weiteren erlaubt man nun jedem den Zugriff (durch das Ablegen der .htaccess im Wurzelverzeichnis hätten wir sonst den Zugriff auf die komplette Website unterbunden) und verbietet den Zugriff, sofern die Umgebungsvariable req_auth gesetzt ist. Mit der abschließenden Satisfy-Direktive wird dafür gesorgt, dass es reicht, dass eine der beiden Bedingungen (req_auth nicht gesetzt oder angemeldeter Benutzer) erfüllt ist. Fertig. Freuen.
Saubere URLs gehören längst zum guten Ton. Zwar werden diese vom „Otto-Normal-Nutzer“ während des Surfens meist gar nicht wahrgenommen, der Vorteil von:
http://www.example.com/de/products/productname-12/details gegenüber:
http://www.example.com/index.php?section=products&show=details&id=12&lang=de wird aber spätestens bei der Verwendung in E-Mails, SMS oder auf Papier deutlich. Selbst dem ein oder anderen Internetausdrucker dürfte hierbei auffallen, dass es eben auf die Länge und die Technik ankommt.
Neben rein ästhetischen und die Optimierung für Benutzer und Suchmaschinen betreffenden Aspekten können saubere URLs auch einen gewissen – wenn auch geringen – Sicherheitsvorteil gegenüber Ihrem Pendant im 90er-Jahre-Stil bieten. Letzterer liefert gegebenenfalls schneller Informationen über den internen Aufbau der Web-Applikation und bietet somit einen zusätzlich Ansatzpunkt für Angriffe, sofern entsprechende Schwachstellen in der Anwendung existieren. So könnte, hinter den oben genannten Beispiel-URLs die gleiche Anwendung laufen, allerdings geht nur aus der zweiten Adresse hervor, dass es sich um eine PHP-Anwendung handelt (Das Wissen über die verwendete Skript- oder Programmiersprache ermöglicht unter Umständen grundlegende Annahmen über den Aufbau der Applikation und könnte daher für einen Angriff relevant sein.). Darüber hinaus offenbart die zweite URL-Adresse über die GET-Parameter gegebenenfalls die Namen der verwendeten Variablen und zum Teil auch deren Funktion innerhalb der Applikation. Sofern im ersten Beispiel die expose_php-Direktive in der php.ini deaktiviert ist, lässt sich ohne Weiteres nicht herausfinden, dass PHP im Spiel ist und ein Rückschluss auf Variablennamen ist nicht möglich.
Sicherlich handelt es sich hierbei nur um „Securiy through obscurity“ und den Daten die vom Benutzer kommen – also neben Cookies und POST-Daten auch den GET-Parametern – sollte man grundsätzlich mit dem nötigen Misstrauen begegnen. Eine zusätzlich Hürde für potentielle Angreifer kann jedoch nie schaden.
Nach diesem mehr oder weniger allgemeinen Vorgeplänkel, schneidet der zweite und letzte Teil der Kurzreihe mögliche Sicherheitsvorteile bei der Verwendung von mod_rewrite im Gegensatz zu einer PHP–Rewrite-Engine an und setzt sich mit der Frage auseinander, an welcher Stelle in der Webapplikation das Umschreiben der URL denn eigentlich stattfinden sollte.
Gelegentlich ist es notwendig eine Webanwendung für umfassendere Arbeiten in eine Art Wartungsmodus zu versetzen. Dabei wird dem Besucher dann eine Seite mit einem freundlichen Hinweistext präsentiert, der über Grund und Dauer der Wartungsarbeiten unterrichtet. Bei einigen CM-, Blog-, Webshopsystemen etc. ist ein derartiger Modus bereits integriert und lässt sich einfach über das Admin-Menü aktivieren. Ist dies nicht der Fall, lässt sich eine temporäre Umleitung sehr einfach mit dem Rewrite-Modul für den Apache-Webserver realisieren:
RewriteEngine On
RewriteRule !wartung\.html$ /wartung.html [L]
Leider kann man mit dieser Variante selbst nun auch nicht mehr, etwa für Tests, mit einem Browser auf die Seiten zugreifen. Dies lässt sich ändern, indem die RewriteRule nur anwendet wird, wenn mit einer anderen als der eigenen IP-Adresse (im Beispiel 321.123.321.123) auf die Seite zugegriffen wird.
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^321.123.321.123$
RewriteRule !wartung\.html$ /wartung.html [L]
Diese Lösung ist soweit ganz praktikabel. Bei dynamischen IP-Adressen muss die Bedingung allerdings sehr wahrscheinlich nach jeder Einwahl angepasst werden (sofern der Wartungsmodus überhaupt so lange aufrecht erhalten wird).
Eine weitere Variante bei der von einem Rechner aus, sowohl der Wartungsmodus, als auch die normale Ansicht der Seite (Testmodus) genutzt werden können, lässt sich wie folgt realisieren:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !.*-gEheIm$
RewriteRule !wartung\.html$ /wartung.html [L]
Hier werden alle Besucher auf die Wartungsseite umgeleitet, deren User-Agent-String nicht mit „-gEheIm“ endet. Beim Firefox lässt sich der User-Agent-String recht einfach ändern, indem man „about:config“ aufruft und dort den Schlüssel „general.useragent.extra.firefox“ ensprechend ergänzt. Alternativ lässt sich das auch mit Addons erledigen. Damit lässt sich nun verhältnismäßig einfach zwischen den beiden „Ansichten“ umschalten. Wesentlicher Nachteil dabei ist allerdings, dass der User-Agent-String an jede aufgerufene Webseite übertragen wird und damit nicht wirklich geheim ist. Man sollte also nicht gerade auf fremden Seiten surfen und eventuell sogar noch als Referrer den URL einer im Wartungsmodus befindliche Seite hinterlassen.