| ... |
... |
@@ -16,40 +16,46 @@ |
| 16 |
16 |
|
| 17 |
17 |
==== Tracking-Mode ==== |
| 18 |
18 |
|
| 19 |
|
-Standardmäßig wird {{formcycle/}} in einer Konfiguration ausgeliefert in der sowohl die Formulare als auch die Verwaltungsoberfläche mit und ohne akzeptierte Cookies betrieben werden kann. Hierfür ist durch die Anwendung keine Einschränkung des sogenannten Tracking-modes konfiguriert. Sollten keine Cookies akzeptiert werden, so wird die Sitzungs-ID durch den Server (z.B. Tomcat) in die URL geschrieben. Ist die Benutzung von Cookies in allen gegebenen Anwendungsfällen und Umgebungen möglich, sollte dieses Verhalten hierfür abgeändert werden. Hintergrund ist, dass durch eine unachtsam weitergegebene URL mit Sitzungs-ID sonst sogenanntes Session-Hijacking möglich ist und dadurch ein Angreifer unberechtigte Zugriffe erlangen könnte. |
|
19 |
+Standardmäßig wird {{formcycle/}} in einer Konfiguration ausgeliefert in der sowohl die Formulare als auch die Verwaltungsoberfläche mit und ohne akzeptierten Cookies betrieben werden kann. Hierfür ist durch die Anwendung keine Einschränkung des sogenannten Tracking-modes konfiguriert. Sollten keine Cookies akzeptiert werden, so wird die Sitzungs-ID durch den Server (z.B. Tomcat) in die URL geschrieben. Ist die Benutzung von Cookies in allen gegebenen Anwendungsfällen und Umgebungen möglich, sollte dieses Verhalten hierfür angepasst werden. Hintergrund ist, dass durch eine unachtsam weitergegebene URL mit Sitzungs-ID sonst sogenanntes Session-Hijacking, also die ungewollte Übernahme einer Sitzung möglich ist und Angreifer so unberechtigte Zugriffe erlangen könnte. |
| 20 |
20 |
|
| 21 |
21 |
Konfiguration des Tracking-Modes: [[hier>>doc:Formcycle.SystemSettings.TomcatSettings.WebHome||anchor="HSession-Tracking" rel="noopener noreferrer" target="_blank"]] |
| 22 |
22 |
|
| 23 |
23 |
==== Cookie-Konfiguration ==== |
| 24 |
24 |
|
| 25 |
|
-Sollte {{formcycle/}} ausschließlich über HTTPS betrieben werden ist es empfohlen die entsprechende Einstellung für Cookies zu hinterlegen. Diese verhindert, dass die Cookies bei Aufrufen über HTTP gesetzt und benutzt werden. Sollte {{formcycle/}} dennoch über HTTP aufgerufen werden, so greift der ggf. noch vorhandene Fallback mit in der URL kodierten Session-ID. |
|
25 |
+Sollte {{formcycle/}} ausschließlich über HTTPS betrieben werden ist es empfohlen das sogenannte //secure//-Flag an Cookies zu aktivieren. Dieses verhindert, dass die Cookies bei Aufrufen über HTTP gesetzt und benutzt werden. Sollte dieses Flag gesetzt werden und {{formcycle/}} dennoch über HTTP aufgerufen werden, so greift der ggf. noch vorhandene Fallback mit der Sitzungs-ID innerhalb der URLs. Sollte wiederrum der Tracking-Mode (siehe oben) wie empfohlen nur Cookies verwenden und bei gesetztem //secure//-Flag ein Aufruf über HTTP erfolgen, ist weder ein Login noch die Benutzung der Verwaltungsoberfläche noch das Erfolgreiche Absenden von Formularen möglich. |
| 26 |
26 |
|
| 27 |
|
-Je nach Umgebung und Anwendungsfall ist es möglich die maximale Dauer einer Sitzung zu limitieren. Dies bezieht sich hierbei sowohl auf die Sitzung innerhalb des Formulars, als auch die der Verwaltungsoberfläche. Sobald keine Kommunikation zwischen Browser und Server für den gegebenen Zeitraum mehr stattfindet wird die Sitzung invalidiert. Um dies beim Ausfüllen von großen Formularen oder dem Arbeiten innerhalb der Verwaltungsoberfläche zu umgehen, ist hier ein Keep-Alive-Mechanismus implementiert welcher in Regelmäßigen Abständen ein Lebenszeichen an den Server übermittelt. Sollte nun das Fenster oder der Browser geschlossen werden oder durch z.B. Sperren des Endgerätes nicht mehr aktiv sein, fällt dieser Mechanismus weg und der Benutzer wird nach Ablauf der konfigurierten Zeit abgemeldet. |
|
27 |
+Konfiguration des Session-Cookies: [[hier>>doc:Formcycle.SystemSettings.TomcatSettings.WebHome||anchor="HCookie-Konfiguration" target="_blank"]] |
| 28 |
28 |
|
| 29 |
|
-Auch lässt sich das Cookie hier weiter anpassen indem z.B. der Standardname oder der Standard-Pfad und die Domäne angepasst wird. |
|
29 |
+Auch lässt sich das Sitzungs-Cookie hier weitergehend anpassen indem z.B. der Standard-Name, der Standard-Pfad, die Domäne oder auch separat die Gültigkeitsdauer geändert wird. Letztes sollte jedoch immer mit Hinblick auf das maximale Sitzungsdauer geschehen. |
| 30 |
30 |
|
| 31 |
|
-Weitere Details unter [[Cookie-Konfiguration>>doc:Formcycle.SystemSettings.TomcatSettings.WebHome||anchor="HCookie-Konfiguration" target="_blank"]] |
|
31 |
+==== Session-Timeout ==== |
| 32 |
32 |
|
|
33 |
+Je nach Umgebung und Anwendungsfall ist es möglich die maximale Dauer einer Sitzung zu limitieren. Dies bezieht sich hierbei sowohl auf die Sitzung innerhalb des Formulars, als auch die der Verwaltungsoberfläche. Sobald keine Kommunikation zwischen Browser und Server für den gegebenen Zeitraum mehr stattfindet wird die Sitzung inklusiever aller zugehörigen Daten zerstört. Um dies beim Ausfüllen von großen Formularen oder dem Arbeiten innerhalb der Verwaltungsoberfläche zu umgehen, ist hier ein Keep-Alive-Mechanismus vorhanden welcher in regelmäßigen Abständen ein Lebenszeichen an den Server übermittelt. Sollte nun das Fenster oder der Browser geschlossen werden oder durch z.B. Sperren des Endgerätes nicht mehr aktiv sein, fällt dieser Mechanismus weg und der Benutzer wird nach Ablauf der konfigurierten Zeit abgemeldet. |
|
34 |
+ |
|
35 |
+Konfiguration des Session-Timeouts: [[hier>>doc:Formcycle.SystemSettings.TomcatSettings.WebHome||anchor="HSession-Timeout" target="_blank"]] |
|
36 |
+ |
| 33 |
33 |
=== Härtung der Server === |
| 34 |
34 |
|
| 35 |
|
-Alle bei der Kommunikation von FORMCYCLE mit dem Endanwender benutzten Server sollten soweit wie möglich gehärtet werden. Dies bedeutet vor allem, dass neben dem Einspielen regelmäßiger Sicherheitsupdates auch alle unnötigen Zugriffe deaktiviert oder verhindert werden sollten. Auch ist dem Prinzip des „Information hidings“ zu folgen. Dies bedeutet, dass jegliche nicht nötige Information der Infrastruktur nach außen versteckt werden sollte. Diese geben Angreifern sonst Hinweise auf mögliche Angriffsmöglichkeiten. Typtische Informationen und Situationen sind hierbei folgende: |
|
39 |
+Neben dem eigentlichen Server auf dem {{formcycle/}} betrieben wird ies es empfohlen alle bei der Kommunikation relevanten Server soweit wie möglich zu härten. Dies bedeutet vor allem, dass neben dem Einspielen regelmäßiger Sicherheitsupdates auch alle unnötigen Zugriffe deaktiviert oder verhindert werden sollten. Auch ist dem Prinzip des „Information hiding“ zu folgen. Dies bedeutet, dass jegliche nicht nötige Information der Infrastruktur nach außen versteckt werden sollte. Hintergrund ist, dass diese sonst Angreifern Hinweise auf mögliche Angriffsmöglichkeiten in Form von zum Beispiel eingesetzten Software-Versionen bietet. Typtische Quellen für solche Informationen sind hierbei folgende: |
| 36 |
36 |
|
| 37 |
|
-* Rückgabe des Verwendeten Servers innerhalb von HTTP-Headern. Dies geschieht meist mit Versionsnummern welche den Patch-Stand des Servers preisgibt |
|
41 |
+* Rückgabe des verwendeten Servers innerhalb von HTTP-Headern. Dies geschieht meist mit Versionsnummern welche den Patch-Stand des Servers preisgibt |
| 38 |
38 |
* Ausgabe der Server-Informationen auf Standard-Fehlerseiten |
| 39 |
39 |
* Verwendung von erkennbaren Standard-Fehlerseiten welche Rückschlüsse auf den Server geben können |
| 40 |
|
-* Betrieb von Standard-Anwendungen (z.B. der Tomcat Manager) welcher zum einen den Server-Typ preisgibt, zum anderen auch weitere Angriffspunkt liefert |
|
44 |
+* Betrieb von Standard-Anwendungen (z.B. der Tomcat Manager) welcher zum einen den Server-Typ preisgibt, zum anderen selbst auch weitere Angriffspunkt liefert |
| 41 |
41 |
|
| 42 |
|
-Weitere Details unter [[Link-Text eingeben>>Härtung des Servers||target="_blank"]] |
|
46 |
+Details für die Härung des Tomcat-Servers: [[hier>>doc:Formcycle.SystemSettings.TomcatSettings.Härtung des Servers.WebHome||target="_blank"]] |
| 43 |
43 |
|
| 44 |
44 |
=== Einschränkung des Backend-Zugriffs (z.B. über Frontend-Server) === |
| 45 |
45 |
|
| 46 |
|
-Sollte es im Anwendungsfall nicht anders vorgesehen sein, so sollte der Zugriff auf die Verwaltungsoberfläche nur intern ermöglicht werden. Dies lässt sich z.B. über Firewalls, Revers-Proxies oder Load-Balancer realisieren. Auch Kann hierfür der Frontend-Server zum Einsatz kommen. Je nach Anwendungsszenario ist dieser komplett ohne Oberfläche oder nur mit Postfach verwendbar. Diese können so z.B. in einer DMZ betrieben werden während der Master-Server inkl. Verwaltungsoberfläche im Intranet betrieben wird. Somit ist die Erstellung/Pflege von Formularen und Daten nur hier möglich während Formulare über den Frontend-Server auch über das Internet benutzt werden können. |
|
50 |
+Sollte es im Anwendungsfall nicht anders vorgesehen sein, so sollte der Zugriff auf die Verwaltungsoberfläche nur internen Benutzern ermöglicht werden. Dies lässt sich z.B. über Firewalls, Revers-Proxies oder Load-Balancer realisieren welche die Verwaltungsoberflächen (//http(s):~/~/server/formcycle/ui///) komplett vor Zugriffen aus dem Internet sperren. Auch kann hierfür der Frontend-Server zum Einsatz kommen. Je nach Anwendungsszenario ist dieser komplett ohne Oberfläche oder nur mit Postfach verwendbar. Dieser können so z.B. in einer DMZ betrieben werden während der Master-Server inkl. Verwaltungsoberfläche im Intranet betrieben wird und mit diesem kommuniziert. Somit ist die Erstellung bzw. Pflege von Formularen und Daten nur intern möglich während Formulare über den Frontend-Server auch über das Internet bereitgestellt werden können. |
| 47 |
47 |
|
| 48 |
|
-Weitere Details unter [[Frontend- und Master-Server>>doc:Formcycle.SystemSettings.FrontendAndMasterServer||target="_blank"]] und [[Betrieb hinter Proxy/Load-Balancer o.ä.>>doc:Formcycle.Installation.IntermediateServers||target="_blank"]] |
|
52 |
+Details über Frontend- und Master-Server: [[hier>>doc:Formcycle.SystemSettings.FrontendAndMasterServer||target="_blank"]] |
| 49 |
49 |
|
|
54 |
+Details über den Betrieb hinter Proxy, Load-Balancer oder ähnlichem: [[hier>>doc:Formcycle.Installation.IntermediateServers||target="_blank"]] |
|
55 |
+ |
| 50 |
50 |
=== Verwendung eines Viren-Scanners === |
| 51 |
51 |
|
| 52 |
|
-Um das Entgegennehmen von schädlichen Dateien oder Eingaben zu verhindern ist es empfohlen auf dem entsprechenden {{formcycle/}}-Server (Master- und/oder Frontend) einen Virenscanner zu betreiben. Dieser kann auf das {{formcycle/}}-Datenverzeichnis konfiguriert werden und sollte alle schädlichen Dateien löschen. {{formcycle/}} erkennt anschließend, dass eine eigentlich abgesendete Datei entfernt wurde bzw. leer ist und vermerkt dies innerhalb des Vorgangs in der Übersicht der Uploads. |
|
58 |
+Um das Entgegennehmen von schädlichen Dateien oder Eingaben zu verhindern ist es empfohlen auf dem entsprechenden {{formcycle/}}-Server (Master- und/oder Frontend) einen Virenscanner zu betreiben. Dieser kann auf das {{formcycle/}}-Datenverzeichnis konfiguriert werden und sollte somit alle schädlichen Dateien löschen. {{formcycle/}} erkennt anschließend, dass eine eigentlich abgesendete Datei entfernt wurde bzw. leer ist und vermerkt dies innerhalb des Vorgangs in der Übersicht der hochgeladenen Dateien. |
| 53 |
53 |
|
| 54 |
54 |
== Konfigurationen innerhalb von {{formcycle/}} == |
| 55 |
55 |
|
