Tricks mit .htaccess

.htaccess – Dateien sind kleine Webserver-Konfigurationsdateien, die einige sehr nützliche Features mitbringen. Auf die meiner Meinung nach nützlichsten Tricks und Kniffe mit dieser Datei gehe ich in dieser Kurzabhandlung ein.

1) .htaccess erstellen

htaccess erstellen

Das erste Problem kommt postwendend: Wie erstellt man eine .htaccess-Datei? Da Windows keine Dateinamen zulässt, die mit einem Punkt beginnen, hat man 2 Möglichkeiten: Entweder man erstellt die Datei unter htaccess.txt, lädt sie auf den FTP-Server und benennt sie da erst in .htaccess um, oder man verwendet einen „besseren“ Texteditor wie Notepad++, erstellt ein neues Dokument und speichert dieses unter .htaccess, was dann komischerweise auch von Windows toleriert wird.

2) Was es zu beachten gilt

Fehler 500

.htaccess-Dateien müssen zu 100% korrekt geschrieben sein, denn sonst lacht euch ein Fehler 500 (siehe rechts) an, der den Seitenzugriff auf den kompletten Server verhindert – Also vorsichtig sein und lieber erstmal „lokal“ experimentieren oder die .htaccess in einem Unterverzeichnis ausprobieren. Das bringt uns auch gleich zum nächsten Punkt: In der Wurzel erstellte .htaccess-Dateien (also etwa https://d-mueller.de/.htaccess) haben Gültigkeit über den kompletten Webserver einschließlich aller Unterverzeichnisse, wohingegen eine .htaccess in einem Unterordner (also etwa https://d-mueller.de/subfolder/.htaccess) nur auf diesen Unterordner und Unterordner dieses Ordners (wie z.B. https://d-mueller.de/subfolder/weitererSubfolder/) hat

3) Webserver-Ansicht

Dateinamensübersicht

Jetzt geht’s auch schon los: Wenn Ihr ein Verzeichnis per Browser aufruft und keinen Dateinamen angebt (also bspw. https://d-mueller.de/verzeichnis/), so wird automatisch nach der index.php oder index.html gesucht. Wenn es diese nicht geben sollte, heißt es Forbidden – You don’t have permission to access /verzeichnis/ on this server.. Soll jetzt aber eine Dateiauflistung nach dem Schema des Screenshots auf der linken Seite erscheinen, muss foldender Code in die .htaccess

Options +Indexes
DirectoryIndex index.html

Dies weißt den Webserver dazu an, eine index.html zu erstellen, die alle Dateien in diesem Unterverzeichnis anzeigt. Vorsicht: Wie unter 2) Was es zu beachten gilt erwähnt, gilt dies auch für alle Unterordner. Bedenkt, dass solch eine Option beachtliche Sicherherheitsrisiken mit sich bringen kann.

4) Alternative Fehler-404-Seite

Fehler 404

Die Standardseite für nicht gefundene Dateien ist nicht die hübscheste und die „Absprungrate“ der Besucher dürfte wohl nah an 100% liegen. Wenn ihr jetzt allerdings eine eigene Seite erstellt, die interessante News und andere „Ausweichdokumente“ anbietet, die die Aufmerksamkeit des Besuchers erregen, ist die Chance wesentlich höher, keinen Besucher zu verlieren. Bei Webshops beispielsweise würde sich ein „Diese Artikel könnten Sie interessieren“-Script anbieten, um die Aufmerksamkeit gleich wieder zu bekommen. Diese Codezeile macht’s möglich:

ErrorDocument 404 /fehler404.php

So würde der Benutzer nach dem vergeblichen Besuchen von https://d-mueller.de/gibtsnicht.htm auf https://d-mueller.de/fehler404.php weitergeleitet werden – geht natürlich auch mit Unterverzeichnissen.

5) PHP Fehler-Einstellungen

PHP Errorlog

PHP kann sehr offenherzig sein und durch großzügig detaillierte Fehlermeldungen zwar einerseits dem Admin bei der Fehlersuche merklich unter die Arme greifen, allerdings auch potentiellen Störenfrieden einen tiefen Einblick in die logischer Struktur der Website geben und damit die Chance für einen erfolgreichen Angriff erhöhen.

Mit der Fehlermeldung

Warning: mysql_connect()
[function.mysql-connect]: Access denied for user 'zugangsName'@'localhost' (using password: YES) in D:\xampp\htdocs\index.php on line 2

hätte man als „Interessent“ zumindest schonmal den Name für den Datenbank-Zugriff. Zwar könnte man jetzt per PHP die Ausgabe der Fehlermeldung im Script unterdrücken, allerdings ist das unsauber, unprofessionell und ihr habt keine Chance zum Debuggen, da ihr vom Fehler ja garnichts mitbekommt. Besser ist da das komplette Ausschalten der PHP-Fehlermeldungen und das gleichzeitige Erstellen eines Error-Logs. Folgender .htaccess-Code machts möglich:

php_flag display_errors off
php_flag log_errors on
php_value track_errors on
php_value error_log D:/xampp/htdocs/test/phperr.log

Dabei entspricht der in der letzten Zeile angegebene Pfad dem absoluten Pfad zu eurem Server, zu erfahren per

<?php phpinfo(); ?>

und da unter „open_basedir“ oder per

<?php echo $_SERVER['DOCUMENT_ROOT']; ?>

Damit wird eine automatische Logdatei erstellt, die ihr regelmäßig einsehen solltet.

6) Verändern der PHP-Konfiguration

Gerade bei Shared-Hostern habt ihr oft keinen Zugriff auf die php.ini, in der alle Konfigurationsmöglichkeiten festgeschrieben sind. Wenn euer Hoster kulant ist, habt ihr zwar vielleicht die Chance, dass jemand für euch die gewünschten Einstellunegn an der php.ini vornimmt, allerdings gelten diese dann auch immer global für den kompletten Webserver. Gesetzt den Fall, ihr habt verschiedene Web-Projekte, welche jeweils verschiedene Konfigurationen von PHP voraussetzen, ist die .htaccess wieder das mittel zur Wahl:

php_flag magic_quotes_gpc off
php_flag register_globals off

So könnt ihr wieder recht einfach für jedes Subverzeichnis eigene Regeln bestimmen und „unmögliche“ Servereinstellungen korrigieren, wie sie oft der Fall sind.

7) Zeichensatzoptionen

Weiterhin ist es möglich, den Standard-Zeichensatz für alle Dokumente einer bestimmten Endung zu definieren. Hier nur kurz den Code, eine ausführlichere Beschreibung gibt es im UTF8-Tutorial unter 5) Der Webserver

AddCharset utf-8 .css .htm .html .js
php_value default_charset utf-8

8) Verzeichnisschutz

Passworteingabe

Ein recht komplexes Thema, welches ich auch noch kurz anschneiden möchte, ist der Verzeichnisschutz mittels .htaccess. Wenn ihr keine Lust auf das Schreiben komplexer Login-Scripte mit PHP habt, nur weil ihr vorübergehend ein geschütztes Verzeichnis auf eurem Webserver braucht, ist .htaccess mal wieder eure Wahl. Es lassen sich hier ganze Usergruppen definieren, welchen man die Befugnis auf verschiedene Dateien und Ordner gestatten oder verbieten kann. Erstmal etwas Beispielcode:

AuthUserFile /www/htdocs/w009d060/.htusers
AuthName "geheimer Bereich"
AuthType Basic
Satisfy Any

<Limit GET POST>
    order deny,allow
    deny from all
    allow from 85.13.131.206
    Require valid-user
</Limit>

Und nun im Einzelnen:

1. AuthUserFile definiert den absoluten Pfad zur Datei .htusers, in der die berechtigten User mit ihrem Passwort angegeben sind. Die Syntax dieser Datei ist dabeiBenutzername:verschluesseltes Passwort – Einen Generator zum verschlüsseln der Passwörter sowie nähere Informationen zur Gruppenzugangsberechtigung findet ihr bei sefthtml. Die tolle Sache mit der .htusers ist, dass ihr mit dem einmaligen Erstellen und Anlegen dieser Datei in der Wurzel des Webservers bequem mehrere Verzeichnisse schützen könnt, indem ihr die immergleiche .htaccess in alle zu schützenden Unterordner schiebt. Dies ist sehr nützlich, wenn der Zugriff auf die Seite selbst (also https://d-mueller.de) gestattet sein soll, der Zugriff auf „private Unterverzeichnisse“ wie bspw. https://d-mueller.de/geheim/ nicht gestattet werden soll. In diesem Fall wäre dann einfach eine .htaccess nach oben definiertem Schema in alle zu beschützenden Unterverzeichnisse zu schieben.
2. AuthName erscheint in der Passwort-Eingabebox als Name der Seite (siehe Screenshot). Dieser Parameter ist optional und wird standardmäßig byPassword genannt, wenn ihr ihn nicht setzt.
3. AuthType definiert, ob die Übertragunsart des Usernamens und des Passworts. Basic ist unverschlüsselt, Digest ist verschlüsselt, macht das ganze aber um einiges komplizierter.
4. Satisfy gibt an, ob alle geforderten Zugangsbedingungen (per Standard auf All) oder nur eine der Bedingungungen (Any) erfüllt sein muss. Zu den Bedingungen dann später.
5. <Limit GET POST> definiert die Beschränkung des Zugriffs für alle Operationen, also Senden an die Seite (POST) und Empfangen von Informationen von der Seite (GET). Eine Alternative zu LIMIT ist das auch sehr nützliche FilesMatch, welches nach folgender Syntax den Zugriff auf Dateien per Regular Expression genehmigt und verbietet. Beispielsyntax:

   <FilesMatch "^file.(css|php)$"> </FilesMatch>

   (statt 

   <Limit GET POST> [...] </Limit>

   ) würde als Filter nicht den Zugriff auf ALLE Dateien, sondern nur den Zugriff auf die Dateien file.php sowie file.css mit den eingeschlossenen Angaben regulieren. Detailliertere Konfigurationsmöglichkeiten für den doch sehr mächtigen FilesMatch-Parameter gibt es hier.

6. order deny,allow gibt die Reihenfolge der Abarbeitung von Erlaubnis und Verbot an. In der Reihenfolge deny,allow wird erstmal pauschal alles verboten, es sei denn die nachfolgenden Bedingungen werden alle (Satisfy All) oder zumindest eine (Satisfy Any) erfüllt. In der Reihenfolge allow,deny wird pauschal erstmal der Zugriff erstmal erlaubt,es sei denn die nachfolgenden Bedingungen werden nicht erfüllt (siehe wieder Satisfy). Zu diesem Bedinungen im nächsten Punkt.
7. allow from ermöglicht die Eingabe einer IP-Adresse, von der aus der Zugriff immer gestattet ist. Beachtet hierbei jedoch, dass die IP normalerweise bei jeder neuen Verbindung ins Internet eine andere ist.
8. Require valid-user besagt, dass eine gültige Kombination aus Passwort und Benutzername aus der .htusers angegeben muss, um den Zugriff zu gestatten. Alternativ lassen sich hier auch durch Leerzeichen getrennt berechtigte User aus der .htusers angeben, wenn z.B. nicht jeder User der in der .htusers angegeben ist, Zugriff erhalten soll. Beispiel: Require stefan david paula

Wer genau hat also mit dem obigen Beispielcode Zugriff auf die Seite? Es ist ja Satisfy Any gesetzt, also muss nur eine der beiden geforderten Bedingungen (entweder ist die IP des Besuchers korrekt oder der Besucher gibt ein gültiges Passwort ein) zutreffen, um Zugang zu erhalten. Wäre jetzt hier Satisfy All gefordert, würde eine Und-Verknüpfung greifen und der Zugriffswillige müsste die korrekte IP und ein korrektes Passwort eingeben – doppelt gemoppelt quasi ;).

9) Weiterleitungen

Ein weiteres großes Einsatzgebiet für .htaccess-Dateien ist die Weiterleitung (Stichwort: mod rewrite). Ein paar sinnvolle, nützliche Anwendungsbeispiele werde ich hier aufzählen.

Ganze Website umleiten

Wenn ihr mehrere Domains verschiedener Schreibweise habt (also bspw. http://www.mein-name.de und http://www.meinname.de), bietet es sich an, die eine auf die andere weiterleiten zu lassen. Dies mit PHP-Codes wie etwa

<?php header("Location: http://www.meinname.de/"); ?>

oder Meta-Weiterleitungen wie

<meta http-equiv="refresh" content="0;url=http://www.meinname.de/">

zu realisieren, ist immer aufwendig und google könnte in der Bewertung und Indizierung der Seite auch etwas dagegen haben. Deswegen empfiehlt sich eine Umleitung per .htaccess. Syntax:

Redirect / http://www.meinname.de/

Dieser Code leitet alle Anfragen an die neue Domain weiter, sodass http://www.mein-name.de/unterordner/datei.htm elegant auf http://www.meinname.de/unterordner/datei.htm verweist.

Doppelten Content vermeiden

Google hat ebenfalls etwas gegen doppelten Inhalt einzuwenden, also wenn eure Domain (wie das meistens der Fall ist) unter http://www.euername.de und http://euername.de zu erreichen ist, existiert die Seite quasi 2mal, was die Bedeutung der Seite im Google-Index evtl. herabsetzt. Um eure Seite nur auf eine Art und Weise aufrufen zu können, hilft ein htaccess-Schnippsel wieder weiter. Diesmal bedienen wir uns des oben angesprochenen Plugins mod rewrite, welches auf dem Großteil der Server bereits vorinstalliert ist. Falls ihr nicht sicher seid, steht hier, wie man testet, ob mod rewrite an ist oder nicht.

RewriteEngine On 
RewriteCond %{HTTP_Host} ^d-mueller\.de$ [NC] 
RewriteRule ^(.*)$ https://d-mueller.de/$1 [R=301,L] 

Damit landen alle Anfragen (ob nun mit www. oder ohne) bei der www-Variante der Domain. Gleichzeitig wird der Statuscode 301 gesetzt, was soviel wie moved permanentlybedeutet.

weiteres Mod-Rewrite Beispiel

Der Vollständigkeit halber sei noch ein Weiterleitungs-Beispiel mit mod rewrite angebracht, welches „statische“ URL’s suggeriert, obwohl im Hintergrund ein PHP-Script arbeitet. Die Bedeutung von statischen URL’s ist bei google höher gewichtet, außerdem gibt man einen weniger tiefen Einblick in die Dateistruktur der Website und die URL’s sind leichter zu merken.

RewriteEngine On 
RewriteBase /meineWebanwendung/ 
RewriteRule ^profil/([0-9]+)/$ showUserProfile.php?userid=$1 

Die RewriteBase definiert das Unterverzeichnis auf dem Server, für das die Regel gilt. Ob die .htaccess in der Wurzel oder im Unterverzeichnis selbst liegt, ist hierbei unbedeutend, die .htaccess könnte also im Unterordner /meineWebanwendung/ oder in der Wurzel selbst liegen. Erreicht wird eine Weiterleitung von http://www.domain.com/meineWebanwendung/profil/3/ auf http://www.domain.com/meineWebanwendung/showUserProfile.php?userid=3. So kann wird also im „Hintergrund“ konventionell die verarbeitende .php-Datei angesteuert, obwohl der Benutzer o.g. „wohlgeformte“ URL besucht. Die Wildcard ist hierbei auf Zahlen beschränkt, sodass nur Zahlen in der URL zu beschriebener Weiterleitung führen. Weitere Anwendungsbeispiele für mod rewrite gibt es hier.

Ende

Abschließend sei darauf hingewiesen, dass sich alle hier aufgeführten htaccess-Konfigurationsmöglichkeiten beliebig miteinander kombinieren lassen. Bei Kritik und Anmerkungen zu diesem kurzen Abriss bitte ich um eine e-Mail. Weiterführende Links, die zu den einzelnen Themen mehr in die Tiefe gehen und sich auch mit dem Thema .htaccess und Weiterleitungbeschäftigen, sind

1. http://www.corz.org/serv/tricks/htaccess.php
2. http://wwwuser.gwdg.de/~mreiman1/wwwserver/htaccess-gwdg.html
3. http://www.jendryschik.de/wsdev/weiterleitung/

Weitere Posts:

• UTF-8 für PHP-Programmierer und Webanwendungen
• Der Einfluss von Cookies auf die Performance einer Webseite
• Zip-Archive entpacken mit Javascript
• PHP-Includes visualisieren mit Inclued
• Angriffe auf Webanwendungen – Teil 2: Session-Highjacking und Session-Fixation