Sie haben JavaScript deaktiviert. Vermutlich sind Sie ein Kollege und wollen nur sehen, ob meine Website auch ohne JavaScript funktioniert.
Andernfalls: Bitte aktivieren Sie JavaScript!
Hinweis:
Dieser Artikel ist älter als 18 Monate / wurde seit 18 Monaten nicht aktualisiert. Dies kann (muss aber nicht) dazu führen, dass der Artikel, und / oder darin beschriebene Techniken, nicht mehr aktuell sind. Bitte berücksichtigen Sie diesen Hinweis bei der Lektüre.
Hinweis: Diese Seite – entstanden 2008! – ist am 18.01.2020 aus der Rubrik Tips'n Tricks hierher umgezogen. Das Thema ist nach wie vor aktuell.
Die Kommentarfunktion von Blogs, und jedes andere Formular auf Webseiten, werden von Spammern gerne für ihre Machenschaften mißbraucht.
Was kann man dagegen tun?
Zuerst einmal muß man unterscheiden zwischen manuellen Einträgen, und automatisierten Einträgen. In diesem Artikel geht es um die Möglichkeiten, automatische Einträge zu erkennen und zu verhindern.
Diese Methode macht sich den Umstand zunutze, dass Kommentarformulare von Automaten sehr viel schneller ausgefüllt werden,
als dies je ein Mensch könnte. Kein Mensch wird in weniger als z. B. 10 Sekunden ein komplettes Formular erfassen, mit vernünftigen Eingaben ausfüllen, und abschicken.
Zusätzlich wird noch eine Maximalzeit von z. B. 10 Stunden vorgegeben. Wozu das? Manche Bots verschicken Ihren Spam zeitversetzt, warum auch immer.
In vielen Fällen genügt allein diese Methode, um bis zu 99% Spamschutz zu erzielen.
Die Methode ist verblüffend einfach anzuwenden, und erfordert nicht einmal SESSIONS.
<?php
echo '<p><input name="date" type="hidden" value="', time(), '" /></p>';
?>
if (isset($_POST['date']) && is_numeric($_POST['date'])) {
$posted = intval($_POST['date']);
$sendezeit = (time() - $posted);
if ($sendezeit < 10 || $sendezeit > 36000) {
$text = "Gerade wurde der Kommentar in $sendezeit Sek. zugespammt\n
Absender: $email\n
Text: $comment";
mail('mail@example.com', 'Kommentarspam', $text);
die("no spam here!");
}
}
Anmerkungen:
1. Wenn die Variable mit der Zeit als URL-Parameter, also per $_GET übergeben wird, dann muss obiges Snippet natürlich entsprechend angepasst werden.
2. Die Angabe $sendezeit > 36000 sperrt Kommentare aus, die zeitversetzt, unabhängig vom Aufruf des Formulars gesendet werden. Ein ebenfalls typisches Kennzeichen für Spambots.
3. mail@example.com: an diese E-Mail Adresse wird bei jedem abgewehrten Spamversuch eine Nachricht geschickt.
Spambots füllen alle Felder eines Formulars aus. Dabei versuchen sie, die Felder mit jeweils passenden Inhalten zu befüllen.
Ein Feld namens E-Mail z. B. wird daher mit großer Wahrscheinlichkeit mit einer - natürlich gefälschten - E-Mail Adresse gefüllt.
Diese Eigenschaft der Spambots kann man sich zunutze machen, indem man zusätzliche Felder ins Formular einfügt, die von Menschen nicht ausgefüllt werden.
Zu diesem Zweck werden die Zusatzfelder per CSS vor Menschen versteckt, und für den Fall, dass der Besucher CSS deaktiviert hat, noch ein entsprechender Hinweis angebracht.
<span style="display:none">
<label for="email">Das folgende Feld muss leer bleiben:</label>
<input type="text" name="email" id="email" title=" dieses Feld muss leer bleiben " />
</span>
Anmerkung: Besser als die inline-CSS Angabe display:none ist sicher, dem span eine Klasse zuzuweisen, und hierfür display:none in einer externen CSS Datei zu deklarieren.
<?php
if ($_POST["email"] != "") {
echo "<p>Sie haben ein Feld ausgefüllt, das leer bleiben muss. Bitte gehen Sie mit der Zurück-Funktion Ihres Browsers zurück.</p>";
exit;
}
?>
Alleine angewandt, eignet sich diese Methode auch für Formulare, die unter Umständen auch von Menschen sehr schnell ausgefüllt werden, z. B. ein Suchformular. (Ja, selbst Suchformulare sind vor den Spambots nicht sicher.) In Kombination mit der vorgenannten Zeit-Methode dürfte ein sehr guter Spamschutz zu erreichen sein.
Nachteil dieser Methode: Besucher ohne oder mit deaktiviertem CSS (z. B. einige Screen Reader, eventuell auch abhängig von User-Einstellungen) werden durch scheinbar unnötige, zusätzliche Formularfelder und die entsprechenden, notwendigen Erklärungen belästigt.
Eine einfache Rechenaufgabe, oder eine einfache, logische Frage (z. B.: ist ein Mann männlich oder weiblich) muss gelöst, und die richtige Antwort in ein zusätzliches Formularfeld eingegeben werden.
Die Programmierung sollte kein Problem sein. Falls per Zufallsgenerator wechselnde Fragen gestellt werden, kann die Übergabe des richtigen Ergebnisses bequem mit einem hidden field wie bei Methode 1 erfolgen.
Der Nachteil dieser Methode liegt auf der Hand. Sie ist einfach lästig.
Eine Erklärung des Verfahrens erübrigt sich. Jeder kennt diese lästigen verzerrten Codebilder.
Und wohl jeder hat sich schon darüber geärgert, dass er das Gekritzel nicht entziffern konnte; und mancher hat vielleicht sogar nach dem dritten oder vierten erfolglosen Versuch entnervt aufgegeben.
Blinden oder stark sehbehinderten Nutzern wird das Absenden des Kommentars mit diesem Verfahren sogar gänzlich unmöglich gemacht.
Es gibt viele Nachweise, dass diese CAPTCHAs von Maschinen leicht, vielleicht sogar zuverlässiger als von Menschen, gelesen werden können.
Es gibt also keinen Grund mehr, Menschen mit CAPTCHAs zu belästigen oder gar auszusperren.
Die Auswertung des Kommentartextes nach bestimmten Kriterien kann zur Erkennung von Spam beitragen. So ist beispielsweise eine große Anzahl von Hyperlinks ein Indiz für Spam. Auch bestimmte Schlüsselwörter - das sprichwörtliche Viagra - können zur Identifizierung von Spam herangezogen werden. Der Aufwand für diese Auswertung ist jedoch relativ hoch, vor allem, um sicher zu stellen, dass nicht irrtümlich Text als Spam klassifiziert wird.
Einige weitere Methoden beschreibt Jared Smith im WebAIM Blog (englischsprachig).
Alle aufgeführten Methoden können mit entsprechendem Aufwand geknackt werden. Vor allem dann, wenn die Site so bedeutend ist, dass es für Programmierer von Bots lohnend erscheint; oder wenn eine der genannten Methoden häufig genug angewandt wird. Dagegen hilft eine Kombination mehrerer Methoden. Wichtig dabei ist der Einsatz von individuellen Lösungen/Kombination von Lösungen, sodass sich kein allgemein übliches Muster erkennen lässt, das dann wiederum ein lohnendes Ziel für die Programmierer von Bots darstellt.
Artikeltexte und Code-Snippets: Creative Commons CC BY-SA 4.0
Medien (Bilder, Videos, Audios) sind evtl. urheberrechtlich geschützt.
Über Ihren Kommentar zu diesem Artikel freue ich mich.
Wenn Sie aber Fragen haben, und eine Antwort erwarten, nutzen Sie bitte das Supportforum! Die Nutzung des Forums ist auch ohne Registrierung möglich.
Michael Welslau schrieb am Freitag, 27.12.13 03:28 Uhr:
Ich bin durch eigene Überlegungen zu der Spam-Verhinderung nach 2. gekommen und hab diese auf einer auch von Bots stark frequentierten Seite verwendet, mit 100% Erfolg! Vor allem wird dadurch der Benutzer nicht mehr mit Captchas und Co belästigt und darauf sollte mehr geachtet werden!
Mike Wieland schrieb am Mittwoch, 21.01.15 13:49 Uhr:
Und, eine ganz triviale Methode, aber sehr effizient:
Ein deny-Eintrag in der .htaccess. Die .htaccess-Methode entlastet den Server. Ich hab so einen Franzosen und einen Türken ausgesperrt - und Ruhe ist.
Nachteil: periodisch von Hand editieren.
Sven schrieb am Dienstag, 05.04.16 18:35 Uhr:
Hallo, vielen Dank für die Gute Erklärung!
Da ich gerade dabei bin meine Seite etwas aufyupeppeln und ich dadurch auf Apps wie z.B. Captcha- Plugins zu verzichten, würde ich gerne diese Codeschnipsel einbinden (von 1. und 2.) Nun habe ich ein Problem: Ich bin blutiger anfänger was Online- Programmierung angeht und deshalb weiß ich nicht, wo genau ich die Codes genau einbinden sollte?!
Ich arbeite mit Wordpress und habe derzeit Antispambee installiert und ebenfalls Si-Captcha Antispam.
Vielleicht könntet ihr mir weiterhelfen, die ab durch ein paar einfache Programmcodes zu unterbinden?!
Vielen Dank im Voraus dafür!
Grüße, Sven
Michael schrieb am Dienstag, 03.12.19 20:46 Uhr:
Hallo, vielen Dank für diese super Ideen!
Ich habe den Spamschutz unter 1.1 eingebaut, und er funktioniert super. Allerdings gibt der W3C Validator Fehler aus:
Error: Saw <?. Probable cause: Attempt to use an XML processing instruction in HTML. (XML processing instructions are not supported in HTML.
</div>↩ <?php↩ echo '<p
Error: No p element in scope but a p end tag seen.
e(), '" /></p>';↩?>↩
Ist das ok so, oder ist irgendwo ein Fehler im Code?
Danke und viele Grüße, Michael
Fritz schrieb am Dienstag, 03.12.19 20:54 Uhr:
@Michael
Die Kommentarfunktion ist zu sperrig für Support. Bitte die Frage im Supportforum forum.weisshart.de stellen. Dort helfe ich gerne.
Anton schrieb am Dienstag, 06.10.20 16:24 Uhr:
Hallo!
Hilfreiche Seite - danke.
Kurzer Hinweis: Beim PHP-Code zum Abfragen des Honeypot müsste es doch statt $_GET besser $_POST lauten, oder?
Herzliche Grüße,
Anton
__________
@Anton
Danke für den Hinweis. Hab's geändert.
mario schrieb am Freitag, 16.04.21 15:28 Uhr:
Sehr hilfreicher Artikel, danke dafür.