nicht angemeldet
Spamflut-Schutzsystem
Hallo SelfHTML-Forum,
ich habe bereits ein Spam-Schutzsystem auf meiner Website installiert. Es besteht aus einem einfachen Zeitsperre und einem CAPTCHA. Ich räume derzeit die Session-Klasse auf. Da habe ich gemerkt, dass die Datenspeicherung (Zeitsperre + Captcha-Zeichenkette) mit in der Session-Tabelle mit (SID, User-ID, ... ) gespeichert wird. Im Zuge des Überarbeitens möchte nun CAPTCHA und Zeitsperre nun total ausser der Session-Klasse lösen und eine eigene Flood-Klasse entwickeln, die CAPTCHA + Zeitsperre etc umfasst.
Würdet Ihr CAPTCHA und Zeitsperre in einer Klasse zusammenführen öder wären 2 getrennte Klassen besser?
Würdet ihr Zeitparameter + Captcha-String mit in der Sessiontabelle passend zu jeder SessionId speichern oder auch hier getrennte Tabellen bevorzugen?
Hier mal die Session-Tabelle:
http://img3.fotos-hochladen.net/uploads/sessiontablebl5uyqv0o1.gif
Sieht sehr unaufgeräumt aus:
[forum_access] - ForumID gespeichert zu denen Zugriff per Passwort erfolgte.
[rated_topics, involved_votes, written_posts, added_topics] - vor allem für Gäste interessant - sie Themen nicht mehrmals bewerten und abstimmen dürfen - selbstgeschriebene Beiträge und Themen sollen für die Zeit der Sitzung editierbar sein.
[flood_time, captcha_string] - das sind Gruppenfeatures, die für jede Gruppe (Moderator, Mitglied und Gast) einzeln steuerbar sind.
Wie würdet ihr die Datenspeicherung besser koordinieren?
Gruß mod.
-
Hello,
Würdet Ihr CAPTCHA und Zeitsperre in einer Klasse zusammenführen öder wären 2 getrennte Klassen besser?
Zwei wären besser. Für das Captcha die Klasse mit dem Device NULL und für die Zeitsperre und andere mögliche Erkennungsmechanismen eine sinnvolle POST-Klasse, in der dann auch die Methoden gegen RePOST enthalten sind.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo Tom,
Zwei wären besser. Für das Captcha die Klasse mit dem Device NULL und für die Zeitsperre und andere mögliche Erkennungsmechanismen eine sinnvolle POST-Klasse, in der dann auch die Methoden gegen RePOST enthalten sind.
Gut - die CAPTCHA-Klasse habe ich jetzt fertig!
Welche anderen Schutzmaßnahmen außer Zeitsperre und der Sperrung von Ip-Adressen /-Blöcken kennst du?
Gruß mod.
-
Hello,
Welche anderen Schutzmaßnahmen außer Zeitsperre und der Sperrung von Ip-Adressen /-Blöcken kennst du?
Nachdenken.
HTML dient der Auszeichnung von Daten, ist hier also eigentlich kontraproduktiv. Also baue ein Formular, das aus HTML-Gesichtspunkten schlecht ist, aber nicht ungültig.
Benutze keine Labels und keine Table-Elemente, sondern benutze IDs und CSS-Position-Angaben für die Anordnung der Felder.
Hier zählt die Intelligenz des Menschen gegenüber der stumpfen Mechanik eines Bots.
Und da würde ich Obscurity vorschlagen, die der Mensch sofort durchschaut, der Bot aber unter Normalumständen aber nicht erkennt, sofern der Programmierer vorausdenken kann...Wenn in einem Formular z.B. steht:
email-Adresse: [1] [ ]
bitte Wiederholung: [2] [ ]und die hinteren auszufüllenden Felder nun nicht unbedingt email1 und email2 heißen, sondern z.B. email und repeat oder sonstirgendwie phantasievoll unterschiedlich, dann sehe ich da für den Bot schon einen erhöhten Schwierigkeitsgrad. Insbesondere dann, wenn die Anordnung der Felder nicht per table, sondern per CSS-position-Angabe stattfindet. Dann kann man in der Liste nämlich die Reihenfolge beliebig festlegen.
Ob nun die email-Adresse wiederholt wird, oder der Name oder ein frei wählbarer Nickname, oder, oder, oder... Das musst Du entscheiden.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Danke für deine Vorschläge!
Flut-Zeitsperre und CAPTCHA sind implementiert.
Ich werde später noch über einen Spider-Schutz nachdenken ...
Was haltet Ihr von der Speicherung der Daten von Gästen, siehe 1. Post - Extra Tabelle einrichten oder in Session-Tabelle belassen ??
Gruß mod.
-
-
-