Die ersten – und hoffentlich auch letzten – Spambot-Kommentare auf meiner Seite haben mich dazu gebracht, einen Schutzmechanismus einzubauen um Bots zu hindern, Kommentare zu hinterlassen.

Wenn man von Schutz gegen Spambots spricht, denken einige von euch sicherlich direkt an ein Capcha, also Bild dessen Inhalt man als Benutzer in ein Eingabefeld schreiben muss. Doch gibt es auch alternative Schutzmethoden, die dem Captcha sogar vorzuziehen sind. Diese möchte ich euch in diesem Artikel vorstellen.

Um über die verschiedenen Mechanismen sprechen zu können, müssen wir uns erst einmal wieder überlegen, wovor wir unsere Seite überhaupt schützen wollen: Gegen nervige Kommentare, die nur Werbung ohne Themenbezug oder anderen sinnfreien Inhalt enthalten.

Diese Kommentare können aber von verschiedenen „Seitenbesuchern“ verursacht werden:

Formularausfüllende Bots

Diese Programme scannen den Quellcode des Formulars, füllen automatisch alle Felder mit ihrem eingestellten Werbetext aus und schicken das Formular ab. Dafür benötigen sie im Vergleich zu einem menschlichen Benutzer aber „keine“ Zeit, wodurch wir eine zusätzliche Möglichkeit bekommen, uns vor ihnen zu schützen.

„Abspielende“-Bots

Diese Bots hingegen lesen nicht einmal die Felder des Formulars. Sie suchen nur nach der Ziel-URL, also dem „action“-Attribut des Formulars und senden einen schon fertig konfigurierten Post-Header an diese URL. Dieser Post-Header besteht aus häufig im Internet benutzten Parameternamen (z.B. name, text, url, email) mit Werbetexten als Werten.

Menschliche Benutzer, die nur Werbung für die eigene Seite machen wollen

Diese netten Besucher lesen den kommentierbaren Inhalt gar nicht durch, sondern scrollen direkt zu dem Kommentarformular und fügen ihren Werbetext ein. Dafür brauchen sie ein wenig Zeit, aber nicht so viel, wie ein ehrlicher Besucher.

Die Schutzmechanismen

Nun kommen wir zu den verschieden Schutzmechanismen, die wir benutzen können um einige dieser Besucher fernzuhalten. Wir fangen mit dem wohl bekanntesten an:

Captcha

Ein Script generiert eine Grafik, eine Audiodatei oder einen Text, dessen Inhalt aus Buchstaben und Zahlen besteht. Diesen Inhalt muss der Besucher, der einen Kommentar hinterlassen möchte, wiedergeben indem er ihn in ein nebenstehendes Textfeld schreibt. Das Schützt vor Bots, aber nicht vor menschlichen Störenfrieden. Allerdings gibt es auch Bots, die zum Beispiel den in einem Bild stehenden Text entziffern können. Die Usability wird durch ein Captcha allerdings beeinträchtigt, da es den ehrlichen Besucher Zeit und auch oft Nerven kostet, den Inhalt zu entziffern und fehlerlos in das Textfeld zu schreiben.

Email-Aktivierung

Hierbei muss der Besucher eine gültige Email-Adresse angeben. Bevor der Kommentar dann nach dem Absenden und Speichern tatsächlich auf der Internetseite angezeigt wird, muss der Benutzer sein Email-Postfach öffnen und in der ihm zugesanden Email auf einen Link klicken, der ihn wieder auf die Internetseite führt. Damit wird bestätigt, dass es sich um einen Mensch handelt, der den Kommentar schrieb, also werden auch hier wieder beide Arten Bots von der Kommentarfunktion ausgeschlossen. Doch auch hier wird dem ehrlichen Besucher ein Zeitaufwand zugemutet, was der Usability schadet. (Ich vermute, dass es auch Bots gibt, die ein Email-Postfach auslesen und auf den Link klicken können.)

Admin-Aktivierung

Alle Kommentare müssen von dem Admin der Internetseite aktiviert werden, bevor sie angezeigt werden. Das ist jedoch bei einer gut besuchten Internetseite kaum umsetzbar, da man als Admin nicht die Zeit hat, alle paar Minuten – oder noch häufiger – einen Kommentar zu überprüfen und zu aktivieren. Das endet meist darin, dass die Antwortzeit bei Diskussionen in den Kommentaren extrem groß wird. Es ist also keine zu empfehlende Variante.

Inhaltliche-Abfrage

Bevor der Benutzer seinen Kommentar absenden kann, muss er einen Multiple-Choice-Test bestehen, der den Inhalt der kommentierbaren Seite abfragt. Diese Methode ist bei der richtigen Anwendung besonders effektiv gegen unerwünschte menschliche Besucher. Bots haben eine gewisse Chance den Test zu bestehen.

Zeitsperre

Es wird ein Hidden-Field in das Formular generiert, das den Zeitpunkt der Generation als Timestamp enthält. Nachdem das Formular abgesendet wurde, wird die verstrichene Zeit ermittelt. Dem Formular wurde von Anfang an vom Admin eine Zeit zugewiesen, die ein flinker Besucher zum Ausfüllen des Formulars braucht. Wenn nun die gemessene Zeit niedriger ist, als die erwartete, wird das Formular nicht entgegen genommen. Doch bei dieser Variante können einige Probleme auftreten:

• Der Admin verschätzt sich beim Angegeben der Zeit und schnelle Besucher werden abgewiesen.
• Wenn die Zeit konstant festgelegt ist, könnte Bots die Zeitsperre umgehen, indem sie warten, oder das Hidden-Field manipulieren.

Von der Zeitsperre gibt es noch andere Variationen. Zum Beispiel, dass nur ein Kommentar innerhalb einer gewissen Zeit erlaubt ist, oder dass der Submit-Button des Formulars erst nach einer gewissen Zeit erscheint oder aktiviert wird (per JavaScript).

JavaScript

Für das Benutzen des Formulars wird bei dieser Variante JavaScript vorausgesetzt. Einige Beispiele dafür sind, dass wichtige Teile, oder das gesamte Formular per JavaScript generiert werden. Bots haben aufgrund der zu langen Rechenzeit von JavaScript meist keinen JavaScript-Interpreter an Bord, weshalb sie dann gar nicht erkennen, dass auf der Seite ein Formular vorhanden ist. Die Accessibility wird hierdurch jedoch stark eingeschränkt, da Browser ohne JavaScript oder Screenreader die Formulare nicht darstellen können.

Honeypot-Captcha

Es ist ungefähr das Gegenteil des normalen Captchas: Es gibt ein Formularfeld, was nicht ausgefüllt werden darf, aber einen üblichen Namen, wie „url“ oder „email“ trägt. Da formularausfüllende Bots alle Felder ausfüllen, die sie finden, treten sie hier in eine Falle, wie eine Biene, die in ein Honigglas fliegt und darin festklebt. Für normale Besucher wird das Formularfeld per Stylesheet unsichtbar gemacht, sodass sie gar nicht die Möglichkeit bekommen, es ausversehen auszufüllen. Für Browser mit deaktiviertem Stylesheet wird über das Formularfeld noch ein Hinweis geschrieben, das Feld bitte nicht auszufüllen. Es darf nur nicht der Fehler gemacht werden, das Feld in irgendeiner Form so zu benennen, dass es für die Bots möglich ist den Honeypot zu erkennen, denn sonst werden die Programmierer ihren Bots sehr schnell beibringen können, diese Felder nicht auszufüllen. Glücklicher Weise wird hier die Usability überhaupt nicht beinträchtig, da ein normaler Besucher gar nichts von der Schutzmethode bemerkt.
Dies ist übrigens auch die Variante, dich ich für diese Seite benutze.

Zusatz: Ich habe festgestellt, dass ein Honeypot nur dann wirkt, wenn das Formular nicht zusammen mit dem vom Honeypot geschmissenen Fehler angezeigt wird.

Besonders um vor den „Abspielenden“-Bots zu schützen gibt es noch eine etwas komplexere Variante:

Dynamische Feldbenennung

Hierbei werden die Formularfelder nicht wie sonst mit verständlichen Namen versehen, sondern mit verschlüsselten oder zufällig generierten Namen benannt. Zum Beispiel „user_123ajr35f0s?__“. Es gibt nur ein einziges verstecktes Feld, in dem der Schlüssel für die kryptische Benennung der anderen Felder übergeben wird. Bei der Entgegennahme des Formulars können die Felder anhand dieses Schlüssels zugeordnet werden. Dadurch wird verhindert, dass das Formular mit einem fertigen Post-Header benutzt werden kann.

Spam-Melden

Es wird darauf vertraut und gehofft, dass die Besucher der Seite darauf achten ob unerwünschte Beiträge in den Kommentaren stehen und diese dann per Button an den Admin melden, sodass dieser sie löschen kann. Diese Funktion reicht zwar meist alleine nicht aus aber lässt sich gut in Kombination mit anderen Methoden verwenden.

Zu guter letzt gibt es noch eine etwas größere Lösung zum Schutz vor nicht gewünschten Kommentaren:

Der Datenbankabgleich

Hierzu wird jeder Kommentar mit einer Datenbank verglichen bevor er gespeichert wird. In der Datenbank befinden sich gesammelte, als „schlecht“ markierten, Kommentare von mehreren Internetseiten. Wenn der entgegengenommene Kommentar in der Datenbank wiedergefunden wird, wird er nicht gespeichert. Jeder Admin, der diese Datenbank zum Filtern seiner Kommentare benutzt, kann auch Kommentare seiner eigenen Seite als „schlecht“ markieren und damit in die Datenbank hinzufügen. Ein Beispiel für so ein Script zum Datenbankabgleich ist Akismet, was seit einiger Zeit auch bei Wordpress als Standard mit ausgeliefert wird.

Ich hoffe, dass ich keine wichtige Möglichkeit des Schutzes gegen ungewünschte Kommentare vergessen habe und es für euch interessant war, ein paar eher unbekanntere Methoden kennen zu lernen. Natürlich lassen sich die Methoden auch beliebig miteinander kombinieren um eine noch höhere Sicherheit zu erreichen.