Show last authors
1 {{info}}
2
3 The {{formcycle/}} Versions 7.0.0 through 7.0.11 contain a version of the Spring Framework that contains the [[CVE-2022-22965>>https://tanzu.vmware.com/security/cve-2022-22965]] vulnerability disclosed on March 31st, 2022.
4 The {{formcycle/}} Versions 7.0.0 through 7.0.6 use a version of Log4j that contains the [[CVE-2021-44228>>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228]] vulnerability disclosed on December 10th, 2021.
5 The {{formcycle/}} versions 7.0.0 through 7.0.7 use a version of Log4j that contains the [[CVE-2021-45046>>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046]] vulnerability disclosed on December 14th, 2021.
6 The {{formcycle/}} versions 7.0.0 through 7.0.8 use a version of Log4j that contains the [[CVE-2021-45105>>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105]] vulnerability disclosed on December 18th, 2021.
7 The {{formcycle/}} versions 7.0.0 through 7.0.9 use a version of Log4j that contains the [[CVE-2021-44832>>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832]] vulnerability disclosed on December 11th, 2021.
8
9 Currently, we are not aware of any scenario where these vulnerabilities in {{formcycle/}} can be exploited. **We still recommend to upgrade to {{formcycle/}} [[Version 7.0.12>>doc:Blog.WebHome]], which uses new versions of Log4j and the Spring Framework that no longer contain these vulnerabilities.**
10 {{/info}}
11
12 {{info}}
13
14 For installations where upgrading to the latest {{formcycle/}} version is not possible, we recommend implementing the [[vendor>>https://logging.apache.org/log4j/2.x/security.html]] recommended mitigation for __CVE-2021-44228__. For the Log4j version used by the potentially affected {{formcycle/}} versions this means setting the {{code language="none"}}-Dlog4j2.formatMsgNoLookups=true{{/code}} option in the Java options for the servlet container used.
15
16 For example, for an Apache Tomcat running on Windows, this can be done in //Tomcat Monitor// at the following location:
17 [[image:tomcat_log4j_settings.png||width="350"]]
18
19 On Linux, environment variables are usually set in the {{code language="none"}}setenv.sh{{/code}} file for Apache Tomcat installations. After setting the parameter, this file could then for example have the following content for the Java options:
20 {{code language="none"}}export JAVA_OPTS="-Dfile.encoding=UTF-8 -Xms1024m -Xmx4096m -Dlog4j2.formatMsgNoLookups=true"{{/code}}
21
22 When using servlet containers other than Apache Tomcat, please consult the documentation for that servlet container for the location at which this parameter can be passed.
23
24 If an upgrade to the latest {{formcycle/}} version is not possible, mitigation of __CVE-2021-45046__ & __CVE-2021-45105__ is only necessary if logpatterns containing [[affected configurations>>https://logging.apache.org/log4j/2.x/security.html]] have been manually configured. In this case, the corresponding patterns should be removed.
25 {{/info}}
26
27 {{content/}}
28
29 For the most secure operation of {{formcycle/}}, different configurations are possible or recommended depending on the system environment and use cases. A distinction must be made between the configuration of the environment, such as the Tomcat server, any upstream web servers, proxies or load balancers, and the configuration of {{formcycle/}} itself.
30
31 == Environment configurations ==
32
33 === Operation over HTTPS ===
34
35 {{formcycle/}} should, if possible, only be provided via HTTPS on the Internet. This increases the security of the data sent so that it cannot be read within the network or manipulated via man-in-the-middle. If possible, the HTTP connector should be completely disabled.
36
37 Configuration of HTTPS within the Tomcat: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.TomcatSettings.Bereitstellung über HTTPS.WebHome||target="_blank"]]
38
39 === Session Management ===
40
41 For the operation of {{formcycle/}} it is mandatory that the user gets a session known to the server within the administration interface as well as within the form. This must be identical between calling and submitting a form, for example, to ensure a check against automated submission (e.g. for DoS attacks).
42
43 ==== Tracking mode ====
44
45 By default, {{formcycle/}} is delivered in a configuration in which both the forms and the administration interface can be operated with and without accepted cookies. For this, no restriction of the so-called tracking mode is configured by the application. If no cookies are accepted, the session ID is written to the URL by the server (e.g. Tomcat). If the use of cookies is possible in all given use cases and environments, this behavior should be adapted for this. The background to this is that a URL with a session ID that is passed on carelessly could otherwise lead to session hijacking, i.e. the unintentional takeover of a session, and attackers could thus gain unauthorized access.
46
47 Configuration of the tracking mode: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.TomcatSettings.WebHome||anchor="HSession-Tracking" rel="noopener noreferrer" target="_blank"]] (WIP)
48
49 ==== Cookie configuration ====
50
51 If {{formcycle/}} is operated exclusively via HTTPS, it is recommended to activate the so-called //secure// flag on cookies. This prevents the cookies from being set and used when called via HTTP. If this flag is set and {{formcycle/}} is still called via HTTP, the fallback with the session ID within the URLs will take effect. If the tracking mode (see above) uses only cookies as recommended and the //secure// flag is set, the user will not be able to login, use the administration interface or successfully submit forms.
52
53 Configuration of the session cookie: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.TomcatSettings.WebHome||anchor="HCookie-Konfiguration" target="_blank"]] (WIP)
54
55 The session cookie can also be further customized here by, for example, changing the default name, the default path, the domain or even separately the validity period. However, the latter should always be done with regard to the maximum session duration.
56
57 ==== Session timeout ====
58
59 Depending on the environment and use case, it is possible to limit the maximum duration of a session. This refers to the session within the form as well as the session of the administration interface. As soon as there is no more communication between browser and server for the given period of time, the session including all associated data is destroyed. To avoid this when filling out large forms or working within the administration interface, a keep-alive mechanism is available here which transmits a sign of life to the server at regular intervals. If the window or browser is now closed or is no longer active, e.g. by locking the terminal device, this mechanism is dropped and the user is logged out after the configured time has elapsed.
60
61 Configuration of the session timeout: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.TomcatSettings.WebHome||anchor="HSessiontimeout" target="_blank"]]
62
63 === Server hardening ===
64
65 It is recommended that, in addition to the actual server on which {{formcycle/}} is operated, all servers relevant to communication should be hardened as far as possible. This means above all that, in addition to installing regular security updates, all unnecessary accesses should be disabled or prevented. The principle of "information hiding" must also be followed. This means that all unnecessary infrastructure information should be hidden from the outside world. The background to this is that it otherwise provides attackers with clues to possible attack options in the form of the software versions used, for example. Typical sources for such information are as follows:
66
67 * Return of the used server within HTTP headers. This is usually done with version numbers which reveal the patch status of the server.
68 * Output of server information on standard error pages
69 * Use of recognizable standard error pages which can give conclusions about the server
70 * Operation of standard applications (e.g. the Tomcat Manager) which on the one hand reveal the server type, on the other hand also provide further points of attack.
71
72 Details for hardening the Tomcat server: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.TomcatSettings.Härtung des Servers.WebHome||target="_blank"]]
73
74 === Restriction of back-end access (e.g. via frontend server) ===
75
76 If there is no other provision in the use case, access to the administration interface should only be granted to internal users. This can be realized e.g. via firewalls, reverse proxies or load balancers which completely block the administration interfaces (//http(s):~/~/server/formcycle/ui///) from access from the Internet. The frontend server can also be used for this purpose. Depending on the application scenario this can be used completely without interface or only with the inbox. It can be operated in a DMZ, for example, while the master server including the administration interface is operated in the intranet and communicates with it. Thus, the creation or maintenance of forms and data is only possible internally, while forms can also be made available via the Internet using the frontend server.
77
78 Details about frontend and master server: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.FrontendAndMasterServer||target="_blank"]]
79
80 Details about operation behind proxy, load balancer or similar: [[{{formcycle/}} Help>>doc:Formcycle.Installation.IntermediateServers||target="_blank"]]
81
82 === Usage of a virus scanner ===
83
84 To prevent receiving malicious files or input it is recommended to run a virus scanner on the corresponding {{formcycle/}} server (master and/or frontend). This can be configured to the {{formcycle/}} data directory and should thus delete all malicious files. {{formcycle/}} then detects that a file that was actually sent has been removed or is empty and notes this within the process in the overview of uploaded files.
85
86 Details about the data directories of {{formcycle/}}: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.TomcatSettings.ChangeDataDirectory||target="_blank"]]
87
88 == Configurations within {{formcycle/}} ==
89
90 === Encryption of form data/database ===
91
92 It is recommended to include the form data when encrypting {{formcycle/}}-side data. This hardly brings measurable performance losses, but prevents the form data from being read during communication with the database and prevents the data from being read from the database itself without knowledge of the algorithm and password. Also, encryption of the entire database by the DBMS used increases security in the same attack scenario.
93
94 Configuration of application-side database encryption: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.UserInterface.Database||anchor="HDatabaseencryption" target="_blank"]]
95
96 === Encrypted communication with the database ===
97
98 It is recommended to encrypt the complete communication with the database via SSL. Depending on the database manufacturer, other database URLs or special parameters are required for this. Encryption prevents attackers with access to the internal network structures from reading the communication between {{formcycle/}} and the database and thus gaining access to sensitive data.
99
100 Configuration of the database connection: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.UserInterface.Database||anchor="HDatabaseconnection" target="_blank"]]
101
102 For more information about encrypted communication, please refer to the documentation of your database vendor.
103
104 === Encrypted communication between master and frontend server ===
105
106 If a frontend server is used, it is recommended to encrypt the communication with the master server. This is realized via SSL certificate which should not be confused with the certificate for the form delivery via HTTPS. Since this is not visible during communication with the form user and only serves as a kind of password, it is also possible to use a self-generated certificate here. In general, the encryption here ensures that attackers with access to the network traffic cannot read the data transferred between the master and frontend servers.
107
108 Instructions for installing the frontend server incl. SSL: [[{{formcycle/}} Help>>doc:Formcycle.Installation.FrontendServer||target="_blank"]]
109
110 Instructions for setting up the frontend server connection incl. SSL: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.UserInterface.FrontendServer||anchor="HSSLencryption" target="_blank"]]
111
112 === Login and encrypted communication with mail server ===
113
114 If possible, care should be taken when connecting the mail server to ensure that it is protected by a login and that encrypted communication takes place. If this is not the case, it is possible for an attacker with access to the internal network structure to read the mails sent.
115
116 Configuration of the system mail server: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.UserInterface.EmailServer||anchor="HSecurity" target="_blank"]]
117
118 Configuration of client mail servers: [[{{formcycle/}} Help>>doc:Formcycle.UserInterface.Client.Settings||anchor="HUsecustommailserver" target="_blank"]]
119
120 === Password policies ===
121
122 To ensure the most secure login for users it is recommended to either use already existing system environments with appropriate policies (e.g. LDAP) or to define the most secure password policies for users within {{formcycle/}} for your own use case.
123
124 Configuration of password policies: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.UserInterface.General.WebHome||anchor="HPasswordpolicies" target="_blank"]]
125
126 === HTTP Strict Transport Security (HSTS) ===
127
128 HSTS is an HTTP header that can be set to prevent the possibility of a fallback to an insecure HTTP connection. The browser is sent the corresponding header, including the validity period and information about whether it is also valid for subdomains. The browser will now not allow any requests over an unencrypted HTTP connection until the validity period has expired and, if applicable, for all subdomains. If you run {{formcycle/}} exclusively over HTTPS it is recommended to activate this option and to choose a validity as long as possible. Also the option should be used for including subdomains. Note, however, that a deliberate switch to unencrypted HTTP could cause problems for users due to this header and its validity.
129
130 Configuration of the HSTS header: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.UserInterface.General.WebHome||anchor="HHTTPStrictTransportSecurity28HSTS29" target="_blank"]]
131
132 === Restrict referrer policy ===
133
134 The referrer policy specifies whether and how the information of the originally called URL should be passed on to subpages or subsequent pages. This means that, for example, the complete original URL or only the domain (called origin) can be communicated. Since the URLs may contain security-relevant information, it is recommended to select the setting as restrictively as possible. The default value "same-origin" usually provides sufficient protection without affecting any necessary functionality. It specifies that all information is only shared within the same domain and that nothing is transmitted across domains.
135
136 Configuration of the Refferer policy: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.UserInterface.General.WebHome||anchor="HReferrerpolicy" target="_blank"]]
137
138 Further information and possible values: [[Mozilla Help>>url:https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy||rel="noopener noreferrer" target="_blank"]]
139
140 === System internal restrictions ===
141
142 The system-internal restrictions serve both a general functional, as well as resulting technical limitations within different subareas. Here you can globally define the total size of a form (incl. uploads) as well as the size of the individual files. Here, the smallest possible usable value should be selected to protect the system from oversized files or requests.
143
144 Similar is the limitation of the maximum number of rows of a database query as well as the size limitation of the single database cells. A value as low as possible prevents that e.g. in case of selection or AutoComplete fields too many rows are delivered and therefore the performance of the server and the client (i.e. the form in the browser) suffers.
145
146 The third setting for defining the file size from which uploads or form entries are to be written to the hard disk allows fine-tuning of the data to be handled, especially in conjunction with a virus scanner. A value greater than 0 means that form data smaller than this value is only handled within the main memory. This tends to increase performance when submitting the form, but understandably increases the load on the working memory. Also, this data cannot be handled by a file-based virus scanner. If a virus scanner is used or the available RAM is limited, it is recommended to leave this value at 0.
147
148 Configuration of the system internal restrictions: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.UserInterface.General.WebHome||anchor="HSystemlimits" rel="noopener noreferrer" target="_blank"]]
149
150 === Automatic deletion of protocol entries ===
151
152 Since errors are logged within the protocol of {{formcycle/}} during processing, it can happen that e.g. error messages from connected third-party systems are captured. Since {{formcycle/}} does not have control over their content but captures them for troubleshooting purposes, it is recommended to have the log purged regularly via the appropriate configuration. This also prevents the database from being filled with outdated entries that are no longer relevant and, depending on the system limitation, from filling up sooner or later.
153
154 Configuration of automated deletion of protocol entries: [[{{formcycle/}} Help>>doc:Formcycle.SystemSettings.UserInterface.General.WebHome||anchor="HAutomaticdeletionofprotocolentries" target="_blank"]]
155
156