WordPress-Formular-Honeypot: Wie „ReportedIP Hive“ Kommentar-Spam nahezu auf Null reduziert
Ein Honeypot-Feld allein hält die Bots auf, die jedes Eingabefeld ausfüllen; es nützt jedoch nichts gegen ein Skript, das so geschrieben ist, dass es genau das eine Feld überspringt, das es überspringen soll. ReportedIP Hive 2.1.53 kombiniert seinen bestehenden Comment Honeypot mit einem Ausführungsnachweis, der auch die zweite Art abfängt, und wertet beide gemeinsam aus, sodass eine skriptgesteuerte Eingabe so gut wie nie einen Posteingang oder einen Kommentarthread erreicht.
Was ein WordPress-Honeypot-Feld tatsächlich bewirkt
Ein Honeypot-Feld ist ein zusätzliches Eingabefeld, das einem Formular hinzugefügt wird, das vor sehenden Besuchern mittels CSS verborgen bleibt, vor Bildschirmleseprogrammen durch aria-hidden und von einem Menschen, der es nicht sehen kann, niemals ausgefüllt wird. Eine durch ein Skript ausgelöste Übermittlung, die jedes gefundene Feld ausfüllt, füllt auch dieses Feld aus, und ein ausgefülltes Honeypot-Feld ist ein Beweis für eine automatisierte Aktion, ohne dass es dafür eine legitime Ausnahme gibt. ReportedIP Hive betreibt seit Version 2.1.2 ein solches Feld in seinem Kommentarformular: ein Feld mit dem Namen reportedip_hive_hp, das außerhalb des Bildschirms positioniert ist und weder in die Tabulatorreihenfolge noch in die Autovervollständigung einbezogen wird.
Warum ein Honeypot allein nicht mehr ausreicht
Ein Honeypot fängt lediglich Skripte ab, die Felder wahllos ausfüllen. Ein Skript, das auf eine bestimmte Website zugeschnitten ist, oder eines, das den Markup-Code eines Formulars auswertet und alles überspringt, was aria-hidden oder eine „off-screen“-Klasse überspringt, geht geradewegs daran vorbei. Diese Lücke können auch inhaltliche Heuristiken nicht schließen, da sich Formulierungen schneller ändern, als ein Filter sie erlernen kann. Daher wurde in ReportedIP Hive 2.1.53 eine zweite, unabhängige Frage hinzugefügt: Hat dieser Client die Seite überhaupt geladen und ihr JavaScript ausgeführt?
Bei dieser Frage spielt es keine Rolle, was in der Übermittlung steht. Ein Client, der direkt an wp-comments-post.php, ohne jemals die Artikelseite abgerufen zu haben, kann kein Skript ausgeführt haben, das sich auf dieser Seite befindet, ganz gleich, worauf sich der Kommentartext angeblich bezieht.
Wie der Ausführungsnachweis zu seinem Urteil gelangt
Der Server fügt ein verstecktes Ankerfeld in das Formular ein. Ein kleines Skript fügt daraufhin ein zweites Feld daneben hinzu, das bei jeder Installation einen anderen Namen erhält, sodass eine manipulierte Payload nicht für zwei Websites verwendet werden kann. Durch das Auslesen beider Felder beim Absenden wird jede Anfrage einer von vier Kategorien zugeordnet:
| Einstufung | Was der Beitrag enthielt | Was das bedeutet |
|---|---|---|
tripped | Das Feld „Honeypot“ wurde ausgefüllt | Typisches Bot-Verhalten: Ein Feld ausgefüllt, das ein Mensch niemals zu Gesicht bekommt |
proved | Honeypot leer, Proof-Feld vorhanden | Ein Browser hat das Formular dargestellt und das dazugehörige Skript ausgeführt |
failed | Honeypot leer, Nachweisfeld fehlt, dieses Formular rendert den Anker nachweislich | Es wurde eine echte Seite aufgerufen, das Skript wurde nie ausgeführt, es gibt keine erkennbaren Anhaltspunkte dafür, dass ein Mensch dahintersteckt |
absent | Keines der beiden Felder ist vorhanden | Diese Einreichung wurde überhaupt nicht über unser Formular übermittelt |
Die Unterscheidung zwischen failed und absent ist für einen echten Grenzfall von Bedeutung: einen Besucher, der JavaScript deaktiviert hat. Hive protokolliert höchstens einmal täglich, dass ein Kommentarformular den Anker tatsächlich gerendert hat; dieser Eintrag entscheidet darüber, ob ein fehlendes Nachweisfeld als „das Skript wurde hier nie ausgeführt“ oder als „wir haben von vornherein kein Feld in diesem Formular platziert“ interpretiert wird. Ein Theme mit manuell erstelltem Kommentar-Markup oder eine Website, auf der die Ebene deaktiviert wurde, erhält die wohlwollende absent Auslegung und wird nicht als verdächtig eingestuft, obwohl es das betreffende Element gar nicht erst enthielt.
Welchen Einfluss hat jedes Signal auf den Spam-Score?
Kommentare werden durch ein separates Bewertungssystem geleitet, ReportedIP_Hive_Comment_Spam_Filter, der das „Execution-Proof“-Urteil mit Link- und Identitätssignalen kombiniert. Ein Kommentar benötigt eine Bewertung von 4 oder mehr, um als Spam eingestuft zu werden:
| Signal | Ergebnis | Erreicht er den Schwellenwert von 4 allein? |
|---|---|---|
Das Feld „Honeypot“ wurde ausgefüllt (tripped) | +6 | Ja, mit zwei Punkten Vorsprung |
Das Formular wurde gerendert, das Skript wurde jedoch nie ausgeführt (failed) | +4 | Ja, genau an der Linie |
| Der Name des Autors ist selbst eine URL | +4 | Ja |
| Ein Link ohne Text in einem kurzen Kommentar | +4 | Ja |
| Mehr Links als das konfigurierte Maximum | +3 | Nein, es ist ein zweites Signal erforderlich |
In der Anfrage ist überhaupt kein „Honeypot“-Feld enthalten (absent, kein Render-Verlauf) | +1 | Nein, es ist ein zweites Signal erforderlich |
Ein gefüllter Honeypot allein überschreitet den Schwellenwert bereits mit deutlichem Spielraum. Ein fehlender Ausführungsnachweis allein erreicht ihn genau, was beabsichtigt ist: Es ist das einzige Signal, das ein echter Leser ohne JavaScript selbst erzeugen kann; daher wird der Vorgang lediglich zur manuellen Überprüfung vorgemerkt, anstatt die Adresse in die IP-Sperrliste aufzunehmen.
Was als Nächstes geschieht, hängt von der Form ab
Die drei Flächen, die die Schicht bedeckt, bergen nicht das gleiche Risiko, weshalb sie nicht die gleichen Konsequenzen nach sich ziehen:
- Kommentare, deren Bewertung über dem Schwellenwert liegt, werden als Spam markiert oder direkt abgelehnt, je nachdem, welche Maßnahme auf der Website unter „Firewall → Spam-Abwehr“ konfiguriert wurde. Ein Besucher ohne JavaScript hat lediglich eine Verzögerung bis zur manuellen Freigabe zu erwarten.
- Registrierungsformulare lehnen eine fehlgeschlagene Übermittlung sofort ab und geben den Grund dafür an, da die Einrichtung eines neuen Kontos eine größere Verpflichtung darstellt als das Verfassen eines Kommentars.
- Die Passwortzurücksetzung wird bei einem gefüllten Honeypot verweigert, jedoch niemals allein aufgrund eines fehlenden Nachweises: Ein Administrator, der aus seiner eigenen Website ausgesperrt ist, stellt ein größeres Problem dar als der dadurch verhinderte Spam; daher kann ein Browser ohne JavaScript ein Konto weiterhin wiederherstellen.
Jede Ablehnung wird offen angezeigt. Ein ausgeschöpftes Abfrage-Kontingent, ein Timeout oder ein nicht erreichbares Netzwerk werden eher als „keine Entscheidung“ denn als Blockierung gewertet, und beim Aktivieren des Report-Only Mode wird jedes Ergebnis protokolliert, ohne dass eine einzige Übermittlung abgelehnt wird. Dies ist nützlich, um die Protokolle einer ganzen Woche durchzusehen, bevor Sie entscheiden, welche Maßnahmen Sie durchsetzen möchten.
Seit wann und wie lässt sich diese Funktion deaktivieren?
Der Comment Honeypot ist seit Hive 2.1.2 in Betrieb. Der Ausführungsnachweis, das Vier-Wege-Urteil und die oben beschriebene Bewertung wurden gemeinsam in Version 2.1.53 eingeführt, zusammen mit der Ausweitung der Überprüfung der Community-Reputation, die zuvor ausschließlich auf der Login-Seite stattfand, auf Kommentare, Registrierungen und Passwortzurücksetzungen. Beide Ebenen sind in jedem Tarif kostenlos enthalten.
Die gesamte Ausführungsnachweis-Ebene befindet sich unter „Firewall → Spam-Abwehr“ und verfügt über einen siteweiten Schalter sowie einen separaten Schalter für die Anmelde- und Passwort-Zurücksetzungsformulare. Eine Website, deren Kommentar-Markup ungewöhnlich genug ist, um falsche failed Ergebnisse auslösen könnte, kann diese Ebene mit REPORTEDIP_HIVE_DISABLE_FORM_PROOF in wp-config.php vollständig deaktivieren.
Häufig gestellte Fragen
Kann ein Honeypot-Feld einen echten Besucher blockieren?
Nicht von selbst. Das Honeypot-Feld ist unsichtbar und kann von niemandem, der eine Maus, eine Tastatur oder einen Screenreader verwendet, aufgerufen werden, sodass es niemals von einem Menschen ausgefüllt wird. Der einzige Fall, für den eine gesonderte Regel erforderlich ist, betrifft Besucher mit deaktiviertem JavaScript; aus diesem Grund führt ein fehlender Ausführungsnachweis lediglich dazu, dass ein Kommentar zur Überprüfung eingereicht wird, anstatt die Adresse zu sperren.
Hat das Feld „Honeypot“ Auswirkungen auf die Barrierefreiheit?
Das Feld enthält aria-hidden="true", ein tabindex von -1 und autocomplete="off", sodass sowohl assistive Technologien als auch Passwortmanager es auf dieselbe Weise überspringen wie ein sehender Mausbenutzer.
Ist ein Formular-Honeypot DSGVO-konform?
Das Feld und das Ausführungsnachweis-Skript erfassen keine weiteren Informationen über den Besucher, außer der Tatsache, ob beim Absenden zwei versteckte Felder vorhanden waren, kein Fingerprinting, keine Anfragen an Drittanbieter. Eine vollständige Übersicht über den Umgang mit Daten finden Sie in der Dokumentation des WordPress-Plugins.
Weiterführende Literatur
- Nachweis der Formularausführung und der neue Schnellstart, in voller Länge
- Ein etwas anderer Honeypot: Das Sperren von Scannern bei deren erster Abfrage eines Pfades zu einer Köderdatei
In der Referenz zu den „comment_form“-Hooks von WordPress ist dokumentiert, an welcher Stelle das Honeypot-Feld ausgegeben wird. Die vollständige Übersicht über die Einstellungen finden Sie in der Dokumentation zum WordPress-Plugin. Entdecken Sie ReportedIP Hive →