.htaccess: Tricks Regeln für ihre Website

Die Webserver-Konfigurationsdatei .htaccess ist eine der wichtigsten Dateien ihrer Website-Installation. Viel kann diese oftmals noch unterschätzte Datei leisten. Sie kann zu einem wahren Performance-Schub einer Website ebenso beitragen, wie zu erhöhter Sicherheit. Immer wieder werden WordPress-Websites gehackt, weil kein Augenmerk auf die Sicherheit der Website gelegt wird. In diesem Artikel stelle ich meine eigene .htaccess-Datei vor, die ich im Laufe der Zeit immer weiter verfeinert und optimiert habe.

Die Tricks

Die Vorbereitung

Zuerst einmal muss die Datei gefunden werden. Der folgende Screenshot zeigt, wo die Datei liegt. Regelmäßig sollte sie sich im Hauptverzeichnis ihrer WordPress-Installation finden lassen, also dort, wo die Ordner wp-content, wp-admin usw. liegen.

Der Speicherort der .htaccess-Datei

Ganz wichtig ist es, vor dem Bearbeiten der .htaccess Datei ein Backup selbiger zu erstellen. Dazu kopiere die Datei einfach in einen neuen/anderen Ordner.

Eine Besonderheit unter Mac OS X: Der Mac sieht alle Dateien mit einem Punkt vor dem Dateinamen als Systemdateien an, also auch die .htaccess. Das bedeutet, dass er sie ausblendet, sobald man sie etwa auf den Desktop gezogen hat. Abhilfe schafft hier das kleine Dashboard Widget Hidden Files, mit dem man nach Belieben die versteckten Dateien ein- und wieder ausblenden kann.

Nach jeder Änderung an der .htaccess-Datei muss ein Refresh des Browsers durchgeführt werden, um feststellen zu können, ob die Webseite noch erreichbar ist. Schon bei nur einem fehlerhaften Zeichen wird die betreffende Webseite nicht mehr angezeigt werden. Die .htaccess ist sehr empfindlich. Sollte ihre Webseite also nicht mehr darstellbar sein, lade bitte die Backup-Version wieder hoch. Das behebt den Fehler zumeist augenblicklich.

Die nun folgenden Code-Schnipsel füge bitte einfach an das Ende der .htaccess an.

Teil 1: Browser-Caching aktivieren

Kaum eine andere Tuning-Maßnahme bringt mit so wenig Aufwand so viel Ergebnis. Viele der größten Dateien ihrer Webseite ändern sich im Grunde genommen nie. Deshalb ist es eine gute Idee, diese für eine lange Zeit in den Browser-Cache zu befördern. Dateien, wie zum Beispiel das CSS oder das JavaScript einer Webseite, werden dann nur beim ersten Besuch einmal vom Browser geladen. Bei jedem weiteren Besuch (oder aber auch beim Aufruf weiterer Seiten beim ersten Besuch) muss der Browser diese Dateien nicht mehr laden. Dementsprechend wird die Webseite viel schneller angezeigt.

Dateien, die sich im Allgemeinen eher selten ändern, zum Beispiel JavaScripts, bekommen einen weit in der Zukunft definierten Cache-Header. Feeds hingegen werden nur eine Stunde gecached, fast alle anderen Dateien hingegen einen Monat. Zu beachten ist, dass in der Datei statische HTML-Seiten für eine schnellere Auslieferung für eine Stunde (3.600 Sekunden) in den Speicher befördert werden. Wer das nicht möchte, setzt stattdessen ein “access plus seconds” ein.

Wichtig zu erwähnen ist, dass ein keep-alive-Header gesendet wird. Das erlaubt dem Browser das gleichzeitige Laden mehrerer Dateien und sorgt für einen weiteren Performance-Schub.

Bitte beachten: Da auch das CSS zwischengespeichert wird, sollte man, wenn man öfter etwas daran ändert, entweder die Datei nach einer Änderung umbenennen, oder eine Versionierung implementieren. Ich bevorzuge die zweite Lösung, die ein Teil eines zukünftigen Artikels sein wird.

# ----------------------------------------------------------------
# Belässt die Dateien, die sich selten oder gar nicht ändern, für eine bestimmte Zeit im Browser-Cache
# ----------------------------------------------------------------
## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"
</IfModule>
## EXPIRES CACHING ##

Teil 2: Die komprimierte Auslieferung der Dateien

Viele Vorschläge für .htaccess Dateien, die im Netz zu finden sind, sind nur rudimentär und unvollständig. Alle denkbaren und wichtigen Datei-Formate werden durch meine .htaccess komprimiert ausgeliefert, damit ein wirklicher Geschwindigkeitsvorteil entsteht.

# Komprimierung
# ----------------------------------------------------------------
<IfModule mod_deflate.c>
# Insert filters / compress text, html, javascript, css, xml:

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/vtt
AddOutputFilterByType DEFLATE text/x-component
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/js
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
AddOutputFilterByType DEFLATE application/atom+xml
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE application/ld+json
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-web-app-manifest+json
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
# Exception: Images
SetEnvIfNoCase REQUEST_URI \.(?:gif|jpg|jpeg|png|svg)$ no-gzip dont-vary
# Drop problematic browsers
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
</IfModule>
#Alternative caching using Apache's "mod_headers", if it's installed.

#Caching of common files - ENABLED
<IfModule mod_headers.c>
<FilesMatch "\.(ico|pdf|flv|swf|js|css|gif|png|jpg|jpeg|txt)$">
Header set Cache-Control "max-age=2592000, public"
</FilesMatch>
</IfModule>
<IfModule mod_headers.c>
  <FilesMatch "\.(js|css|xml|gz)$">
  Header append Vary Accept-Encoding
  </FilesMatch>
</IfModule>
# Set Keep Alive Header
<IfModule mod_headers.c>
  Header set Connection keep-alive
</IfModule>
# If your server don't support ETags deactivate with "None" (and remove header)
<IfModule mod_expires.c>
  <IfModule mod_headers.c>
  Header unset ETag
  </IfModule>
  FileETag None
</IfModule>

Teil 3: Allgemeine Sicherheitseinstellungen

Der Grand­sei­g­neur des Webdesigns – Jeff Starr von Perishable Press – feilt bereits seit Jahren an seiner Blockliste für die .htacce ss. Die neueste Version seiner Firewall, die 7G, ist ein Manifest der Sicherheit und wird gerne durch einige WordPress-Security-Plugins kopiert, weil sie so effektiv ist. Sie schützt unter anderem vor Cross-Site-Scripting und Schadcode-Implementierung über die Erweiterungen von URLs. Hackversuche werden trotz des minimalen Codes wirkungsvoll unterbunden und der Code arbeitet sehr effektiv.

# 7G FIREWALL v1.2 20190727
# @ https://perishablepress.com/7g-firewall/
# 7G:[QUERY STRING]
<IfModule mod_rewrite.c>
	
	RewriteCond %{REQUEST_URI} !(7g_log.php) [NC]
	
	RewriteCond %{QUERY_STRING} ([a-z0-9]{2000,}) [NC,OR]
	RewriteCond %{QUERY_STRING} (/|%2f)(:|%3a)(/|%2f) [NC,OR]
	RewriteCond %{QUERY_STRING} (/|%2f)(\*|%2a)(\*|%2a)(/|%2f) [NC,OR]
	RewriteCond %{QUERY_STRING} (~|`|<|>|\^|\|\\|0x00|%00|%0d%0a) [NC,OR]
	RewriteCond %{QUERY_STRING} (cmd|command)(=|%3d)(chdir|mkdir)(.*)(x20) [NC,OR]
	RewriteCond %{QUERY_STRING} (fck|ckfinder|fullclick|ckfinder|fckeditor) [NC,OR]
	RewriteCond %{QUERY_STRING} (/|%2f)((wp-)?config)((\.|%2e)inc)?((\.|%2e)php) [NC,OR]
	RewriteCond %{QUERY_STRING} (thumbs?(_editor|open)?|tim(thumbs?)?)((\.|%2e)php) [NC,OR]
	RewriteCond %{QUERY_STRING} (absolute_|base|root_)(dir|path)(=|%3d)(ftp|https?) [NC,OR]
	RewriteCond %{QUERY_STRING} (localhost|loopback|127(\.|%2e)0(\.|%2e)0(\.|%2e)1) [NC,OR]
	RewriteCond %{QUERY_STRING} (\.|20)(get|the)(_|%5f)(permalink|posts_page_url)(\(|%28) [NC,OR]
	RewriteCond %{QUERY_STRING} (s)?(ftp|http|inurl|php)(s)?(:(/|%2f|%u2215)(/|%2f|%u2215)) [NC,OR]
	RewriteCond %{QUERY_STRING} (globals|mosconfig([a-z_]{1,22})|request)(=|\[|%[a-z0-9]{0,2}) [NC,OR]
	RewriteCond %{QUERY_STRING} ((boot|win)((\.|%2e)ini)|etc(/|%2f)passwd|self(/|%2f)environ) [NC,OR]
	RewriteCond %{QUERY_STRING} (((/|%2f){3,3})|((\.|%2e){3,3})|((\.|%2e){2,2})(/|%2f|%u2215)) [NC,OR]
	RewriteCond %{QUERY_STRING} (benchmark|char|exec|fopen|function|html)(.*)(\(|%28)(.*)(\)|%29) [NC,OR]
	RewriteCond %{QUERY_STRING} (php)([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}) [NC,OR]
	RewriteCond %{QUERY_STRING} (e|%65|%45)(v|%76|%56)(a|%61|%31)(l|%6c|%4c)(.*)(\(|%28)(.*)(\)|%29) [NC,OR]
	RewriteCond %{QUERY_STRING} (/|%2f)(=|%3d|$&|_mm|cgi(\.|-)|inurl(:|%3a)(/|%2f)|(mod|path)(=|%3d)(\.|%2e)) [NC,OR]
	RewriteCond %{QUERY_STRING} (<|%3c)(.*)(e|%65|%45)(m|%6d|%4d)(b|%62|%42)(e|%65|%45)(d|%64|%44)(.*)(>|%3e) [NC,OR]
	RewriteCond %{QUERY_STRING} (<|%3c)(.*)(i|%69|%49)(f|%66|%46)(r|%72|%52)(a|%61|%41)(m|%6d|%4d)(e|%65|%45)(.*)(>|%3e) [NC,OR]
	RewriteCond %{QUERY_STRING} (<|%3c)(.*)(o|%4f|%6f)(b|%62|%42)(j|%4a|%6a)(e|%65|%45)(c|%63|%43)(t|%74|%54)(.*)(>|%3e) [NC,OR]
	RewriteCond %{QUERY_STRING} (<|%3c)(.*)(s|%73|%53)(c|%63|%43)(r|%72|%52)(i|%69|%49)(p|%70|%50)(t|%74|%54)(.*)(>|%3e) [NC,OR]
	RewriteCond %{QUERY_STRING} (\+|%2b|%20)(d|%64|%44)(e|%65|%45)(l|%6c|%4c)(e|%65|%45)(t|%74|%54)(e|%65|%45)(\+|%2b|%20) [NC,OR]
	RewriteCond %{QUERY_STRING} (\+|%2b|%20)(i|%69|%49)(n|%6e|%4e)(s|%73|%53)(e|%65|%45)(r|%72|%52)(t|%74|%54)(\+|%2b|%20) [NC,OR]
	RewriteCond %{QUERY_STRING} (\+|%2b|%20)(s|%73|%53)(e|%65|%45)(l|%6c|%4c)(e|%65|%45)(c|%63|%43)(t|%74|%54)(\+|%2b|%20) [NC,OR]
	RewriteCond %{QUERY_STRING} (\+|%2b|%20)(u|%75|%55)(p|%70|%50)(d|%64|%44)(a|%61|%41)(t|%74|%54)(e|%65|%45)(\+|%2b|%20) [NC,OR]
	RewriteCond %{QUERY_STRING} (\\x00|(\"|%22|\'|%27)?0(\"|%22|\'|%27)?(=|%3d)(\"|%22|\'|%27)?0|cast(\(|%28)0x|or%201(=|%3d)1) [NC,OR]
	RewriteCond %{QUERY_STRING} (g|%67|%47)(l|%6c|%4c)(o|%6f|%4f)(b|%62|%42)(a|%61|%41)(l|%6c|%4c)(s|%73|%53)(=|[|%[0-9A-Z]{0,2}) [NC,OR]
	RewriteCond %{QUERY_STRING} (_|%5f)(r|%72|%52)(e|%65|%45)(q|%71|%51)(u|%75|%55)(e|%65|%45)(s|%73|%53)(t|%74|%54)(=|[|%[0-9A-Z]{0,2}) [NC,OR]
	RewriteCond %{QUERY_STRING} (j|%6a|%4a)(a|%61|%41)(v|%76|%56)(a|%61|%31)(s|%73|%53)(c|%63|%43)(r|%72|%52)(i|%69|%49)(p|%70|%50)(t|%74|%54)(:|%3a)(.*)(;|%3b|\)|%29) [NC,OR]
	RewriteCond %{QUERY_STRING} (b|%62|%42)(a|%61|%41)(s|%73|%53)(e|%65|%45)(6|%36)(4|%34)(_|%5f)(e|%65|%45|d|%64|%44)(e|%65|%45|n|%6e|%4e)(c|%63|%43)(o|%6f|%4f)(d|%64|%44)(e|%65|%45)(.*)(\()(.*)(\)) [NC,OR]
	RewriteCond %{QUERY_STRING} (allow_url_(fopen|include)|auto_prepend_file|blexbot|browsersploit|(c99|php)shell|curltest|disable_functions?|document_root|elastix|encodeuricom|exec|exploit|fclose|fgets|fputs|fsbuff|fsockopen|gethostbyname|grablogin|hmei7|input_file|load_file|null|open_basedir|outfile|passthru|popen|proc_open|quickbrute|remoteview|root_path|safe_mode|shell_exec|site((.){0,2})copier|sux0r|trojan|wget|xertive) [NC,OR]
	RewriteCond %{QUERY_STRING} (;|<|>|\'|\"|\)|%0a|%0d|%22|%27|%3c|%3e|%00)(.*)(/\*|alter|base64|benchmark|cast|char|concat|convert|create|encode|declare|delete|drop|insert|md5|order|request|script|select|set|union|update) [NC,OR]
	RewriteCond %{QUERY_STRING} ((\+|%2b)(concat|delete|get|select|union)(\+|%2b)) [NC,OR]
	RewriteCond %{QUERY_STRING} (union)(.*)(select)(.*)(\(|%28) [NC,OR]
	RewriteCond %{QUERY_STRING} (concat)(.*)(\(|%28) [NC]
	
	RewriteRule .* - [F,L]
	
	# RewriteRule .* /7g_log.php?log [L,NE,E=7G_QUERY_STRING:%1___%2___%3]
	
</IfModule>

Teil 4: Wichtige Sicherheitseinstellungen für WordPress

Die allgemeine Beliebtheit des Content-Management-Systems WordPress ist leider der Grund dafür, dass es sich immer öfter den Hackversuchen böswilliger Mitmenschen ausgesetzt sieht. Mit einigen Zeilen Code in der .htaccess kann man dem vorbeugen. Kommt dann noch eine Absicherung des Administrator-Zugangs der Website hinzu, kann man die Site als sicher ansehen, wenn man die Basics wie das rechtzeitige Update von WordPress, Theme und Plugins beherrscht.

a) Schutz des Administrator-Bereichs

Wie man den Admin-Zugang einer WordPress-Website per .htaccess und .htpasswd wirkungsvoll absichert, haben wir bereits beschrieben. Ebenfalls wird die potenziell unsichere XML-RPC-Schnittstelle von WordPress mit diesem Code völlig abgeschaltet. Wer die Schnittstelle nutzen möchte, weil er zum Beispiel mit der neuen WordPress-Desktop-App arbeitet, muss den Bereich des Codes auskommentieren. Das geschieht mit einer vorgesetzten Raute (#) pro Code-Zeile. Die Absicherung des Adminbereichs ist bereits vorbereitet, wenn man diese Form der Sicherheit nicht nutzen möchte, dann kommentieren Sie diesen Bereich aus.

 ----------------------------------------------------------------
# Schutz des Administrator-Bereichs. Wenn der .htaccess/.htpasswd Schutz genutzt werden soll, auskommentieren UND PFAD ANPASSEN
# ----------------------------------------------------------------
#<Files wp-login.php>
#AuthName "Admin-Bereich"
#AuthType Basic
#AuthUserFile ihr/pfad/zur/.htpasswd
#require valid-user
#</Files>

b) Zugriff von außen auf .htaccess Datei verbieten

Damit die wichtige Serversteuerungs-Datei .htaccess keinesfalls von außerhalb des (S)FTP Zugangs erreichbar und damit verändert werden kann, verbieten wir als erstes den Zugriff darauf.

# Zugriff auf .htaccess und .htpasswd verbieten, falls in Benutzung
<FilesMatch "(\.htaccess)">
  Order deny,allow
  Deny from all
</FilesMatch>

c) Bild-Hotlinking verbieten

Das sogenannte Hotlinking von Bildern kann zum echten Problem werden. Hierbei laden andere Menschen die Bilder aus ihrer Webseite nicht herunter, um sie dann anschliessend zu verlinken, sondern es wird nur der Pfad zu ihrem Bild angegeben. Dies kann ihre Webseite verlangsamen und wichtige Bandbreite stehlen. Die externe Verlinkung der Bilder kann man mit dem folgenden Code jedoch ganz leicht verhindern.

Der Platzhalter ihrewebseite.com muss durch die URL ihrer Webseite ersetzt werden. Ganz unten ist der Pfad zu einer Grafik zu finden, die anstatt des verlinkten Bildes angezeigt wird. Diese Grafik kann durch jede andere ersetzt werden.

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?ihrewebseite.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?ihrewebseite.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ http://i.imgur.com/g7ptdBB.png [NC,R,L]

Bitte beachten: Sollte man einen externen Feedanbieter, wie zum Beispiel Feedburner, benutzen, könnte es sein, dass keine Bilder im Feed landen.

d) IP-Adressen dauerhaft bannen

Es kann schon mal vorkommen, dass man spezielle IP-Adressen einfach bannen möchte. Sei es, weil derjenige versucht hat, den Administrationsbereich zu hacken, oder aber, weil er vielleicht nur böswillige (Spam) Kommentare hinterlässt. Wenn man die IP-Adresse desjenigen herausgefunden hat, nutze folgenden Code um ihn für immer, zumindest unter dieser IP-Adresse, auszusperren.

<Limit GET POST>
order allow,deny
deny from 123.456.78.9
deny from 987.654.32.1
allow from all
</Limit>

Bitte beachten: Die IP-Adressen im obigen Code müssen natürlich noch angepasst werden. Diese Änderung gehörte einstmals zum Standard-Repertoire, ist jedoch mit Inkrafttreten der DSGVO deutlich schwieriger umzusetzen, da man IP-Adressen nicht mehr standardmäßig erfassen darf.

e) Include-Only-Dateien blocken

Etliche, wirklich wichtige Dateien sollten niemals zugänglich sein, außer von WordPress selbst. Auch davor kann man sich mit folgendem Code schützen.

Bitte beachten: Für eine WordPress-Multisite-Installation funktioniert der Code nicht.

# Block the include-only files.<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

f) Separate Htaccess schützt den Wp-Content-Ordner

Der WordPress Ordner wp-content ist der wichtigste Ordner, da er ihre Themes, die Plugins und Bilder, gecachte Dateien usw. enthält. Für Hacker ist dieser Ordner das Hauptangriffsziel, deshalb sollte er gut geschützt sein.

Erstelle eine separate .htaccess Datei, füge den folgenden Code hinein und lade die Datei in den wp-content Ordner hoch (www.einewebseite/wp-content/).

Order deny,allow
 Deny from all
 <Files ~ ".(xml|css|jpe?g|png|gif|js)$">
 Allow from all
 </Files>

g) Die XML-RPC Schnittstelle abschalten

Die XML-RPC Schnittstelle in WordPress dient dazu, WordPress mit externen Programmen verwalten zu können; zum Beispiel, um Artikel zu veröffentlichen oder Kommentare zu bearbeiten . Zu den Programmen gehören unter anderem die mobilen Anwendungen für iOS, Android und Co, aber auch die WordPress-Desktopanwendung.

Die Schnittstelle kann aber auch für DDoS-Angriffe genutzt werden, die dafür sorgen, dass ihre Webseite lahm gelegt wird. Mit einem kurzen Eintrag in die .htaccess schaltet man die Schnittstelle komplett ab:

 <Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

Diesen Eintrag sollte man allerdings nur verwenden, wenn ihre Webseite keine Blog-Funktionalität hat, da auch keine Trackbacks mehr durch gelassen werden. Sollten Sie einen Blog betreiben oder ihr WordPress mit mobilen Anwendungen betreiben wollen, nutze den folgenden Code, um die Schnittstelle abzusichern:

<IfModule mod_setenvif.c>
  <Files xmlrpc.php>
    BrowserMatch "Poster" allowed
    BrowserMatch "WordPress" allowed
    BrowserMatch "wp-iphone" allowed
    BrowserMatch "wp-android" allowed
    Order Deny,Allow
    Deny from All
    Allow from env=allowed
  </Files>
</IfModule>

Im Beispiel-Code sind Zeile für Zeile folgende Clients freigegeben:

Nicht benötigte Freigaben gehören zeilenweise entfernt. Neue User-Agents können hinzugefügt und somit freigeschaltet werden.

Teil 5. PHP – Fehlermeldungen unterdrücken

Dies ist ein ganz wichtiger Punkt, denn sobald PHP eine Fehlermeldung heraus gibt, wird damit auch der Dateipfad sichtbar. Sergej Müller schreibt zu diesem Problem:

In WordPress-Blogs ist es recht simpel, einen PHP-Fehler (indirekt) zu erzeugen, um an die Fehler-Ausgabe inklusive Pfad heran zu kommen. Dafür muss man weder Administrator noch Experte sein. Durch einen direkten Aufruf bestimmter WordPress-Core- wie Plugins-Dateien in der Adresszeile des Browsers werden PHP-Fatal-Fehler generiert (weil notwendige und referenzierte WordPress-Funktionen fehlen).Erlauben Server- bzw. PHP-Einstellungen die Darstellung von Fehlern, erscheinen Fehler der Anwendung im Browser. Kaum jemand kann etwas mit der Fehlerausgabe anfangen, für Angreifer ist es jedoch eine sehr wertvolle Information, um nach Hintertüren zu suchen und diese auszunutzen.

Mit einem simplen Eintrag in der .htaccess Datei löst man das Problem:

php_flag display_errors Off

Download der kompletten .htaccess Datei

Die komplette .htaccess Datei runtergeladen (ZIP, 4kB)

Fazit

Mit dieser .htaccess Datei sind wir schon ziemlich nahe am Optimum. Die Datei ist eine hervorragende Grundlage, in der nur noch einige kleine, seitenspezifische Details ergänzt werden müssen (vermutlich). Mir und meiner Website leistet diese Datei sehr gute Dienste, und, ich hoffe stark, dir auch. Die Datei ist zudem so aufgebaut, dass es keine nervigen Probleme mehr bei Google Page Speed Insights gibt.

.htaccess-Tester prüft Rewrite-Regeln auf ihre Richtigkeit

Das Werkeln an der .htaccess ist nicht jedermanns Sache. Besonders das Umschreiben von URLs mit mod_rewrite bringt oft nicht auf Anhieb das gewünschte Ergebnis. Um die Rewrite-Rules nicht direkt am eigenen Server ausprobieren zu müssen, gibt es den .htaccess-Tester. Über einige wenige Eingabefelder lassen sich Regeln schnell und unkompliziert überprüfen.

Umleitung: Eine der Aufgaben der .htaccess (Bildquelle: Hartmut910 / pixelio.de)

Schnelles Testen von Regeln über eine simple UI

Der spartanischen Oberfläche des .htaccess-Testers reichen drei Eingabefelder. Ins erste Eingabefeld kommt die URL, die getestet werden soll. Ins zweite Feld schreibt man die Regeln, die überprüft werden sollen. Ins dritte Feld gibt man optional einen HTTP-Referer ein.

Oberfläche des .htaccess-Testers

Als Beispiel soll per Umschreibungsregel die Eingabe von robots.txt an eine PHP-Datei weitergeleitet werden. Ins erste Feld schreibe ich also die zu prüfende URL:

http://www.drweb.de/robots.txt

Ins zweite Eingabefeld kommt die zu prüfende Regel, erforderlichenfalls auch mehrere. Bis auf wenige Ausnahmen ist der .htaccess-Tester in der Lage, alle Regeln zu überprüfen. Nur mit Eingaben wie „%{REQUEST_FILENAME}“ kann der Tester noch nicht umgehen. Es wird laut Angaben der Entwickler aber daran gearbeitet, auch solche Problemstellungen in Zukunft abarbeiten zu können. Die Regel unseres Beispiels lautet:

RewriteEngine On
RewriteRule ^robots\.txt$ /robots.php

Der Tester gibt nun die per mod_rewrite umgeschriebene URL aus. In diesem Fall also:

http://www.drweb.de/robots.php

Zusätzlich zur Ausgabe-URL gibt es eine Debugging-Info, die auf Fehler in den Regeln aufmerksam macht oder Hinweise zum Verhalten des Testers gibt. Setzt man beispielsweise das Flag [L], welches dafür sorgt, dass nach dieser Regel keine weiteren Regeln mehr ausgeführt werden, so gibt der Tester einen entsprechenden Hinweis. Denn auch ein falsch gesetztes Flag kann schon mal der Grund dafür sein, dass eine Umschreibung nicht so läuft, wie sie soll.

Fazit: Mit dem .htaccess-Tester lassen sich Umschreibungsregeln sehr schnell und einfach prüfen. Außerdem hilft die Debugging-Info Fehler zu finden. Kenntnisse im richtigen Umgang mit mod_rewrite sind natürlich vorausgesetzt. Denn eine Hilfe zur Erstellung von Regeln bietet der Tester nicht.

PHP und .htaccess: Lesbare URLs mit variablen Verzeichnisnamen

Bei dynamischen Websites, die zum Beispiel mit PHP realisiert werden, wird oftmals eine komplette Website über eine einzige PHP-Datei gesteuert. Dabei werden Variablen als URL-Parameter übergeben und Seiten mit unterschiedlichen Inhalten generiert. So entstehen in der Regel unschöne URLs, die zum einen sehr lang und zum anderen weder für Menschen noch für Suchmaschinen verständlich sind. Mit ein bisschen PHP-Code lässt sich das ändern.

Mit ein paar Zeilen in der .htaccess-Datei lassen sich kurze und prägnante URLs generieren, bei denen Variablen nicht mehr über URL-Parameter sondern als Verzeichnisnamen übertragen werden. Aus

http://www.example.com/index.php?rubrik=leistungen&seite=beratung

wird dann

http://www.example.com/leistungen/beratung/

und suggeriert, dass es sich tatsächlich um Verzeichnisse handelt, in denen die Inhalte der Seite liegen.

Vorteile

Der Vorteil ist zum einen, dass die URLs deutlich kürzer werden. Gerade wenn man URLs beziehungsweise Links per Mail versendet oder gar in gedruckter Form veröffentlicht, ist eine kurze und einprägsame Adresse von großer Bedeutung. Ein weiterer Grund, auf URL-Parameter zu verzichten, liefern Suchmaschinen wie Google selbst. Sie raten davon ab, zu lange URLs zu verwenden, da solche Seiten deutlich schlechter bewertet und demzufolge auch nachrangig berücksichtigt werden bei der Anzeige von Suchergebnissen.

Laut Googles Starter Guide für die Suchmaschinenoptimierung sollten URLs

  1. kurz sein, auf URL-Parameter sowie Session-IDs weitestgehend verzichten,
  2. konkrete Bezeichnungen haben anstatt allgemeiner („leistungen“ statt „seite2“) und
  3. nicht zu viele Unterverzeichnisse besitzen.

Außerdem kann man mit der oben genannten Methode verschleiern, dass eine Website mit PHP programmiert ist. So erschwert man es Hackern, Sicherheitslücken eines Servers bzw. einer serverseitigen Programmiersprache auszunutzen, da die verwendete Programmiersprache nicht ersichtlich ist.

Drei Zeilen in die .htaccess-Datei

Um die Variablenübergabe über Verzeichnisnamen zu steuern, reichen drei Zeilen in der .htaccess-Datei aus:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* /index.php

Die erste Zeile startet die „Rewrite Engine“ von Apache. In der zweiten Zeile wird die Bedingung für die in der dritten Zeile folgende Regel angegeben. Die Bedingung prüft, ob es sich bei der angeforderten Datei tatsächlich um eine existierende Datei handelt.

Achtung: Dies ist jedoch nur möglich wenn im Apache Server das Modul: modrewrite aktiviert ist. Andernfalls verursacht der soeben eingefügte Code einen Fehler und Ihre Webseite bleibt weiß.

Die Bedingung ist erfüllt, wenn es sich nicht um eine Datei handelt. Die Flag „-f“ prüft, ob es sich um eine Datei handelt, „!-f“ prüft – so wie es in dem Beispiel gebraucht wird –, ob es sich nicht um eine Datei handelt:

RewriteCond %{REQUEST_FILENAME} -f # Bedingung erfüllt, wenn es eine Datei ist
RewriteCond %{REQUEST_FILENAME} !-f # Bedingung erfüllt, wenn es keine Datei ist

Die Regel in der dritten Zeile leitet alle Anfragen („.*“), die nicht auf eine existierende Datei verweisen, an die Datei „/index.php“ weiter. Handelt es sich um eine exisitierende Datei (z. B. eine Grafik oder ein PDF-Dokument), so wird diese ganz normal aufgerufen, dargestellt bzw. zum Download angeboten.

Über die PHP-Datei lässt sich dann die URL auslesen und weiterverarbeiten. Alternativ lässt sich die Übergabe der URL-Parameter an die PHP-Date i auch direkt über den Eintrag in die .htaccess-Datei realisieren. Dazu die letzte Zeile der .htaccess-Datei austauschen:

RewriteRule ^([\w]+)/?([\w]+)? /index.php?rubrik=$1&seite=$2

Über die regulären Ausdrücke „([\w]+)“ werden Zeichenketten bestehend aus Buchstaben und Zahlen, die durch einen Schrägstrich getrennt sind, als Variable an die PHP-Datei übergeben. Das Fragezeichen hinter dem Schrägstrich und dem zweiten Ausdruck signalisiert, dass diese Werte optional sind. Das heißt, es kann auch nur ein Wert übergeben werden, und zwar für den Parameter „rubrik“.

Variablen auslesen mit PHP

Wer die erste Variante von „RewriteRule“ nutzt, muss die Variablen „rubrik“ und „seite“ per PHP ,aus der URL auslesen. Damit die „index.php“ die Variablen aus der URL auslesen kann, wird die URL an eine PHP-Variable übergeben:

$url = $_SERVER["REQUEST_URI"];

Die vorderfinierte Variable „$_SERVER[“REQUEST_URI”]“ enthält die URL, über die die PHP-Datei aufgerufen wurde. Im aktuellen Beispiel ist das „/leistungen/beratung/“.

Mit der Funktion „explode()“ wird die URL in ihre Bestandteile zerlegt und als Array weiterverarbeitet:

$url = explode("/", $url);

Da die Zeichenkette „/leistungen/beratung/“ anhand des Schrägstrichs zerlegt wird, werden dem Array in diesem Fall vier Werte übergeben, wobei der erste und der letzte Wert jeweils eine leere Zeichenkette sind, da vor dem ersten und nach dem letzten Schrägstrich keine Zeichen stehen.

Die eigentlichen Werte „leistungen“ und „beratung“ befinden sich an Position zwei und drei des Arrays. Sie werden jeweils einer Variablen zugeordnet:

$rubrik = $url[1];
$seite = $url[2];

In der zweiten Variante des „RewriteRule“-Eintrags in der .htaccess-Datei können die URL-Parameter direkt über „$_GET“ ausgelesen werden, ihne die Werte aus der URL zu extrahieren:

$rubrik = $_GET["rubrik"];
$seite = $_GET["seite"];

Wird nur ein Verzeichnis angeben (z. B. „/leistungen/“), so bleibt die Variable „$seite“ leer. Was nicht funktioniert, ist die Übergabe eines Wertes nur für die Variable „$seite“, da der erste Verzeichnisname immer der Variablen „$rubrik“ zugewiesen wird.

Ausnahmen festlegen

Möglicherweise will man nicht alle URL-Anfragen an die index.php weiterleiten. Das Verzeichnis „downloads“ soll z. B. nicht von der Datei „index.php“ sondern von „downloads.php“ verarbeitet werden. In diesem Fall fügt man nach der ersten Zeile der .htaccess-Datei folgende Zeile ein:

RewriteRule ^downloads$ /downloads.php

Jetzt wird die URL „/downloads/“ an die Datei „downloads.php“ verwiesen und kann von dort verarbeitet werden.

Fazit

Die hier vorgestellte Methode, um URL-Paramter zu übertragen, wird insbesondere von Content-Management-Systemen eingesetzt. Bei TYPO3 sorgt zum Beispiel die Erweiterung RealURL für solche kurzen und suchmaschinenfreundlichen URLs.

Vom Prinzip her arbeitet RealURL genau so wie die hier beschriebene Methode.

Dieser Beitrag wurde zuletzt am 12. Februar 2020 aktualisiert: Update von 6g-Firewall auf 7g-Firewall.


Deprecated: Directive 'allow_url_include' is deprecated in Unknown on line 0