Security guidelines

This document give some guidelines on how to improve security of your applications based on the Simplicité® platform.

Platform upgrades

The platform regularly receive upgrades that potentially include security related fixes. The details of the fixes/changes are available in the release notes.

To ensure security it is thus mandatory to keep your deployed instances up-to-date.

Securing application endpoints

Introduction

The Simplicité® platform is designed to be secure, nothing is available without being explicitly granted. However a particular attention must be put on the following aspects.

There are 4 endpoints available on Simplicité® platform:

All of them are secured either by the standard authentication mechanisms (Java server's auth modules, OAuth2/OpenIDConnect or SAML flows) you have configured except the public features that you choose to expose on the UI endpoint's public components (see below)

Locally stored password must be encrypted/hashed (see the HASH_PASSWORD system parameter) accordingly to your local authentication configuration. And a second authentication factor should be enabled: standard TOTP via email, SMS or authentication applications is available as of version 5.2.

Note: When possible, using an external authentication mechanism is always a better and more secure approach than using loally stored password even with a second authetication factor.

In particular the designer user's password must be hard to guess (this is also applicable to any user granted with advanced rights). Alternatively the designer user can be deactivated (but this may complexify delivery processes).

UI endpoint

The UI endpoint has some public (non authenticated) components that may be used for the purpose of explicitly exposing some features publicly.

A particular attention must be put on what is granted to the public user (through its default PUBLIC group or any other group that you grant him)

API endpoint

If you don't use the API endpoint you should disable it by setting the private system parameter USE_API to no.

If you only use it from a limited set of origins you should filter the access to this endpoint (e.g. by using the "whitelist" Docker configuration or by a reverse proxy-level filtering)

At least you should disable the API tester page by setting the private system parameter USE_API_TESTER to no.

For more information on default API authentication mechanisms, see this document.

I/O endpoint

You must secure access to the I/O endoint.

The I/O endpoint is dedicated for batch import/exports, including business modules installations/upgrades and system upgrades and thus should only be accessed from legitimate origins for these kind of processes.

When you don't use the I/O endpoint you may disable it by setting the private system parameter USE_IO to no. This change must be reversible because you may need this endpoint for "rescue" system patching.

If you only use it from a limited set of origins you should filter the access to this endpoint (e.g. by using the "whitelist" Docker configuration or by a reverse proxy-level filtering)

For more information defaut on I/O authentication mechanisms, see this document.

Note: for backward compatibility reasons (and for particular cases) the I/O and Git endpoints also use the legacy authentication method bases on private system parameters names EAI * or, as of version 5, the io.password JVM argument or the IO_PASSWORD environment variable. If you have no good reason to keep it all the time, this authentication method should be inhibited (at least when you don't need it) by removing the corresponding system parameters, JVM argument or environment variable. Note that, as of minor version 5.1, it is not be possible to use the user's password if it is requested to be changed.

Git endpoint

If you use the Git endpoint you must secure its access.

This Git endpoint is only supposed to be used for business modules installation/upgrades and thus should only be accessed from legitimate origins for these kind of processes.

It is a variant of the corresponding module import/export features available on the I/O endpoint.

If you don't use the Git endpoint you should disable it by setting the private system parameter USE_GIT to no.

If you only use it from a limited set of origins you should filter the access to this endpoint (e.g. by using the "whitelist" Docker configuration or by a reverse proxy-level filtering)

Health-check

The /health page/service allow you to get health-check technical information on a running instance.

You should secure the access to this URI by restricting access to the only IP in charge of techincal monitoring.

You can also disable this page/service by setting the USE_HEALTH system parameter to no. This is relevant to disable it completely if, for instance, you use the JMX services of the platform (or a third party monitoring toolset) for the platform monitoring.

If you only use it from a limited set of origins you should filter the access to this endpoint (e.g. by using the "whitelist" Docker configuration or by a reverse proxy-level filtering)

Maven repository

The instance exposes a Maven repository of the 3rd party Java components on the /maven URI. This is only relevant in development.

You should secure the access to this URI in production.

You can also disable this page/service by setting the USE_MAVEN system parameter to no. This is relevant on production instance on which this development-oriented feature is useless.

If you only use it from a limited set of origins you should filter the access to this endpoint (e.g. by using the "whitelist" Docker configuration or by a reverse proxy-level filtering)

Note: this 3rd party components list is anyway public on the document website.

Securing your application's configuration and custom code

Public rights

Be careful on what you grant to the public user (typicaly through the PUBLIC group or by additional resposnsibilities associated to this user) because everything granted to this user is made available on the public UI components

Private system parameters

Be sure to configure as Private type all system parameters that holds confidential data that you don't want to be available elsewhere than on the server side (e.g. services credentials, passwords, ...)

Business object filtering

If you have a business object with dynamic filtering rules (e.g. implemented in the postLoad hook based on rules on user's responsibilities and/or business obejct instance name), you should set 1=2 as default static filtering rule. As a metter of fact, if for any reason you code is not working well it will result in giving no access to any data instead of giving access to all data.

Forbidden fields

A invisible business object field is still visible if you inspect the HTML of the UI and is still available on the API calls. To be sure a field is only usable on the server side you must mark it Forbidden.

As above for filtering, if a field's visibility is dynamically set by code, be sure to configure it as Forbidden in your static configuration. If for any reason your code does not work the field will remain by default not avialable.

Cross site scripting vulnerabilities {#xss)

If you implement a custom page (e.g. via an external object), make sure to take into account the risk of cross site scripting vulnerabilities (passing <script> or <svg> with script in a HTTP parameter). Basic protection is to systematically display values got from HTTP parameters using Tool.toHTML/toJS.

The platform code implements such XSS prevention on all pages.

SQL injection vulnerabilities

If you write custom SQL statements make sure to take into account the risk of SQL injection vulnerabilities. Basic protection is to systematically use host variables or, at least, protect the values inserted in your SQL statements using Tool.toSQL.

The platform code implements such SQL injection prevention for all SQL statements.

CRCF protection

If you implement a custom page with a form, make ur to implement a CRCF protection mechanism.

The platform code implements such CRCF protection in all page with forms.

Low level tools

System users (such as designer) have access by default to low level tools on the generic UI (database and document database browsers). These tools are standard external objects they should be inhibited by removing grants on them if you don't use them.

Data encryption

Use built-in (see the Data Encryption part in code examples) or third party data encryption especially when the database access is not limited to the application.

Internal authentication

If you use the internal authentication you should consider securing it by adding a second authentication factor (2FA/MFA) and/or by implementing custom rules (e.g.: disabling a login after a certain amount of erroneous password entry or enforcing appropriate password validation rules). See this document for details.

You should also use the appropriate password hashing algorithm by setting the HASH_PASSWORD system parameter (note that changing this algorithm will require that all your users change their password).

Custom HTTP headers

Although it should rather be done at the reverse proxy level (or at Tomcat level), it is possible to add custom HTTP headers to all responses by setting the HTTP_HEADER systme parameter. E.g. typical usage is to set custom Content-Security-Policy, X-Frame-Options, X-XSS-Protection, ... HTTP headers.

Securing your infrastructure

Introduction

Simplicité® platform run on a server infrastructure. You must secure it properly by:

Simplicité® has no particular requirement at this level, all usual good practices in securing server infrastructure applies.

Use SSL

Your application endpoints should always be exposed as HTTPS (SSL). This can be achieved directy in the Java application server that runs Simplicité® or at the reverse proxy level (if you have configured one).

SSH Access

The server infrastucture command line access should always use SSH (ideally key-based) authentication (and the keys should be secured by a robust passphrase).

System updates

Note the warranty is void on a non up-to-date platform, keeping your Simplicité® platform up-to-date is not just recommended it is mandatory.

Securing Docker-based deployments

If you deploy the platform using Docker images you can strengthen the security of the deployed container(s) by applying an hardened deployment configuration

In this example all useless capabilities of the container are disabled, it runs in read only mode and all working directories are mounted as temporary filesystems volumes. You need to adjust this example to your particular case (e.g. by using persistent volumes instead of temporary volumes where needed, etc.)

Our standard Docker images are rebuilt regularly with an up-to-date system base OS, an up-to-date JVM, an up-to-date Tomcat server and the latest platform revision. You must update the deployed containers using the latest Docker images on a regular basis.

And of course, you must also apply the system upgrades on your host machine on similar a regular basis.

Securing the Simplicité® Instance Manager (SIM)

These are specific guidelines for the Simplicité Instances Manager (SIM). See this document for details on the SIM.

SIM credentials

You must use strong password for your SIM users passwords (for UI and API access). Better, use SSL client certificates for authentication. When connecting over SSH, use only secured SSH keys.

Web-based terminal access

Don't enable the web-based terminal access (ShellInABox) unless you absolutely need it (keep in mind it is a rather insecure feature that only makes sense on a non-production, highly secured infrastructure).