Sichere Formulare - Teil 4: Spam-Bots maßregeln
von Rene Schmidt
Unseren Bausatz für ein sicheres Kontaktformular kennen Sie vielleicht schon. Nun gibt es ein Update, mit dem Spam-Bots ferngehalten werden sollen.
Der Kontaktformular-Bausatz läßt sich nicht als Spam-Verteiler missbrauchen. Bisher war es aber möglich, damit Nachrichten automatisch zu senden - wenn auch nur an den eingetragenen Nachrichtenempfänger. Mit dieser Aktualisierung erweitern wir den Bausatz um Mechanismen, die das automatisierte Absenden erschweren sollen.
Erschweren ist das Stichwort. Einem relativ einfachen PHP-Skript beizubringen, wie es Mensch und Maschine auseinander halten soll, ist eher schwierig. Das Wordpress-Plugin Spam Karma 2 beispielsweise ist dabei noch recht erfolgreich. Es ist einfach zu installieren, weil es sich in eine vorhandene Infrastruktur (nämlich Wordpress) einklinken kann. Allerdings ist das Skript durch seine zahlreichen Prüfungsmechanismen wie Linkzähler, Abgleich mit Spam-Datenbanken, CAPTCHAs, Blacklists komplex und für Anfänger schwer zu durchschauen. Das gilt vor allem, wenn dessen Mechanismen ohne Wordpress für eine eigene Website eingesetzt werden sollen.
Dies ist auch der Grund dafür, dass unser Bausatz weder CAPTCHAs noch eine Datenbankanbindung besitzt. Der Bausatz soll Basis für eigene Entwicklungen und Anpassungen sein. Dazu muss das Skript einfach zu verstehen sein.
Verbesserung #1: Zeitraum bestimmen
Die erste Verbesserung ist simpel: primitive Spambots füllen die Formularfelder aus und schicken die Daten sofort ab. Dadurch geben sie sich als Spambot zu erkennen, denn ein Mensch braucht mindestens ein paar Sekunden, um ein Formular mit sinnvollen Daten zu füllen.
Die Zeit, die zwischen Aufruf und Absenden vergangen sein muss, kann im Konfig-Feld des Skripts "FORM_MIN_AGE" in Sekunden angegeben werden:
define( 'FORM_MIN_AGE', 5 );
Damit das Formularskript sicher festellen kann, wann es das erste Mal aufgerufen wurde, wird ein Zeitstempel und dessen Streuwert (engl. "Hash") im Formular als versteckter Formularinhalt mitgesendet. Der Zeitstempel könnte zwar manipuliert werden, die Gegenprüfung mit dem Streuwert würde allerdings fehlschlagen.
Damit Spammer nicht tausende Mal das Formular aufrufen können, um Zeitstempel- und Zeitstempel-Streuwert-Kombinationen für später geplante Spam-Sendungen zu erfassen, ist auch das "Alter" des Zeitstempels ein Kriterium. Das maximale Alter wird im Skript hier angegeben (Beispiel: 60*60=3600 Sekunden):
define( 'FORM_MAX_AGE', 60*60 );
Im Klassen-Konstruktor wird ein Faktor erzeugt, welcher später zum Berechnen aller Streuwerte verwendet wird (Objekt-Eigenschaft "$this->faktor"). Er wird aus der Größe des Skripts, der Länge des absoluten Pfads zum Skript und der Länge des Webserver-Hostnamens berechnet. Außerdem ermittelt der Konstruktor eine Kennung des Skripts (Objekt-Eigenschaft "$this->id"). Sie dient dazu, Dateinamen für den späteren Gebrauch weniger leicht erratbar zu machen.
Verbesserung #2: Noch mehr Validierungen
Drei neue Hidden-Felder gibt es im Formular. Im Feld "zeit" wird der bereits beschriebene Zeitstempel zum Zeitpunkt des Formularaufrufs gespeichert. Der Zeitstempel muss mindestens 10 Zeichen lang und numerisch sein.
Das Feld "payload" enthält den Streuwert des Zeitstempels. Der Streuwert wird anhand der IP-Adresse des aufrufenden Benutzers und des zuvor ermittelten Faktors errechnet. Würde ein Spammer einen Streuwert verwenden, den er mittels der IP-Adresse A ermittelt hätte (was unwahrscheinlich ist), um seine Spams von der IP Adresse B mit dem gleichen Streuwert über dieses Formular zu senden, würde das fehlschlagen.
Der Spammer kann aber noch immer in einem Zeitfenster von fast einer Stunde (3600 minus 5 Sekunden) Zeitstempel- und Streuwert-Kombinationen ermitteln und währenddessen das Formular missbrauchen. Außerdem wäre es theoretisch denkbar, wenn auch unwahrscheinlich, dass der Spammer die Berechnungsgrundlage der Streuwerte kennt, vorausberechnet und Formulardaten absendet, ohne das Formular vorher aufgerufen zu haben.
Verbesserung #3: Bitte eine Nummer ziehen
Das letzte Feld trägt daher den Streuwert einer Zufallszahl. Aus dem Streuwert kann die Zahl nicht rekonstruiert werden. Diese Zahl wird beim ersten Aufruf des Skripts in eine temporäre Datei geschrieben. Die Datei wird nach dem Absenden des Formulars wieder ausgelesen, der Streuwert wird erneut berechnet und mit dem übermittelten Streuwert verglichen. Sind beide gleich, ist alles in Ordnung. Wurde der übermittelte Streuwert manipuliert, sind die beiden Streuwerte nicht gleich und eine Fehlermeldung wird ausgegeben.
Verbesserung #4: Strengere Checks
Eine weitere Hürde für Spammer wurde in einige der verbliebenen Felder eingebaut. Spambots spekulieren darauf, dass nur E-Mail-Felder auf Plausibilität geprüft werden und geben einfach, außer im Nachrichtfeld, eine E-Mail-Adresse in alle Felder ein. Um es Spammern nicht allzu einfach zu machen, darf daher, außer im E-Mail- und Nachrichtenfeld, kein @-Symbol eingegeben werden. Der Lesername muss zudem aus Vorname, Leerzeichen und Nachname bestehen. Auch Hidden-Felder werden auf sinnvolle Daten geprüft.
Spam-Abwehr ist ein fortdauernder Kampf, bei dem Spammer einen prinzipiellen taktischen Vorteil haben: sie kennen die Spam-Abwehrmethoden. Absolute Sicherheit bietet bisher kein System, zumal neue Spambots einen Websurfer mittlerweile täuschend echt nachahmen können, inklusive Javascript-Interpretation. Die hier vorgestellten Verbesserungen heben das Sicherheitsniveau an. Noch mehr Sicherheit würde das Skript erheblich komplizieren. Erweiterte Mechanismen werden aber sicher im Laufe der Zeit notwendig werden. (tm)
Kompletter Bausatz zum Download mit Frameswork (ZIP-Archiv 935 KB)
Die Links zum Thema:
- Spam-Abwehr mit CAPTCHAs
- Wikipedia: Hash-Wert
- Wikipedia: Zeitstempel
- Diskussion zu diesem Beitrag im Dr. Web Weblog
Erstveröffentlichung am 11.04.2006
Über René Schmidt
Verwandte Artikel
(No Ratings Yet)
