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
There are 4 endpoints available on Simplicité® platform:
- the UI endpoint
- the API endpoint
- the I/O endpoint
- the Git endpoint
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.
Note: When possible, using an external authentication mechanism is always a better and more secure approach than using loally stored passwords.
In particular the designer
user's password must be hard to guess (this is also applicable to any user granted with advanced rights).
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, theio.password
JVM argument or theIO_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 {#privatesysparams)
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).
Securing your infrastructure
Introduction
Simplicité® platform run on a server infrastructure. You must secure it properly by:
- configuring firewalls accordingly to your configuration (the rules may be different whether you deploy Simplicité® behind a reverse proxy server or directly)
- restricting access to the command line (VPN, SSH keys, ...) and system accouts
- protecting database credentials Etc.
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
- Your server infrastructure must be kept up-to-date by applying all system updates on the fly. Many security vulnerabilities are at OS-level.
- The JVM, database server, JDBC driver and Java application server must be kept up-to-date.
- The Simplicité® updates must be applied as soon as they are made available
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).