Moin!
Ich habe versucht das in eine Funktion zu packen, damit bestehende Skripte leicht nachgerüstet werden können. Erste Funktionsproben sind erfolgreich verlaufen, aber ich stelle die Funktion mal zur Diskussion.
ähnlich wie Klaus würde ich einen anderen Ansatz wählen: Du gehst mit Deinem Script nach Indizien, die bei einer akuten Art des Spammings gerade mal üblich sind.
Diese sind "notwendig". Das @ _muss_ enthalten sein, der Zeilenumbruch _muss_ enthalten sein, sonst passt das gesamte Angriffsszenario nicht. Zumindest nicht, wenn man als Ziel den Spamversand unterstellt. Das Flooding eines Gästebuches oder Forums halte ich für weniger gefährlich. Aber geade hinsichtlich eines Forums würde ich die Abstände zwischen den Postings nicht auf x Minuten pro IP festlegen wollen.
Mir schwebt vor, auf der Formularseite eine Session mit langer Laufzeit zu starten (bzw. eine bestehende zu füttern), in der die Aufrufzeit gespeichert wird. Findet der Formularversand früher als nach n Sekunden statt (n könnte im Bereich 5 bis 10 liegen), hat offenbar kein Mensch die Formularfelder ausgefüllt. Die Aufrufzeit sollte nach jedem (mindestens legitimen, besser ausnahmslos jedem) Scriptaufruf aktualisiert werden.
Auch das ist ein Herumgedoktore an Symptomen: Der Spammer könnte sich darauf einstellen und seinen Request n+3 Sekunden nach Abruf des Formulars und des Session-Cookies starten. Auch ein Unix-Batch kennt sleep n.
Zugegeben, das ist nicht so leicht nachzurüsten wie Deine Funktion. Im Ergebnis dürfte es aber deutlich effektiver, effizienter und dauerhafter sein.
Dauerhafter ergo nicht.
Der an anderer Stelle genannte Weg mit der Grafik ist meines Ermessens ungangbar: Für viele zu schwer nachzurüsten, von zu vielen Vorbedingungen (Grafikbibliotheken) abhängig, zugangsbeschränkend für Besucher.
Erstens: Der Spammer versucht immer in eigentlich einzeilige Variablen Inhalte mit Zeilenumbrüchen einzuschmuggeln.
Das passiert auch leicht durch Copy & Paste.
Hm. Das stimmt allerdings. Sendet der Browser die eigentlich? Man könnte die Daten vorher trimmen, um festzustellen ob sich der Umbruch inmitten von Text befindet und so eine Reihe solcher Fehlbedienungen ausschließen- jedoch nicht alle.
Zweitens: Der Spammer versucht in jedes Formularfeld eine mindestens Mailadresse einzutragen.
eMail und Firma können sehr leicht @-Zeichen enthalten. Findet sich dies auch noch in einem anderen Feld, warum auch immer, werden legitime Nutzungen bei Deinem Beispielaufruf abgelehnt. Dieses Problem könntest Du zumindest reduzieren, indem Du nicht nur auf @-Zeichen testest, sondern auf eMail-Adressen.
Das wäre eine Möglichkeit, die ich bedenken sollte. Aber ich habe die Zahl der Felder, welche das @ enthalten dürfen, bewusst konfigurierbar gemacht. Der "jrubin3456" versucht schlicht in jedes Feld eine Mailadresse einzutragen. Grund : jedes kann 'nützlich' sein und er will sich nicht mit Kram wie Fremdsprachen und der Benennung aufhalten- das Muster wird er fortsetzen.
if ($intMaxAllowed > count($arFields)) {
die ("Error: in function jrubin3456: Die Anzahl der erlaubten Felder mit @ ist größer als die Anzahl der Felder.");Dies kann nicht von außen manipuliert werden (Hacking mal ausgenommen), wäre also IMHO kein Grund für einen Abbruch.
Doch. Es ist ein sozusagen fataler logischer Fehler im Script. Es soll sichergestellt werden, dass es funktioniert. Gut: ich hätte ein anderes Error-Management benutzen können, aber wozu?
if (isset($_POST[$strField])) {
[...]
if (isset($_GET[$strField])) {$_REQUEST würde die Code-Verdopplung sparen ... :-)
Führwahr! Zudem sollte ich also tatsächlich auf eine Mailadresse proben.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development