This document give some guidelines on how to improve security of your applications based on the Simplicité® platform.
Securing application endpoints
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 realm / JaaS/Jaspic modules, OAuth2/OpenIDConnect or SAML flows) you configure except the public features that you choose to expose on the UI endpoint's public components (see bellow)
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).
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
PUBLC group or any other group that you grant him)
If you don't use the API endpoint you should disable it by setting the private system parameter
For more information on default API authentication mechanisms, see the IO command-line doc.
If you don't use the I/O endpoint you should disable it by setting the private system parameter
For more information defaut on I/O authentication mechanisms, see the IO command-line doc.
If you don't use the Git endpoint you should disable it by setting the private system parameter
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 *. If you have no good reason to keep it, this authentication method should be inhibited by removing the corresponding system parammeters.
Securing your configuration and your specific code
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.
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 vulnearbility
If you write a custom web page (e.g. via an external object) make sure to take into account the risk of cross site scripting vulnerabilities (passing
<svg> with script
in a HTTP parameter). Basic protection is to systematically display values got from HTTP parameter using
Low level tools
System users (such as
designer) have access by default to low level tools on the generic UI (database and dbdoc browsers). These tools are standard external objects
they should be inhibited by removing grants on them if you don't use them.
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.
Securing your infrastructure
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.
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).
The server infrastucture command line access should always use SSH (ideally key-based) authentication (and the keys should be secured by a robust passphrase).
- 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 JDK, 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.
Simplicité® Instance Manager (SIM)
These are specific guidelines for the Simplicité Instances Manager (SIM). See this document for details on the SIM.
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.
Don't enable the web-based terminal access (ShellInABox) unless you do need it (keeping in mind it is a rather insecure feature).