+++ /dev/null
-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. Wir nehmen erstmal an, der Code haetten
-wir nicht eingebaut.
-
-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 - und 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 kommt.
-
-Dann gibt des den Date-Key. Dieser ist einfach das aktuelle Datum im
-amerikanischem Format. Auch hier koennen Sie das Format gerne auf deutsch
-umstellen.
-
-Diese beiden Codes stehen in der inc/config.php und koennen nach den oben
-genannten Regeln geaendert werden.
-
-Wird eine Mail bestaetigt so, erzeugt das PHP-Script mailid_top.php in Zeile 229
-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 Script mailid_top.php, Zeile 124 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 unsere LITE-Version der GNU
-GPL.
-
-Die PRO-Version wird bald diesbezueglich ein wenig abgeaendet, damit ein evtl.
-Rechtsstreit vorgebeugt ist.
-
-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 Standart-
-Einstellung ist 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 so 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/config.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
-das keine Sicherheit mehr gewaehrt und jeglicher Support-Anspruch verfaellt).
-
-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 SQL_QUERY_ESC)
-entfernt 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 vereiteln soll (und bis jetzt 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. Wir empfehlen 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.
-
-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 - wir hatten 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 angewand!
-
-x. Haftbarkeit
---------------
-
-Querverweis auf die README.de-Datei...
-
-[EOF]
projects / mailer.git / blobdiff