Lästiger Kommentarspam
Der Preis des Erfolges: Das Blog bekommt Spam in den Kommentaren. Es sind einige tausend pro Tag, betreffen aber nur einen Artikel. Was tun?
Die triviale Lösung wäre, ein Captcha oder ähnliche Belastungen für den geneigten Leser einzubinden. Ich mag den, der seine Aufmerksamkeit meinen Texten opfert, aber nicht noch zusätzlich belästigen. Es muß auch "einfach" so gehen.
Backend Logik
ezPublish läuft hier auf PostgreSQL, ich habe also die Chance einiges im Backend abzufangen. Und die einfach Lösung ist, die INSERTs zu verhindern:
CREATE or REPLACE RULE lutz_temp_prevent_spam AS ON INSERT TO ezcomment WHERE NEW.contentobject_id IN (107, 142) DO INSTEAD NOTHING;
Jedesmal, wenn ein neuer Artikel bespammt wird, muß die List manuell erweitert werden. Nachdem man die Spam-Kommentare mit einem beherzten DELETE FROM losgeworden ist.
Selbstverständlich skaliert das nicht, aber es hilft in der akuten Notlage.
Den Nutzer am Browser erkennen
Was macht also den entscheidenden Unterschied zwischen einem Robot und einem Nutzer aus?
Für die Frage hatte ich glücklicherweise Zeit. Bis heute. Denn heute begann der Spam von hunderten von IPs auf alle Beiträge breit verteilt einzuschlagen. Jetzt mußte eine neue Lösung her.
Die Idee ist simpel: Ein Angreifer schickt automatisiert ausgefüllte Formulare an das Blog. Dieses hat keine Vorkehrungen gegen XSRF, und trägt all diese Kommentare brav ein. Die gängige Abwehr ist, ein hidden Feld mit einer eindeutigen ID auszuliefern und diese nur innerhalb der von einem Cookie vermittelten Session wieder zu akzeptieren.
Selbstverständlich kennen die Spammer diese Abwehr und lesen vor jedem neuen Spam-Kommentar die Webseite erneut ein. Dann parsen sie die Felder und schicken den Request los.
Wenn ich also Erfolg haben will, muß meine Abwehr von einem Bot nicht, wohl aber von einem Nutzer mit einem normalen Webbrowser erkannt werden. Das hidden Feld darf also nicht im Formular stehen, sondern muß vom Browser eingefügt werden. Dann kann der Nutzer einfach kommentieren, ohne große Rätsel lösen zu müssen.
Das Feld wird also mit Javascript eingefügt (sorry), und das geht so. In add_comment.tpl kommt hinter die schon existierenden hidden Felder noch dieser Code rein:
{if $fields|contains( 'jsrunning' )}
<script type="text/javascript">
document.write("<input name='jsrun");
document.write("ning' type='hidden");
document.write("' value='true' />");
</script>
{/if}Der Code ist absichtlich so geschrieben, daß naive Parser das Input Feld nicht erkennen können. Vermutlich schlägt nun der ein oder andere Virenscanner an. Was soll's.
Und nun noch das Feld in ezcomments.ini.append.php aktivieren:
AvailableFields[]=jsrunning [jsrunning] Required=true PostVarName=jsrunning
Fertig. Die Spammer tropfen ab. Nun kann die RULE gelöscht werden und die Seele hat Ruhe.
Wie lang soll das halten?
Natürlich konnen und werden die Spammer sich darauf einstellen. Aber nur, wenn es sich lohnt. Und das ist unwahrscheinlich.
Zum einen bin ich zu unbekannt, daß sich ein Spammer am Ehrgeiz gepackt fühlen könnte und zum anderen ist die Lösung nicht Mainstream.
Das funktioniert, weil nicht viele Leute es so machen.
Wäre der Ansatz verbreitet, würden die Spammer natürlich jede Frage einmal lesen und beantworten, und dann hundertfach spammen. Aber je mehr unterschiedliche Ansätze benutzt werden, desto schwerer wird es die alle automatisiert zu umgehen.
Eigene Methoden sind idR am effizientesten weil das für die Spammer nicht skaliert und man deshalb in Ruhe gelassen wird.
Es gab einen erfolgreichen Spam-Eintrag, der laut Log offenbar manuell vorgenommen wurde. Anschließend lief der Robot los und hat seit dem auch nicht mehr aufgehört.
Den einen Spam habe ich gelöscht, der Robotspam ist abgetropft.
3 Kommentare