In den Boomzeiten von World of Warcraft schossen täglich hunderte neuer Gilden aus dem Boden und verschwanden auch wieder genauso schnell. Das Problem sind meist die Altlasten, Webmaster werden leichtsinnig und hinterlassen auf Ihrem Server noch alte Installationen von Scripten ohne ein Auge darauf zu werfen. Ein Fall hier ist das Dragon Kill Point System eqDKP, diese Punkte werden verwendet um die Aktivität von Spielern in einer Gilde zu belohnen. Schlicht ist es nichts anderes als eine PHP gestützte Datenbank mit Userverwaltung. Leider wiesen Versionen vor 1.3 eine Kritische Sicherheitslücke auf welche es Angreifern erlaubt remote gehosteten Code lokal auszuführen. Genaueres zu den Details findet der interessierte z.B. hier. Sollte es nun in den Fingern jucken um dort beschriebenes mal ausprobieren zu können bitte ich so fair zu sein und betroffene Seiten, sofern man welche findet, davon in Kenntnis zu setzen. Ich habe heute beim 30min suchen 4 Seiten gefunden welche verwundbar waren. Bei drei der 4 war ein Impressum angegeben dort habe ich dem Webmaster wenigstens einen Hinweis per Mail hinterlassen.
Und .htaccess hilft ?
Es gilt wie bei vielen andern Dingen auch, .htaccess ist kein Wunderdoktor, ein total unsicheres System kann auch mit allgemeinen Regeln nicht sicher gemacht werden. Man sollte immer darauf achten das man seine verwendeten Systeme aktuell hält. Denn dazu sich das Amt eines "Webmasters" aufzubürgen gehört eben mehr als nur Klick & Install. Eine angepasste .htaccess bietet einige Möglichkeiten um grobe Lücken zu schließen, wie gesagt; Zurücklehnen sollte man sich aber dennoch nicht.
Einige Beispiele
Im kommenden Abschnitt zeige ich einige nützliche Beispiele auf wie man mit einer angepassten htaccess Datei für ein wenig mehr Sicherheit sorgen kann. Zuerst wird am Beginn der .htaccess Datei die Rewrite Engine eingeschaltet sowie das verfolgen von Symbolic Links eingeschaltet:
# mod_rewrite
RewriteEngine On
RewriteBase /
# could cause problems, try to comment out next line
Options +FollowSymLinks
Um einen Redirect Loop zu vermeiden wird dies als nächstes eingefügt:
Nun beginne ich mit den Einschränkungen / Filtern. Als erstes wird der Zugriff auf gültige HTML Protokolle beschränkt. Dies sind HTTP/0.9, HTTP/1.0 und HTTP/1.1, der Rest ist nicht valide folglich kein Browser und hat auf der Seite nichts zu suchen.
Eine weitere Limitierung ist das Filtern von nicht sicheren Request Methoden. Das HTTP Protokoll beherrscht neben GET und POST viele weitere Anfrage Möglichkeiten. In der Regel stellt dies kein Problem dar weil der Webserver bereits entscheidet das ein PUT oder DELETE von einem nicht authentifiziertem User nicht zulässig ist. Liegt hier jedoch eine Fehlkonfiguration oder auch ein Bug vor kann es gefährlich werden. Wenn man nicht mit WebDAV arbeitet kann man unsichere Request Methods direkt blockieren.
Als nächstes werden POST Requets, also Anfragen die in der Regel von Forms auf der Webseite ausgehen, welche kein USERAGENT enthalten geblockt. Der HTTP_USER_AGENT ist quasi der verwendete Browser des Users. Identifiziert dieser sich nicht ist etwas fault. Solche Agents können durch die Limitierung auf POST nach wie vor auf der Webseite surfen aber keine Forms submitten. Also z.b. leidiger Gästebuchspam oder Fake Account Registrierungen.
# Block POST requests without useragent
RewriteCond %{REQUEST_METHOD} =POST
RewriteCond %{HTTP_USER_AGENT} ^-?$
RewriteRule .* - [F,NS,L]
Nun gehen wir den oben beschriebenen Sicherheitsaspekt der INJECTION an. Auch XSS (Cross Site Scripting) genannt. Hier werden in Fehlerhafte Programme wie Foren fremde Quelltexte importiert und ausgeführt. Da dies nur GET, POST und auch HEAD requests betrifft werden auch nur solche überprüft. Der vom Userbrowser übermittelte Abfragestring wird geprüft ob dieser mögliche Links auf externen Content oder script-tags enthält. In einigen fällen in denen man Fremd URLS im Querystring verwendet kann es hier zu Problemen kommen. Im Normalfall ist dies allerdings nicht der Fall.
Ab und an versuchen Angreifer oder schlichtweg neugierige auch über die URL in einigen Scripts zugriff auf Dateien zu bekommen die nicht dafür bestimmt sind. Hierzu wird in den nächsten beiden Regeln a) die Verwendung von URLs nach dem Schema webseite.de/dokumente/../admin/user.txt b) Zugriff auf einige bekannte Installations / Konfigurations Dateien
Etwas anderes das ich regelmäßig zur htaccess hinzufüge ist ein Code welche Benutzer auf die Webseite mit www. davor umleitet. Also komme ich auf http://solariz.de werde ich unbemerkt umgeleitet auf http://www.solariz.de dies stellt sicher das die Seite nicht unter verschiedenen URLs verbreitet wird. Vorsicht jedoch hierbei! Ist die eigene Seite nicht auf einer Toplevel Domain gehosted sonder über eine Subdomain erreichbar wie z.b. meineseite.wasauchimmer.net so darf folgender code nicht verwendet werden.
Ein weiterer Punkt der bei mir regelmäßig Verwendung findet ist das blocken von speziellen User Agents, nämlich Bots und Crawler. Im web werden Webseiten beinahe minütlich von sogenannten Crawlern besucht. Einige davon sind gut andere möchte man nicht haben. Als gutes Beispiel sind z.B. Suchmaschinen zu nennen, diese besuchen Seiten und indizieren Schlagwörter von diesen um sie später in der Suche durchsuchen zu können. Böse dagegen sind Leechbots oder Emailcrawler die versuchen Bilder / Dateien oder emailadressen auf der Seite zu “klauen”. In erster Linie ist die Webseite für Menschliche Besucher, sekundär für Suchmaschinen Spiders. Daher blocke ich mir bekannte unerwünschte Crawler/Bots direkt bevor Schaden angerichtet werden kann. Hierzu möchte ich anstatt hier Regeln für die htaccess zu posten auf einen anderen Beitrag in meinem Blog verweisen, dort wird detaillierter auf dieses Thema eingegangen. Zu finden ist dieser hier: /apachetips/killallrobots Das war es soweit auch schon an dieser Stelle. Wer speziell auf XSS Attacken eingehen möchte und auch an Statistiken dazu interessiert ist sollte mal einen Block auf abwehr.solariz.de riskieren.
