Beispiel eqDKP

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:
# Stop Redirect Loops
RewriteCond %{ENV:REDIRECT_STATUS} !^$
RewriteRule .* - [L]
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.
# Valid HTTP Protocol Requests Only
RewriteCond %{THE_REQUEST} !^[A-Z]{3,9}\ .+\ HTTP/(0\.9|1\.0|1\.1) [NC]
RewriteRule .* - [F,NS,L]
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.
# Safe Request Methods Only
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST|PROPFIND|OPTIONS)$ [NC]
RewriteRule .* - [F,NS,L]
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.
# Block some injection trys through Query String
RewriteCond %{REQUEST_METHOD} =GET [OR]
RewriteCond %{REQUEST_METHOD} =POST [OR]
RewriteCond %{REQUEST_METHOD} =HEAD
RewriteCond %{QUERY_STRING} (ftps?|https?):// [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC]
RewriteRule .* - [F,NS,L]
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 Regelna) die Verwendung von URLs nach dem Schema webseite.de/dokumente/../admin/user.txtb) Zugriff auf einige bekannte Installations / Konfigurations Dateien
# Block directory traversal Requests trying to get .. or /.. stuff
RewriteCond %{QUERY_STRING} (\.\./|/\.\.|\./\.)
RewriteRule .* - [F,NS,L]
# Block INSTALL.php requests
RewriteCond %{REQUEST_URI} (install|setup|config|configure)\.php [NC]
RewriteRule ^(.*)$ index.php [F,L]
 Block Access to svn directorys
RewriteCond %{REQUEST_URI} \.svn [NC]
RewriteRule .* - [F,NS,L]
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.
# Redirect to www.*
RewriteCond %{HTTP_HOST} !^www\.[a-z-]+\.[a-z]{2,6} [NC]
RewriteCond %{HTTP_HOST} ([a-z-]+\.[a-z]{2,6})$     [NC]
RewriteRule ^/(.*)$ http://%1/$1 [R=301,L]
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/killallrobotsDas 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.

Amazon Logo Diesen Blog unterstützen?
Bestell dir doch etwas bei Amazon. Nutze diesen speziellen Link, es kostet dich nichts extra und für jeden Kauf darüber erhalte ich eine kleine Gutschrift. Danke!
✉ Marco Götze//

Kommentare

Formate: | Größe: Mb
Anmelden mitoder Benutzernamen eingeben

Daniela
Vielen Dank für diese Sammlung.

Ein Problem habe ich jedoch mit dem folgenden Eintrag:

# Valid HTTP Protocol Requests Only
RewriteCond %{THE_REQUEST} !^[A-Z]{3,9} .+ HTTP/(0.9|1.0|1.1) [NC]
RewriteRule .* - [F,NS,L]

Da kommt es bei mir zu einem Syntax-Fehler in der .htaccess (Error 500). Bislang bin ich noch nicht dahinter gekommen worin genau der Fehler liegt. Hast du da eine Idee?
Daniela
Vielen Dank für diese Sammlung.Ein Problem habe ich jedoch mit dem folgenden Eintrag:# Valid HTTP Protocol Requests OnlyRewriteCond %{THE_REQUEST} !^[A-Z]{3,9} .+ HTTP/(0.9|1.0|1.1) [NC]RewriteRule .* - [F,NS,L]Da kommt es bei mir zu einem Syntax-Fehler in der .htaccess (Error 500). Bislang bin ich noch nicht dahinter gekommen worin genau der Fehler liegt. Hast du da eine Idee?
hoffmann
man merkt das du ein kennner bist.. echt klasse
hoffmann
man merkt das du ein kennner bist.. echt klasse
solariz
Danke für den Hinweis, habe das mal aktualisiert.

Wenn du noch nicht kennst schau mal auf abwehr.solariz.de finde die Statistiken sehr interessant ;)

Gru&szlig;
★Marco Gö†ze
Danke für den Hinweis, habe das mal aktualisiert.Wenn du noch nicht kennst schau mal auf abwehr.solariz.de finde die Statistiken sehr interessant ;)Gruß
René
Vielen Dank. Ich habe einige Zeit nach genau diesen Infos gesucht (zumindest einen Teil davon ;-)). Mir gingen diese ganzen XSS-Versuche powered by Russland für ein anderes CMS so tierisch auf den Zeiger. Wenn ich mir angucke, wieviele gehackte Server nur allein bei mir in den Logs aufschlagen&hellip; gruselig.

Btw. die beiden letzten Links (apachetips/killallrobots und Download Textdatei) führen leider beide ins Leere.
René
Vielen Dank. Ich habe einige Zeit nach genau diesen Infos gesucht (zumindest einen Teil davon ;-)). Mir gingen diese ganzen XSS-Versuche powered by Russland für ein anderes CMS so tierisch auf den Zeiger. Wenn ich mir angucke, wieviele gehackte Server nur allein bei mir in den Logs aufschlagen… gruselig.Btw. die beiden letzten Links (apachetips/killallrobots und Download Textdatei) führen leider beide ins Leere.