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