Spam und anderes Gemüse

Jeder, der ein Formular ins Web stellt muss mit Missbrauch desselben rechnen. Dieser Artikel möchte erörtern, welche Massnahmen gegen automatisiertes Befüllen im eHome-Factory CMS überhaupt sinnvoll sind.

Definition

Spam ist jede Art von Beitrag, welchen Sie nicht wünschen. Spam ist nicht reduziert auf automatisierte Prozesse wie Spam-Bots. Auch ein normaler menschlicher Troll kann spamen. Anderseits kann es Situationen geben, wo automatisierte Behandlung der GUI sogar erwünscht ist1.

Eines der grössten Missverständnisse beruht darin zu glauben, Userinteraktion von automatisierter Aktion unterscheiden zu können. Das ist schlicht nicht möglich und so auch nicht notwendig. Menschen brauchen für das Internet User-Agents. Der menschliche Akt beruht in einer Klickrate, die Requests auslösen kann, und im Falle eines Postings im besten Fall in Inhalt, der analysiert werden kann. Alles was man tun kann, ist Content an seinem menschlichen Gehalt zu beurteilen. Dies aber bringt die Problematik der Definition des Menschlichen mit sich.

Zweierlei Arten von Definitionen

Formulare werden nicht auschliesslich zum Zweck von Spam missbraucht. Oftmals sind sie die Schnittstelle, um bekannte Exploits in Software auszubeuten. Dies soll nicht Thema des Artikels sein. Die serverseitige Validierung von Userinput setze ich stillschweigend voraus. Ich betone jedoch, dass ein POST von Daten nicht auf ein Formular angewiesen ist. Sofern man das Design des Formulars als Teil der Spamabwehr einbezieht, sollte man sich dessen bewusst sein.

Gängige Massnahmen

Formular-Instanz authentifizieren

Gängige Massnahmen sollen verifizieren, dass Eingaben in einer aktuellen und authentischen Formular-Instanz getätigt wurden. Man will dabei verhindern, dass ein Formular lokal gespeichert und die gleichen oder variierte Eingaben aus dieser Instanz erfolgreich gepostet werden künnen.
Erreicht werden kann dies durch mehrere Massnahmen.

Einer der ersten Fehler bei Formularen besteht darin, dass sie als statischer Content abgerufen werden können, und das Senden bereits zu einer regulären Formular-Verarbeitung führt. Während nichts dagegen spricht, dass man Formulare als Templates auf dem Server verwendet, ist doch diese Freiheit über ein instanzloses Formular äusserst schlecht.

Formular-Parsen erschweren

Weitere gängige Massnahmen dienen dazu, verschiedene Arten des Formular-Lesens auszunutzen. Ein Useragent oder Robot wird sich eher an Feldnamen orientieren, der Anwender hingegen an Feldbeschriftungen. Dies eröffnet die Möglichkeit, den Agent mit funktionslosen Feldern und anonymisierten Feldnamen zu konfrontieren. Die Erfolgsquote solcher Abwehr nimmt jedoch immer mehr ab und ist die zusätzliche Komplexität auf der Applikationsseite kaum wert, denn für jedes anonymisierte Feld muss auf der Serverseite wieder ein Schlüssel gelogged werden, welcher den anonymen Feldnamen mit der Feldfunktion verbinden kann.

Plausibilitätsprüfung der Bedienung

Es gibt nur wenige Möglichkeiten, die mehrstufige Formular-Behandlung zu plausibilisieren. Ein Bot braucht kaum Zeit, sich in einem Formular zu orientieren. Er kann sofort füllen und sofort senden. Dies ist ein Ansatzpunkt: Prüfe, ob zwischen der Anforderung des Formulars und dem Post eine minimale Zeit vergangen ist.
Wie soll nun die minimale Zeit bemessen sein? Die Zeit, die ein User braucht, kann sehr verschieden sein, je nach dem, ob er das Formular bereits kennt, oder es erst kennenlernen muss. Ein Textfeld verlangt keine besondere Zeit zur Befüllung, wenn der Anwender ganz legitim seinen Text in einer anderen Datei vorbereitet und lediglich via Copy-Paste eingefügt hat. Wiederum gilt: Browser können beim Befüllen assistieren und z.B. Name und Passwort vorbelegen. Der User muss nur noch den Senden-Button bedienen. Das macht diese Art der Prüfung sehr kontextabhängig. Die minimale Zeit verringert sich drastisch. Eine Sekunde pro Feld kann bereits einen legitimen User blockieren. Viele Spambots kennen zudem diese Falle, und deshalb dürfte sie nicht sehr effizient sein.

IP-basierte Sperren und Kontingente

Weitere Massnahmen versuchen zwar nicht, Spam zu verhindern, aber seine Masse einzuschränken. Dazu gehört die Annahme, dass eine User-Session über den Verlauf der Session konstant innerhalb eines IP/24-Bereichs bleibt2. Sofern man dem User innerhalb einer Frist genau einen erfolgreichen Eintrag zugesteht, ist eine wirkungsvolle Bremse möglich. Diese Massnahme muss aber dann versagen, wenn ein Spambot über viele IPs verfügt. Die Massnahme ist strikt auch begrenzt auf Situationen, wo vom ersten Verlangen des Formulars bis zu seinem letzten Submit nicht viel Zeit vergeht.

Content-basierte Analysen

Hierzu zählt der Test auf duplizierten Inhalt. Dies ist jedoch ein aufwändiges Verfahren mit wenig Chancen auf Erfolg, da Spammer automatisiert hinreichend variierten Content senden können, um solche Tests zu bestehen. Am erfolgreichsten dürfen noch Filter sein, welche auf der Basis von Tokens den Inhalt analysieren und bewerten (Bayes-Filter, Markov-Filter). Ein Spammer sieht im Gästebuch Information, wie er seine Mails gestalten kann, um einen Bayes-Filter zu passieren. Im E-Mail-Vekehr ist dies für ihn schwieriger, weil er die Besonderheit der Standard-Mails eines Empfängers nicht kennt.
Content basierte Filter haben eine rechtliche Relevanz. Content-Filter dürfen beim End-Empfänger angewendet werden oder beim Betreiber des Formulars, der mit den Empfängern kommuniziert. Content-Filter sind aber rechtlich problematisch auf der Ebene von Mail-Delivery-Servern oder auch von Organisationen.

Heuristische Ansätze

Ein naiver Ansatz, der auf Bayes-Filter verzichtet, sucht nach sensiblen Worten. Davon ist in der Regel abzuraten mit einer Ausnahme: In Gästebüchern haben es Spammer primär auf Links abgesehen. Allerdings ist die Zahl der Massenlink-Postings eher am Abnehmen, da die Filterung nach Zahl der Links sich allgemein etabliert hat.
Der heuristische Ansatz bewertet Merkmale. Als solche kommen in Frage: Wann wurde unter dieser IP das letzte Mal gepostet, welche Sprache wird gesprochen, wieviele Links, User-Agent etc....
Damit normale Autoren nicht bestraft werden, ist es ein Bonus/Malus-System. Insgesamt dürfte es hier schwierig sind, eine effiziente Mischung überhaupt zu erreichen. Die Anzahl der Kontrollen ist so gross, so dass man gleich einen Bayes-Filter trainieren kann.

Freischaltung / Sichtung

Wenn alles versagt, bleibt nur die Sichtung von Beiträgen, bevor sie entweder publiziert werden (z.. Guestbook) oder weiter verarbeitet werden (z.B. Mail).
Gerade diese Sichtung ist aber nicht erwünscht bei Massenbeiträgen und hilft also nur, um eine menschliche Qualitäts­prüfung bei nicht automatisierten Beiträgen zu ermöglichen.

Unterschiede Gästebücher, Blogs, Formmailer, Account-Registrierung

Eine Methode muss sich dem Potential des Missbrauchs anpassen. Accounts sollten zum Beispiel pro User nur einmal erstellt werden können. Hier haben wir keinen grösseren Text zu parsen, sondern viele Einzelangaben zu validieren. Eine einfache aber auch einschränkende Methode ist die Abhängigkeit der Freischaltung eines Accounts von einem E-Mail-Account, an welchen das generierte Passwort gesendet wird. Dies schreckt jedoch einen Automaten nicht ab. Vielmehr ist es bei Accounts angesagt, die Aktivität zu kontrollieren. Wie werden Beiträge durch einen User beurteilt? Erlaubt der Account das Versenden von Mails? Gibt es einen ungewöhnlichen Betrieb hier?
Blogs und Gästebücher bieten verschiedene Interessen für Spammer. Blogs sind weit interessanter, da sie oft durch Google gut indexiert sind. Gästebücher findet man eher selten und nicht gut platziert bei Google, denn es fehlt ihnen an einem eigenen Contentprofil mit Überschriften. Ein Blogger muss demnach seine Seiten anders schützen. Hier sei an das Schliessen des Formulars nach einer begrenzten Aktivitätsfrist erinnert.
Blogs und Gästebücher erlauben es dem Spammer, den Content an die bestehende Norm anzupassen. Das macht Contentfilterung nur mit gut trainierten Bayes-Filtern effizient. Bei einem Formmailer bleibt der Spammer aber gänzlich in Unkenntnis über normale Mailinhalte des Empfängers. Hier wird er sich viel eher an den üblichen Mailtext-Durchschnitt halten. Gängige Mail-Useragents haben heute einen Bayes-Filter an Bord. Sie sind viel effizienter, den Spam zu erkennen. Eine Formmailer-Mail wird sehr wahrscheinlich nicht vom Mailserver gefiltert, denn die Mail stammt vom Formmailer, und Mail-Server wenden in der Regel selbst keine Bayes-Filter an. Das bedeutet: Formmailer-Mails werden den Empfänger mit grosser Wahrscheinlichkeit erreichen.

htaccess als Basiskontrolle

Bots senden manchmal eine stark variierende Liste von User-Agents, deren Mehrzahl heute eigentlich nicht mehr im Gebrauch ist. Man darf mit ruhigem Gewissen diese obsoleten weil garantiert falschen Requests ausschliessen. Tut man dies auf der Ebene von htaccess, so wird der Server entlastet. Würde man aber diesen Vorgang in die Startphase eines Scriptes verlagern, so liesse sich die Eigenart der momentan verwendeten IP beurteilen, und somit die ganze Welle, sofern sie unter der gleichen IP führt, erfassen und blockieren.
Damit kann man natürlich nicht jene Welle erfassen, die IP und Agents zur gleichen Zeit modulieren.

User-Agent Blacklistung oder Whitelistung

User-Agent Angaben können modifiziert werden. Sie gelten weder als notwendige, noch als verlässlichen Angaben im HTTP Verkehr. Nicht jeder, der seinen User-Agent modifiziert, ist ein Spammer. Dennoch hat die Kontrolle des User-Agent Strings einen Platz im ganzen Bewertungsschema. Zunächst lassen sich einige Angaben blacklisten. Diese Massnahme kann bestenfalls unsorgfältige Bots erfassen. Man kann zudem auch veraltete User-Agents aus dem Verkehr ziehen. Ich finde einen Netscape 4.7 oder einen MSIE 4.0 schlicht nicht mehr akzeptabel3.
Ist ein Ratingprozess implementiert, der mehrere Merkmale bewertet, so kann man auch via Whitelisting moderne Useragents belohnen. Whitelisting als Blockierungsmassnahme ohne Bewertung ist eine radikale Massnahme, die man nur bei stark angegriffenen Formularen anwenden sollte. Meiner Erfahrung nach sollte man aber insgesamt Filterung auf dem User-Agent nicht akribisch vollziehen. Solche Listen sind sehr aufwändig und müssen besonders im Fall von Whitelisting immer wieder überprüft werden.

Captchas4

Captchas sind kontrovers, weil sie den Anwender einer Challenge ausliefern. Bei Captchas muss man ein Signal erkennen und dieses bestätigen. Weil mittels OCR Text in Bilder gelesen werden kann, müssen die Texte in Bild-Captchas soweit verwirbelt und verunklart werden, dass Menschen gerade noch, Maschinen aber nicht mehr diese Leistung erbringen5. Es ist nur eine Frage der Zeit, bis Maschinen auch hier die Trefferquote von Menschen erreichen, die dazu oft mehrere Anläufe brauchen.
Captchas haben eine zweite kontroverse Seite. Sie müssen zugänglich sein. Das heisst, für jede Bildversion muss auch eine Nicht-Bild-Version bereit stehen. Eine Maschine kann den schwächeren der zwei Aspekte angreifen. Auch Spracherkennung ist relativ leicht. Spracherkennung muss aber die Sprache des Anwenders berücksichtigen. Hier kommt das Problem der Sprachwahl zum Zuge. Eine Maschine kann die Sprache ihrer besten Chance verlangen.
Man vermutet heute, dass die hohe Erfolgsquote bei einigen Portalen nicht auf sehr guten Maschinen beruht, sondern dass die Captchas effektiv von Bediensteten ausgefüllt werden. An diesem Punkt muss die Captcha-Theorie endgültig scheitern. Allerdings muss man sehen, dass die private Homepage wohl kaum je von dieser Art Captcha-Bruch befallen sein wird.

Individuelle Captchas

Bezüglich Captchas sollte man vor allem sehr differenzieren. Ein grosses Portal kann, weil es Accounts mit hoher Funktionalität und Missbrauchspotential bietet, andere Methoden bevorzugen, als eine Homepage, die kaum solche Chancen implementiert.
Captchas können auch bei einer privaten Homepage helfen, sofern sie simpel genug sind, dass es nur einer Version bedarf, um zugänglich zu bleiben. Hierbei verzichtet man auf Bilder und nimmt einen rein textbasierten Test vor. Der Erfolg dieser Captchas liegt nicht in der Methode an sich, sondern an der individuellen Gestalt. Je verbreiteter eine bestimmte Form von Captcha ist, was besonders bei Plugins gilt, um so eher werden solche Captchas von Spammern analysiert. Handelt es sich aber um eine private Form, lohnt sich der Aufwand aus der Sicht des Spammers oft nicht.

Accessibility und Usability

Accessibility versus Spam-Abwehr

Dies ist ein natürlicher Interessenkonflikt. Accessibility besagt, dass wir uns nicht auf die Anzeige verlassen sollen, wenn es um die Bedienung eines Formulars geht. Vielmehr sollen Formulare als solche korrekt ausgezeichnet sein. Vor allem Label Elemente haben hier eine wichtige Funktion. Screenreader verwerten zwar das CSS, interpretieren aber einige Regeln besonders. Color, Background und Position versagen hierbei.
Im Kampf mit dem Spam ist man versucht, ein Formular zu vernebeln. Die Wahrscheinlichkeit, dass man es für eine nicht vorhersehbare Benutzergruppe unbrauchbar macht, ist jedoch grösser, als dass man damit moderne Spambots behindert.
Captchas müssen besonders kritisch betrachtet werden. Ein Bildcaptcha allein ist eindeutig zu wenig. Auch selbst gestrickte Rätsel-Captchas stellen Probleme dar, wenn man nicht Anwender anderer Sprachgruppen ausschliessen will6. Räsel-Captchas sind zudem eine besondere Art von Test. Je neutraler sie gefasst sind, um so eher werden sie von Maschinen gebrochen. Je mehr sie aber auch kulturelle Prügung abstützen, um so unzugänglicher werden die Formulare.

Usability versus Spam-Abwehr

Usability meint primär, dass ein Formular genau und schnell zum Ziel führt. Ein unverzichtbarer Bestandteil der Usability ist der Verzicht auf unnötige Pflichtfelder und sonstige Ablenkungsmanöver, aber ebenso die Rückgabe der Usereingaben zur Archivierung für den Anwender. Alles, was diesem Prozess im Wege steht, vermindert die Usability.
Javascript wird des öfteren eingesetzt, um die Leistungsfähigkeit des Browsers als Kriterium zur Unterscheidung mit einzubeziehen. Abgesehen davon, dass dies eine abnehmende Erfolgschance hat, sollte dies doch nicht der primäre Grund sein, Javascript vorauszusetzen. Der primäre Sinn von Javascript ist die optionale Erweiterung der GUI, Hilfeleistung bei der Eingabe und Vor- aber nicht Ersatzvalidierung des Inputs. Allerdings muss man auch hier betonen, dass zuviel Validierung mit Javascript genau das Gegenteil von Spamschutz erzeugt. Ich gebe nämlich wertvolle Information preis, damit eine Maschine optimiert werden kann.

Die Vorschau

Eine Vorschau ist weder gegen Usability noch gegen Accessibilty gerichtet. Im Gegenteil: In einer Situation, in der ein User das Formular und seine Abarbeitung nicht kennt, ist es irritierend und mangelhaft, keine Vorschau zu geben. Vorschauen gehören zum guten Stil und dienen damit, eine zusätzliche Aktion zu erzwingen, an welcher die einfacheren Bots häufig bereits scheitern. Im Mailverkehr ist die Vorschau auch der Punkt, wo der regelmässig enttäuschte Anwender das erste Mal eine Kopie klaut, weil er befürchtet, dass er keine Archivversion zu seinen Akten erhalten wird. Eine Vorschau kann nur in Situationen unterbleiben, wo der erzeugte Inhalt weiterhin editierbar bleibt. Dies kann etwa der Fall sein, indem der User als Member eingelogged ist, oder indem man einem Gast durch seine Session-ID Schreibrechte zu seinen Artikeln gibt, solange die ID existiert7.

Registrierung als Lösung

Blogs und Gästebücher erlauben deshalb viel sponates Feedback, weil es keine Registrierung gibt. Tatsächlich kann eine Registrierung das Problem entscheidend einschränken. In einem Registrierungsvorgang ist es ja schliesslich kein Verbrechen, auch mal ein Captcha anzuwenden.
Die Registrierung aber verlagert nur das Problem. Nun habe ich Accounts zu überwachen. Der einzige Vorteil beruht darin, dass ich mit einer Sperrung des Accounts auch entsprechende Beiträge entfernen kann, sofern die Architektur dies zulässt.
Registrierung ist jedoch ein Killer, wenn man Aktivität wünscht. Es zeigt, dass Usability oft mit möglicher Spontaneität verglichen wird. Wenn man sich überall registrieren müsste, würde das auch nichts wesentlich verbessern. Man hat nur einfach Zehn mal mehr Passworte zu verwalten. Und die Zahl der verwaisten Accounts wächst beliebig.
Aus meiner Sicht ist Registrierung keine Lösung. Es ist zuerst und vor allem eine Niederlage gegenüber den Spammern. Auch hier würde ich sagen: Ein paar Wochen den Bayes-Filter trainieren ist nicht aufwändiger, wie ein Accountsystem zu verwalten und ab und an zu bereinigen.

Spam-Requests erkennen

Man kann relativ schnell und einfach Spamrequest in Logfiles erkennen. Aber man kann sie nur sehr schwer vorhersehen. Ein Markenzeichen von Server stationierten Spambots ist, dass sie keine weiteren Ressourcen nebst ihrem eigentlichen Ziel verlangen. Browser verlangen CSS-, JS- und Bild-Dateien. Server-Bots tun es nicht. Falls ein Bot es dennoch tut, darf man wetten, dass der Bot ein Browser-Plugin war.
Ein weiteres Markenzeichen von Bots der gestrigen Tage ist, dass sie oft jeden Return des Servers negieren. Der Bot glaubt, mit einem einzigen POST seinen Spam absetzen zu können.
Serverbots können noch besser mit Cookies umgehen als mit eingebundenen Ressourcen. Man kann aus diesem Mangel mehrere Strategien entwickeln, die aber allesamt auch in einem zentralen Punkt irren können. Vergessen wir nicht, dass nicht alle legitimen User-Agents CSS-Files, Javascripte oder Bilder laden.
Header-Felder sind ein weiterer Punkt wo Server-Bots häufig schlampen. Normale User-Agents senden Information zur Content-Negotiation. Das Fehlen dieser Angaben ist ein besserer Hinweis auf einen Bot als etwa das Nicht-Verlangen von referenzierten Files. Es empfiehlt sich, das Fehlen des Accept Http-Pflichtheader zu prüfen und solche Requests schlicht zu blockieren8.

Synopse, was ist angesagt

Wahrscheilich hat man mehrere Formulare zu be(t)reuen. Für jedes Formular eine eigene Batterie von Massnahmen zu implementieren, scheint wenig effizient. Deshalb sollte man eher darauf achten, dass man Formularen bestimmte Tests per Konfiguration einfach zuschalten kann. Aus meiner Sicht sind folgende relativ unproblematische Features:

Was wird in eHome-Factory implementiert?

Die Vorschau ist bereits fester Bestandteil. Cookies müssen akzeptiert werden, um Formulare ausfüllen zu können. Die IP-Sperre für IP/24 und IP/16-Blöcke wurde ebenfalls implementiert. Im Formmailer kann die Sendmail-Funktion aufgehoben werden. Im Gästebuch wurde dagegen Wert gelegt auf eine schnellst mögliche Löschfunktion. Diese Massnahmen sollten zusammen weniger Wartung mit sich bringen, als das Training eines Bayes-Filters.

Fussnoten

1 Wenn Ihnen der Browser das Feld mit Name und Passwort vorbelegt, dann agiert er als Bot im Dienste des Users. Er agiert partiell nicht anders als moderne Spambots

2 In der Realität wechselt die IP oft im Stundentakt zwischen sehr verschiedenen IPs.

3 Meine Blacklist für eHome-Factory ist relativ kurz:
^$,
^Java,
^libwww,
^Opera/[2-8],
^Mozilla/([123]|4\.[1-9]),
^Mozilla/4\.0\ \(compatible\;\ MSIE\ [45]

4 Captcha steht für Completely Automated Public Turing test to tell Computers and Humans Apart. Mehr dazu: http://de.wikipedia.org

5 Ich schaffe im Schnitt noch jedes dritte Bild-Captcha. Ich habe keine Hoffnung auf den Support durch das Portal.

6 Es gibt jedoch kein Gesetz, dass eine Homepage mehrsprachig bedienbar sein muss. Die Beschränkung auf eine deutschsprachige GUI mit deutschen Inhalten erlaubt es, sich auf deutsche Rätsel-Captchas zu beschränken.

7 Hier sollten nur Sesson-IDs mit grosser Schlüssellänge zum Einsatz kommen, um Kollisionen zu vermeiden.

8 Eine mögliche .htaccess Regel:
SetEnvIf Accept "^$" bad_bot