Deutschsprachige Informationen zu den Sicherheitsvorkehrungen ============================================================= Themenuebersicht: ----------------- 1. Sicherheitscode beim Bestaetigen der Mails 2. IP- und E-Mail-Sperre im Anmeldeformular 3. Modul-Sicherheit 4. SQL-Injektionen und XSS-Attacken 5. URL-Sperre 6. Profilsperre 7. URL-Filtersystem x. Haftbarkeit --- --- --- --- --- 1. Sicherheitscode beim Bestaetigen der Mails --------------------------------------------- Der Sicherheitscode gilt als eine Sicherheitsbarriere gegen Betrueger, die nur Punkte ansammeln wollen und das moeglichst ohne die beworbene Seite zu besuchen und sich anzusehen. Und genau dafuer ist der Mailtausch ja da, es soll die beworbene Seite besucht werden. Auch dieses Script kann natuerlich nicht 100%-ig dafuer sorgen, dass die Seite auch tatsaechlich besucht werden. Dazu gibt es andere Methoden, die hier den Rahmen der Datei sprengen wuerden. Aber nun zum eigentlichen Thema zurueck. Nehmen wir mal an, das Script kaeme ohne dem besagten Sicherheitscode. Die Betrueger benutzen dann ein Programm, dass die URL genau nachbilden kann, die aufgerufen wird, wenn die Zeit abgelaufen ist und die Punkte verguetet werden (worum es den Fakern geht). Es wird also nicht das Frameset mit der beworbenen Seite unten und oben das Zeit-Frame aufgerufen, sondern nur die Gutschrift-Seite. Ohne Code in der URL und Code im Muster-Bild ist dies kein Problem. Nehmen wir nun an, wir wuerden den Code im Muster-Bild direkt in die URL einbinden, so kann dies auch mit wenigen Aenderungen am Faker-Programm umgangen werden. Wenn JavaScript abgeschaltet wird, geht zwar im Browser nichts mehr, aber das Faker-Programm funktioniert immer noch. Es musste also ein besserer Schutz her. Und hier kommt der Absicherungsmechanismus mit dem sogn. Site-Key und Date-Key zur Geltung. Der Site-Key ist ein von mir zufallsmaessig eingegebener Code. Diesen koennen - und in Sachen Sicherheit - sollten Sie ihn auch aendern. Der Code sollte dabei aus Zahlen, Buchstaben und anderen Zeichen bestehen. Diese koennen Sie wild durcheinander eingeben. Wollen Sie die doppelten Anfuehrungszeichen eingeben, so "escape-n" Sie diese bitte, indem Sie ein \ direkt vor das Anfuehrungszeichen setzen. Das sieht dann so aus: \" Dies muss sein, da der Site-Key auch in doppelten Anfuehrungszeichen steht und es somit zu Scriptfehlern kommen wuerde. Dann gibt des den Date-Key. Dieser ist einfach das aktuelle Datum im amerikanischem Format. Auch hier koennen Sie das Format gerne auf deutsch usw. umstellen. Sie sollten dabei auf keinem Fall die Sekundenzahl mit einbinden. Falls Sie von Ihren Mitgliedern zu viele negative Rueckmeldungen erhalten, so koennen Sie zwar den grafischen Code abschalten (Code-Laenge=0 unter "Einstellungen->Sonstige Einstellungen"), jedoch nicht den URL-Schutz. Ihre Mitglieder muessen weiterhin einmal einen Button anklicken. Diese beiden Codes stehen in der inc/cache/config-local.php und koennen nach den oben genannten Regeln geaendert werden. Wird eine Mail bestaetigt so, erzeugt das PHP-Script mailid.php per rand() Funktion eine Zufallszahl zwichen 0 und 99999. Diese wird beim Laden der Seite mit der Code-Eingabe an die URL dran gehaengt. Im selben Script mailid.php werden die beiden Codes mit dem User-Agent (genaue Browserbezeichnung) und der Zufallszahl aus der URL aneinander gehaengt und hexdec() codiert. Aus der dann resultierenden Zahl werden so viele Stellen nach dem Dezimalpunkt extrahiert, wie viel Sie im Admin-Bereich eingestellt haben. Weil die Zahl aus der URL mit den beiden Keys und dem User-Agent zusammen codiert werden, sind diese unterschiedlich und koennen auch beim Abgleich des eingegebenen Codes wieder neu generiert werden, da vor dem Ableich nach dem selben Muster codiert wird. Dieses Verfahren haben die Entwickler von PHP-Nuke entwickelt (http://www.phpnuke.org) und unterliegt genau wie mein Script der GNU GPL. 2. IP- und E-Mail-Sperre im Anmeldeformular ------------------------------------------- Im Anmeldeformular gibt es eine zeitbegrenzte IP-Sperre. Diese soll verhindern, dass der selbe Internet-User sich direkt hintereinander mit unterschiedlichen E-Mail-Adressen anmelden kann. Gegen die selbe E-Mail Adresse besteht auch weiterhin ein Schutzmechanimus. Es ist also weder moeglich, sich mit gleicher E-Mail-Adresse, noch innerhalb einer einstellbaren Zeitspanne mit unterschiedlichen E-Mail-Adressen anzumelden. Beide Barrieren koennen Sie im Admin-Bereich veraendern, die Standard- Einstellungen sind mit einigen Webmastern abgeklaert und sollte sicher genug sein. 3. Modul-Sicherheit ------------------- Anfangs habe ich auch hier das Sicherheitssystem von PHP-Nuke (http://www.phpnuke.org) uebernommen. Ich merkte aber bald, dass dies beim Programmieren sehr mueselig ist und habe mich fuer eine abgewandelte Version entschieden. Die Idee, Include-Dateien im Header gegen das direkte Aufrufen abzusichern habe ich aber dennoch von PHP-Nuke uebernommen. Diese Sicherheitsbarriere ist fuer den normalen Besucher nicht sichtbar. Erst wenn er versucht, Include-Dateien direkt aufzurufen (inc/cache/config-local.php beispielsweise), so wird eine rote Warnseite angezeigt und der Ablauf des Scriptes "stirbt". Diese Grundsicherheit des Script kann nicht deaktiviert werden (ausser Sie sind verrueckt genug und loeschen die Sperren aus jedem Script, selbstverstaendlich ist dann keine Sicherheit mehr gewaehrt und jeglicher Support-Anspruch verfallen). 4. SQL-Injektionen und XSS-Attacken ----------------------------------- Bis zur Version 0.2.0-pre10 mit Patch-Level 485 und aelter war es fuer einen entfernten Angreifer theoretisch moeglich, SQL-Befehle einzuschleusen und auch Attacken auf die Variable $PHP_SELF durchzufueheren. Seit Patch 486 und 487 (laden Sie sich am Besten immer die aktuellsten Patches herunter!) sind nun entsprechende Zeilen aus der inc/db/lib-mysql3.php (Funktion sqlQueryEscaped) entfernt und sollten nicht mehr angreifbar sein. Der generierten SQL-Befehl wurde vor der Ausfuehrung nochmals "uebersetzt", also alle sicherheitsgefaehrdenen Zeichen wieder eingebaut. Zudem existiert im Script inc/libs/security_functions.php am Ende des Scriptes ein Mechanismus, der XSS-Attacken verhindern soll (und es auch gut getan hat). 5. URL-Sperre ------------- Was weniger mit der direkten Sicherheit des Scriptes zu tun hat, sondern eher Ihren Mailtausch von Betruegern schuetzen soll, ist die Moeglichkeit, eine zeitgesteuerte URL-Sperre einzurichten. Die selbe URL kann somit fuer eine einstellbare Zeit nicht mehr beworben werden. Ich empfehle hier dabei mindestens 1 Tag, wenn nicht sogar eher 2 Tage. Leider ist diese Sperre mit dynamischen URLs leicht umrundbar. Es haelt jedoch die Anfaenger fern. Zudem koennen Sie unter 7. in dieser Dokumentation erfahren, wie der neue URL-Filter arbeiten wird und wieso er implementiert wird. 6. Profilsperre --------------- Gleich wie die URL-Sperre URLs vor doppelter Bewerbung "schuetzt", so schuetzt auch die Profilsperre das Mitgliederprofil vor erneutem Editieren innerhalb einer bestimmten Zeit. Zudem arbeiten beide Sperren "Hand-In-Hand", was bedeutet, dass sobald ein Mitglied eine Mail gebucht hat, fuer eine gewisse Zeit sein Profil nicht mehr aendern kann. Auch diese Sperre gilt den Betruegern, die nach dem Versand ihren Empfang auf 0 stellten und vor dem Versand (vor 00:00 Uhr) ihn hochstellten, um zu versenden. Folglich konnten die anderen Mitglieder weniger empfangsbereite Mitglieder erreichen. 7. URL-Filtersystem ------------------- Das neuartige Filtersystem filtert URLs heraus, die nicht den Normungen entsprechen. Dies soll zum einem verhindern - ich hatte es ebenfalls in einem anderen Mailtausch mehrfach erlebt - dass URLs, wie mailto:adresse@host.de beworben werden (oder auch Skype-Adressen). Aber es verhindert auch, dass "boese" URLs, die den Server angreifen sollen, in das System legal gelangen und somit alle Computer der Mitglieder - oder wenigstens den Computer des Admins angreifen koennen (Trojaner). Das URL-Filtersystem selber basiert auf einer Meta-Sprache, die dann gueltige URL-Filter (regulaere Ausdruecke) generiert und diese dann auf die beworbene URL anwendet. Das Filtersystem laesst sich nun bald per Internet aktualisieren, was das Aktuellhalten dann sehr stark vereinfacht. Die beworbene URL wird uebrigens vom URL-Lader (Dereferrer) nochmals vom Filter- System untersucht. x. Haftbarkeit -------------- Querverweis auf die README.de-Datei... [EOF]