DOCS/en/SECURITY.txt

   1 Deutschsprachige Informationen zu den Sicherheitsvorkehrungen
   2 =============================================================
   3
   4 Themenuebersicht:
   5 -----------------
   6
   7 1. Sicherheitscode beim Bestaetigen der Mails
   8 2. IP- und E-Mail-Sperre im Anmeldeformular
   9 3. Modul-Sicherheit
  10 4. SQL-Injektionen und XSS-Attacken
  11 5. URL-Sperre
  12 6. Profilsperre
  13 7. URL-Filtersystem
  14 x. Haftbarkeit
  15
  16 --- --- --- --- ---
  17
  18 1. Sicherheitscode beim Bestaetigen der Mails
  19 ---------------------------------------------
  20
  21 Der Sicherheitscode gilt als eine Sicherheitsbarriere gegen Betrueger, die nur
  22 Punkte ansammeln wollen und das moeglichst ohne die beworbene Seite zu besuchen
  23 und sich anzusehen. Und genau dafuer ist der Mailtausch ja da, es soll die
  24 beworbene Seite besucht werden. Auch dieses Script kann natuerlich nicht 100%-ig
  25 dafuer sorgen, dass die Seite auch tatsaechlich besucht werden. Dazu gibt es
  26 andere Methoden, die hier den Rahmen der Datei sprengen wuerden.
  27
  28 Aber nun zum eigentlichen Thema zurueck. Wir nehmen erstmal an, der Code haetten
  29 wir nicht eingebaut.
  30
  31 Die Betrueger benutzen dann ein Programm, dass die URL genau nachbilden kann, die
  32 aufgerufen wird, wenn die Zeit abgelaufen ist und die Punkte verguetet werden
  33 (worum es den Fakern geht). Es wird also nicht das Frameset mit der beworbenen
  34 Seite unten und oben das Zeit-Frame aufgerufen, sondern nur die Gutschrift-Seite.
  35
  36 Ohne Code in der URL und Code im Muster-Bild ist dies kein Problem.
  37
  38 Nehmen wir nun an, wir wuerden den Code im Muster-Bild direkt in die URL
  39 einbinden, so kann dies auch mit wenigen Aenderungen am Faker-Programm umgangen
  40 werden.
  41
  42 Wenn JavaScript abgeschaltet wird, geht zwar im Browser nichts mehr, aber das
  43 Faker-Programm funktioniert immer noch. Es musste also ein besserer Schutz her.
  44
  45 Und hier kommt der Absicherungsmechanismus mit dem sogn. Site-Key und Date-Key
  46 zur Geltung.
  47
  48 Der Site-Key ist ein von mir zufallsmaessig eingegebener Code. Diesen koennen -
  49 und in Sachen Sicherheit - und sollten Sie ihn auch aendern. Der Code sollte
  50 dabei aus Zahlen, Buchstaben und anderen Zeichen bestehen. Diese koennen Sie
  51 wild durcheinander eingeben. Wollen Sie die doppelten Anfuehrungszeichen
  52 eingeben, so "escape-n" Sie diese bitte, indem Sie ein \ direkt vor das
  53 Anfuehrungszeichen setzen. Das sieht dann so aus: \" Dies muss sein, da der
  54 Site-Key auch in doppelten Anfuehrungszeichen steht und es somit zu
  55 Scriptfehlern kommt.
  56
  57 Dann gibt des den Date-Key. Dieser ist einfach das aktuelle Datum im
  58 amerikanischem Format. Auch hier koennen Sie das Format gerne auf deutsch
  59 umstellen.
  60
  61 Diese beiden Codes stehen in der inc/config.php und koennen nach den oben
  62 genannten Regeln geaendert werden.
  63
  64 Wird eine Mail bestaetigt so, erzeugt das PHP-Script mailid_top.php in Zeile 229
  65 per rand() Funktion eine Zufallszahl zwichen 0 und 99999. Diese wird beim Laden
  66 der Seite mit der Code-Eingabe an die URL dran gehaengt.
  67
  68 Im Script mailid_top.php, Zeile 124 werden die beiden Codes mit dem User-Agent
  69 (genaue Browserbezeichnung) und der Zufallszahl aus der URL aneinander gehaengt
  70 und hexdec() codiert. Aus der dann resultierenden Zahl werden so viele Stellen
  71 nach dem Dezimalpunkt extrahiert, wie viel Sie im Admin-Bereich eingestellt
  72 haben.
  73
  74 Weil die Zahl aus der URL mit den beiden Keys und dem User-Agent zusammen
  75 codiert werden, sind diese unterschiedlich und koennen auch beim Abgleich des
  76 eingegebenen Codes wieder neu generiert werden, da vor dem Ableich nach dem
  77 selben Muster codiert wird.
  78
  79 Dieses Verfahren haben die Entwickler von PHP-Nuke entwickelt
  80 (http://www.phpnuke.org) und unterliegt genau wie unsere LITE-Version der GNU
  81 GPL.
  82
  83 Die PRO-Version wird bald diesbezueglich ein wenig abgeaendet, damit ein evtl.
  84 Rechtsstreit vorgebeugt ist.
  85
  86 2. IP- und E-Mail-Sperre im Anmeldeformular
  87 -------------------------------------------
  88
  89 Im Anmeldeformular gibt es eine zeitbegrenzte IP-Sperre. Diese soll verhindern,
  90 dass der selbe Internet-User sich direkt hintereinander mit unterschiedlichen
  91 E-Mail-Adressen anmelden kann. Gegen die selbe E-Mail Adresse besteht auch
  92 weiterhin ein Schutzmechanimus.
  93
  94 Es ist also weder moeglich, sich mit gleicher E-Mail-Adresse, noch innerhalb
  95 einer einstellbaren Zeitspanne mit unterschiedlichen E-Mail-Adressen anzumelden.
  96
  97 Beide Barrieren koennen Sie im Admin-Bereich veraendern, die Standart-
  98 Einstellung ist mit einigen Webmastern abgeklaert und sollte sicher genug sein.
  99
 100 3. Modul-Sicherheit
 101 -------------------
 102
 103 Anfangs habe ich auch hier das Sicherheitssystem von PHP-Nuke
 104 (http://www.phpnuke.org) uebernommen. Ich merkte aber bald, dass dies beim
 105 Programmieren sehr mueselig ist und habe mich fuer eine abgewandelte Version
 106 entschieden. Die Idee, Include-Dateien so abzusichern habe ich aber dennoch von
 107 PHP-Nuke uebernommen.
 108
 109 Diese Sicherheitsbarriere ist fuer den normalen Besucher nicht sichtbar. Erst
 110 wenn er versucht, Include-Dateien direkt aufzurufen (inc/config.php
 111 beispielsweise), so wird eine rote Warnseite angezeigt und der Ablauf des
 112 Scriptes "stirbt".
 113
 114 Diese Grundsicherheit des Script kann nicht deaktiviert werden (ausser Sie sind
 115 verrueckt genug und loeschen die Sperren aus jedem Script, selbstverstaendlich ist
 116 das keine Sicherheit mehr gewaehrt und jeglicher Support-Anspruch verfaellt).
 117
 118 4. SQL-Injektionen und XSS-Attacken
 119 -----------------------------------
 120
 121 Bis zur Version 0.2.0-pre10 mit Patch-Level 485 und aelter war es fuer einen
 122 entfernten Angreifer theoretisch moeglich, SQL-Befehle einzuschleusen und auch
 123 Attacken auf die Variable $PHP_SELF durchzufueheren. Seit Patch 486 und 487
 124 (laden Sie sich am Besten immer die aktuellsten Patches herunter!) sind nun
 125 entsprechende Zeilen aus der inc/db/lib-mysql3.php (Funktion SQL_QUERY_ESC)
 126 entfernt sollten nicht mehr angreifbar sein. Der generierten SQL-Befehl wurde
 127 vor der Ausfuehrung nochmals "uebersetzt", also alle sicherheitsgefaehrdenen
 128 Zeichen wieder eingebaut. Zudem existiert im Script
 129 inc/libs/security_functions.php am Ende des Scriptes ein Mechanismus, der
 130 XSS-Attacken vereiteln soll (und bis jetzt auch gut getan hat).
 131
 132 5. URL-Sperre
 133 -------------
 134
 135 Was weniger mit der direkten Sicherheit des Scriptes zu tun hat, sondern eher
 136 Ihren Mailtausch von Betruegern schuetzen soll, ist die Moeglichkeit, eine
 137 zeitgesteuerte URL-Sperre einzurichten. Die selbe URL kann somit fuer eine
 138 einstellbare Zeit nicht mehr beworben werden. Das Entwickler-Team empfiehlt
 139 hier dabei mindestens 1 Tag, wenn nicht sogar eher 2 Tage.
 140
 141 Leider ist diese Sperre mit dynamischen URLs leicht umrundbar. Es haelt jedoch
 142 die Anfaenger fern.
 143
 144 6. Profilsperre
 145 ---------------
 146
 147 Gleich wie die URL-Sperre URLs vor doppelter Bewerbung "schuetzt", so schuetzt
 148 auch die Profilsperre das Mitgliederprofil vor erneutem Editieren innerhalb einer
 149 bestimmten Zeit. Zudem arbeiten beide Sperren "Hand-In-Hand", was bedeutet, dass
 150 sobald ein Mitglied eine Mail gebucht hat, fuer eine gewisse Zeit sein Profil
 151 nicht mehr aendern kann. Auch diese Sperre gilt den Betruegern, die nach dem
 152 Versand ihren Empfang auf 0 stellten und vor dem Versand (vor 00:00 Uhr) ihn
 153 hochstellten, um zu versenden. Folglich konnten die anderen Mitglieder weniger
 154 empfangsbereite Mitglieder erreichen.
 155
 156 7. URL-Filtersystem
 157 -------------------
 158
 159 Das neuartige Filtersystem filtert URLs heraus, die nicht den Normungen
 160 entsprechen. Dies soll zum einem verhindern - wir hatten es ebenfalls in einem
 161 anderen Mailtausch mehrfach erlebt - dass URLs, wie mailto:adresse@host.de
 162 beworben werden (oder auch Skype-Adressen). Aber es verhindert auch, dass "boese"
 163 URLs, die den Server angreifen sollen, in das System legal gelangen und somit
 164 alle Computer der Mitglieder - oder wenigstens den Computer des Admins angreifen
 165 koennen (Trojaner).
 166
 167 Das URL-Filtersystem selber basiert auf einer Meta-Sprache, die dann gueltige
 168 URL-Filter (regulaere Ausdruecke) generiert und diese dann auf die beworbene URL
 169 anwendet. Das Filtersystem laesst sich nun bald per Internet aktualisieren, was
 170 das Aktuellhalten dann sehr stark vereinfacht.
 171
 172 Die beworbene URL wird uebrigens vom URL-Lader (Dereferrer) nochmals angewand!
 173
 174 x. Haftbarkeit
 175 --------------
 176
 177 Querverweis auf die README.de-Datei...
 178
 179 [EOF]