General Security Recommendations

For the most secure operation of Xima® 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 Xima® Formcycle itself.

Environment configurations

Operation over HTTPS

Xima® 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.

Configuration of HTTPS within the Tomcat: Xima® Formcycle Help

Session Management

For the operation of Xima® 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).

Tracking mode

By default, Xima® 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.

Configuration of the tracking mode: Xima® Formcycle Help (WIP)

Cookie configuration

If Xima® 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 Xima® 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.

Configuration of the session cookie: Xima® Formcycle Help (WIP)

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.

Session timeout

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.

Configuration of the session timeout: Xima® Formcycle Help

Server hardening

It is recommended that, in addition to the actual server on which Xima® 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:

• Return of the used server within HTTP headers. This is usually done with version numbers which reveal the patch status of the server.
• Output of server information on standard error pages
• Use of recognizable standard error pages which can give conclusions about the server
• 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.

Details for hardening the Tomcat server: Xima® Formcycle Help

Restriction of back-end access (e.g. via frontend server)

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.

Details about frontend and master server: Xima® Formcycle Help

Details about operation behind proxy, load balancer or similar: Xima® Formcycle Help

Usage of a virus scanner

To prevent receiving malicious files or input it is recommended to run a virus scanner on the corresponding Xima® Formcycle server (master and/or frontend). This can be configured to the Xima® Formcycle data directory and should thus delete all malicious files. Xima® 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.

Details about the data directories of Xima® Formcycle: Xima® Formcycle Help

Configurations within Xima® Formcycle

Encryption of form data/database

It is recommended to include the form data when encrypting Xima® 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.

Configuration of application-side database encryption: Xima® Formcycle Help

Encrypted communication with the database

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 Xima® Formcycle and the database and thus gaining access to sensitive data.

Configuration of the database connection: Xima® Formcycle Help

For more information about encrypted communication, please refer to the documentation of your database vendor.

Encrypted communication between master and frontend server

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.

Instructions for installing the frontend server incl. SSL: Xima® Formcycle Help

Instructions for setting up the frontend server connection incl. SSL: Xima® Formcycle Help

Login and encrypted communication with mail server

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.

Configuration of the system mail server: Xima® Formcycle Help

Configuration of client mail servers: Xima® Formcycle Help

Password policies

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 Xima® Formcycle for your own use case.

Configuration of password policies: Xima® Formcycle Help

HTTP Strict Transport Security (HSTS)

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 Xima® 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.

Configuration of the HSTS header: Xima® Formcycle Help

Restrict referrer policy

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.

Configuration of the Refferer policy: Xima® Formcycle Help

Further information and possible values: Mozilla Help

System internal restrictions

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.

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.

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.

Configuration of the system internal restrictions: Xima® Formcycle Help

Automatic deletion of protocol entries

Since errors are logged within the protocol of Xima® Formcycle  during processing, it can happen that e.g. error messages from connected third-party systems are captured. Since Xima® 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.

Configuration of automated deletion of protocol entries: Xima® Formcycle Help