Spamschutz Gästebuch

[hotti]

moin,

mein Gästebuch hat ein  Eingabe-Formular mit den Feldern:
textarea->textfeld für die Nachricht

hidden-fields/name=wert:
id='AzHmmxyZ'
ky='023134598'
mail='[e-mail]'

(Mail-Adresse wie im Impressum)

Außerdem wird ein Cookie gesetzt mit dem Value 'QwWEDf5Gtp'. Bei einem Reload ändern sich die hiddenfelder id und ky sowie der Wert des Cookies. Beim Absenden mit dem Submit-Button wird zu einer "Danke"-Seite umgeleitet.

Ein Spammer hat vor, das Gästebuch mit obszönen Links u.a. zuzumüllen. Wie würde er vorgehen?

Hotte

[LX]

Ein Spammer wird erst mal das Formular mit Firebug oder einem ähnlichen Tool untersuchen und versuchen, die entsprechenden Eingabefelder mit automatisierten POST-Requests nachzubilden.

Wenn er feststellt, dass dies nicht funktioniert, wird er versuchen, den Zusammenhang zwischen hidden-Feldern und Cookies zu ergründen. Schlimmstenfalls wird er jeweils die Cookie- und hidden-input-Values jedesmal neu auslesen, wenn er unbedingt Dein Gästebuch mißbrauchen will.

Als zusätzliche Maßnahme ist daher entweder ein Captcha oder eine ansteigende Verzögerung bei multiplen Requests auf der gleichen IP zu empfehlen.

Gruß, LX

[Shadowcrow]

hi $name,

ich nutze für ein gästebuch auf einer seite Akismet, als das GB noch über suchmaschinen zu finden war hat es 99.9% des spams abgebügelt :-).

gruss
shadow

[hotti]

hi,

Ein Spammer wird erst mal das Formular mit Firebug oder einem ähnlichen Tool untersuchen und versuchen, die entsprechenden Eingabefelder mit automatisierten POST-Requests nachzubilden.

Ja, nee, klar, das macht er bestimmt ;-)

Wenn er feststellt, dass dies nicht funktioniert, [..]

Er wird denken, dass sein Eintrag erfolgreich war.

[..] wird er versuchen, den Zusammenhang zwischen hidden-Feldern und Cookies zu ergründen. Schlimmstenfalls wird er jeweils die Cookie- und hidden-input-Values jedesmal neu auslesen, wenn er unbedingt Dein Gästebuch mißbrauchen will.

Gerne. Nur zu. Es gibt im Formular nicht den geringsten Hinweis auf solche Zusammenhänge.

Als zusätzliche Maßnahme ist daher entweder ein Captcha oder eine ansteigende Verzögerung bei multiplen Requests auf der gleichen IP zu empfehlen.

Ich halte beides für nicht empfehlenswert. Ein Captcha könnte friedfertige Besucher abschrecken und manch Anderer sieht die IP-Adresse als "persönliche Daten" an die er evntl. nicht gespeichert haben möchte. Außerdem ist die IP-Adresse keineswegs eine Konstante.

Hotte

[Alexander (HH)]

Moin Moin!

mein Gästebuch hat ein  Eingabe-Formular mit den Feldern:
textarea->textfeld für die Nachricht

hidden-fields/name=wert:
id='AzHmmxyZ'
ky='023134598'

Wozu zwei verschiedene Werte, und dazu noch so offensichtlich benannt?

mail='[e-mail]'

»»

(Mail-Adresse wie im Impressum)

Wozu ein Hidden-Feld mit Deiner(?) Mail-Adresse?

Außerdem wird ein Cookie gesetzt mit dem Value 'QwWEDf5Gtp'.

Falsch formuliert: Du versuchst, einen Cookie zu setzen. Hast Du einen Fallback-Mechanismus oder läßt Du paranoide Surfer einfach gegen die Wand laufen, die keine Cookies akzeptieren?

Bei einem Reload ändern sich die hiddenfelder id und ky sowie der Wert des Cookies.

Na und? Wertest Du die Hidden-Felder und den Cookie aus oder schreibst Du die nur aus Spaß ins Formular?

Beim Absenden mit dem Submit-Button wird zu einer "Danke"-Seite umgeleitet.

Ein Spammer hat vor, das Gästebuch mit obszönen Links u.a. zuzumüllen. Wie würde er vorgehen?

Du möchtest also, dass ich mir mal den schwarzen Hut aufsetze?

  
#!/usr/bin/perl -w  
use strict;  
use WWW::Mechanize;  
my $spam='Buy that blue pills at http://evil.site.tld/';  
my $mail='[e-mail]';  
for my $loop (1 .. 100) {  
    my $m=WWW::Mechanize->new(agent => 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)', cookie_jar => {});  
    $m->get('http://www.example.com/guestbook.cgi');  
    map { $_->value($spam) } $m->find_all_inputs({ type => 'textarea' });  
    map { $_->value($mail) } $m->find_all_inputs({ type => 'text', name_regex => qr/mail/ });  
    $m->submit();  
}  

.. aus dem Kopf und ohne zu testen. Dieses Dutzend Zeilen erwartet, dass Du nur ein Formular auslieferst, mit einer einzigen Textarea für den Text und einem Textfeld, dessen Name "mail" enthält, für die E-Mail-Adresse des Gastes. Dein Cookie wird brav zurückgeliefert, ebenso Deine Hidden-Felder.

Suche eines passenden Formulars in einer Seite mit mehreren Formularen ist leicht nachzurüsten, ebenso z.B. ein Klick auf einen bestimmten Submit-Button mit oder ohne Image.

Prüfst Du die Zeit zwischen dem GET und dem dazugehörigen submit (POST), baue ich ein sleep(10*random()) ein.

Rüstest Du Javascript oder Captchas nach, sperrst Du weitere Benutzer aus.

Je nach dem, wie stark ich motiviert bin, rüste ich einfach die Funktion des Javascript in meinem Code nach, oder ich lasse einfach eine Javascript-Engine in Perl laufen, ggf. mit einem Timeout gegen Trödeleien in Deinem JS-Code. Gegen Captchas hilft gut raten, Algorithmus knacken (MS Live und Google sind geknackt), oder schlicht Schwanzsteuerung.

Oder ich outsource das ganze Spammen nach Indien oder China und lasse dort Billigst-Arbeiter für ein paar Cent vorbereitete Texte abtippen oder reinkopieren. Das hilft auch gegen Captchas, Javascript und alle anderen Tricks, mit denen Du versuchst, Menschen von Maschinen zu unterscheiden. Gegen eine Abfrage der Remote-IP-Adresse helfen Anonymisierungsnetzwerke oder ganz einfach offene Proxies.

Alexander

[hotti]

hi,

.. aus dem Kopf und ohne zu testen. Dieses Dutzend Zeilen erwartet, dass Du nur ein Formular auslieferst, mit einer einzigen Textarea für den Text und einem Textfeld, dessen Name "mail" enthält, für die E-Mail-Adresse des Gastes. Dein Cookie wird brav zurückgeliefert, ebenso Deine Hidden-Felder.

Du würdest den Cookie und die hidden-Felder also zurückschicken ohne zu wissen, was damit auf dem Server gemacht wird?

Hotte

[Alexander (HH)]

Moin Moin!

»» [...] Dein Cookie wird brav zurückgeliefert, ebenso Deine Hidden-Felder.

Du würdest den Cookie und die hidden-Felder also zurückschicken ohne zu wissen, was damit auf dem Server gemacht wird?

Natürlich. Ein Browser würde exakt das Gleiche machen, so lange kein Javascript im Spiel ist.

Alexander

[hotti]

Moin Alexander,

»» Du würdest den Cookie und die hidden-Felder also zurückschicken ohne zu wissen, was damit auf dem Server gemacht wird?

Natürlich. Ein Browser würde exakt das Gleiche machen, so lange kein Javascript im Spiel ist.

Ok, danke Dir. Der Zusammenhang mit Javascript ist mir noch nicht klar, kannst Du noch was dazu schreiben?

Hotte

[ChrisB]

Hi,

Der Zusammenhang mit Javascript ist mir noch nicht klar, kannst Du noch was dazu schreiben?

Wenn du serverseitig die Wert 2 und 3 ausgibst, und als Antwort auf diese "Challenge" 5 als Summe der beiden erwartest - dann kann der Browser diese per JavaScript selbst ausrechnen; ein Bot tut sich damit aber (etwas) schwerer.

MfG ChrisB

[Alexander (HH)]

Moin Moin!

»» Der Zusammenhang mit Javascript ist mir noch nicht klar, kannst Du noch was dazu schreiben?

Wenn du serverseitig die Wert 2 und 3 ausgibst, und als Antwort auf diese "Challenge" 5 als Summe der beiden erwartest - dann kann der Browser diese per JavaScript selbst ausrechnen; ein Bot tut sich damit aber (etwas) schwerer.

Ja, und zwar aus exakt einem Grund: Die Simulation einer browsertypischen Javascript-Umgebung macht den Bot extrem anfällig.

Ich habe vor einiger Zeit mal die (im Nachhinein etwas abstrus wirkende) Idee umgesetzt, den selben Javascript-Code im Browser und auf dem Server zur Formularvalidierung einzusetzen. Letztlich habe ich für das Javascript ein paar ziemlich brutal einschränkende Regeln festgelegt, was den Umgang mit Formularelementen angeht, entsprechend wenig in der Server-JS-Umgebung nachgebaut, und dann in aller Regel den selben Validierungscode zweimal laufen lassen. Die eigentliche Implementation war nicht sonderlich schwierig, eine fertige Javascript-Engine vom Mozilla-Projekt ließ sich schnell an den Server anflanschen, und wegen der Einschränkungen für den Javascript-Code war auch nicht viel an Umgebung aufzubauen.

Mit Bots funktioniert das so aber gerade nicht. Der Bot, egal ob Spambot oder Suchbot, muß einen Browser so präzise wie möglich simulieren, um wirklich das selbe Ergebnis zu bekommen wie ein echter Browser. Ist die Umgebung von einem echten Browser zu unterscheiden, kann man Bots in Javascript erkennen und entsprechend handeln:

  
...  
<form name="f">  
<input name="bot" type="hidden" value="0">  
...  
</form>  
<script type="text/javascript">  
  function isBot()  
  {  
    return navigator.userAgent=='StupidBot/1.0';  /* blödes Beispiel! */  
  }  
  if (isBot()) {  
    document.f.bot.value="1";  
  }  
</script>  
...  

Und der Bot wird angreifbar. Erkennt das Javascript eine Spambot-Umgebung, kann das Javascript Rechenzeit und Speicherplatz verbrennen und so das Spammen verlangsamen:

  
  ...  
  if (isBot()) {  
    document.f.bot.value="1";  
    var i,j,k,a;  
    for (i=0; i<1000000; i++) {  
      a[i]=[];  
      for (j=0; j<1000000; k++) {  
        a[i][j]=[];  
        a[i][j][0]="Eat this!";  
        for (k=1; j<1000000; k++) {  
          a[i][j][k]=a[i][j][k-1]+a[i][j][k-1];  
        }  
      }  
    }  
  }  
  ...  

Setzt der Bot der JS-Umgebung ein Timeout, ist der Bot identifizierbar, ganz einfach über window.setTimeout() mit einer Zeitangabe über dem Limit. Versucht der Bot, das abzufangen, indem gesetzte Timeouts vorgezogen werden, kann man die vergangene Zeit mit window.setInterval() messen und bei drastischen Unterschieden ist der Bot wieder identifiziert. Außerdem gibt es noch das Date-Objekt, dessen Zeiten ebenfalls vom Bot gefälscht werden müßten. Das Javascript kann sich mit Hilfe des Servers (XMLHttpRequest, document.createElement("script")) die echte Uhrzeit holen und die vergangene Zeit auf dem Server mit der vergangenen Zeit in der Bot-Umgebung vergleichen. Ist der Unterschied drastisch genug, ist der Bot identifiziert. Funktioniert der Zugriff auf die externe Zeitquelle nicht, ist der Bot ebenfalls identifiziert.

Suchbots hätten ein anderes Problem, denn sie müßten DOM-Manipulationen erlauben (z.B. um eine rein Javascript-basierende Navigation überhaupt erst zu aktivieren):

  
  ...  
  if (isGoogleBot()) {  
    var b=document.getElementsByTagName('body')[0];  
    for (i=0; i<10000; i++) {  
      var a=document.createElement('a');  
      a.href="http://spam.example.com/spam/spam/spam.html";  
      a.appendChild(document.createTextNode("Eat more spam"));  
      b.appendChild(a);  
    }  
  }  
  ...  

Implementieren die Bots dann auch noch XMLHttpRequest, wird die Sache für Bot-Betreiber richtig widerlich. Mit XMLHttpRequest kann man, zusammen mit der Bot-Erkennung, die Bot-Maschinen sehr leicht mit sehr, sehr, sehr viel weiterem Müll beladen, ohne das irgendein normaler Browser darunter leiden müßte. Implementieren die Bots XMLHttpRequest nicht, obwohl der simulierte Browser XMLHttpRequest implementiert, ist der Bot zu erkennen. Emuliert der Bot einen aktiken Browser ohne XMLHttpRequest, fällt er erst recht auf.

Alexander

[hotti]

Moin!

lieber Alexander, ich danke Dir für die interessanten Informationen!!

Viele Grüße,
Horst Haselhun