Here is a list of best practices that are considered useful to enforce a good security level for the EBX® setup. These best practices apply to EBX® and to other environments, their configuration, protocols and policies. These are best practices in general, and may not be relevant to your particular infrastructure and security policy.
Web Server or Application Server may specify encryption algorithms when setting HTTPS parameters. Some recommendations on these algorithms are provided in section HTTPS. Password and fields having osd:password as a type are storing hash of their value with SHA_512 as algorithm. That includes the password of users of the default directory.
Using HTTPS for communication with clients (GUI and REST or SOAP) is recommended. All HTTP traffic should be redirected to HTTPS.
A secure cipher suite and protocols should be used whenever possible. This applies, for example, to Web Servers, Application Servers, and jdbc connections.
TLS v1.2 should be the main protocol because it's the only version that offers modern authenticated encryption (also known as AEAD).
Several obsolete cryptographic primitives must be avoided:
Anonymous Diffie-Hellman (ADH) suites do not provide authentication,
NULL cipher suites provide no encryption,
Export cipher suites are insecure when negotiated in a connection, but they can also be used against a server that prefers stronger suites (the FREAK attack),
Suites with weak ciphers (typically of 40 and 56 bits) use encryption that can easily be broken,
RC4 is insecure,
3DES is slow and weak,
On the other hand, getting too restrictive on allowed cyphers may prevent some clients to connect as they may not be able to negotiate the HTTPS connection.
The following configuration is compatible with browsers supported by EBX®.
Cipher suites: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
Versions: TLSv1.2
Deployed components as Web Server and Application Server should be installed using a non-root or unprivileged user, and following the principle of least privilege whenever possible. For example, only necessary ports and protocols should be opened.
If you have to expose web applications on the Internet, it's a good practice to protect them with a Web Server in a demilitarized zone while EBX® and the database server may be in a production zone. Here are some best practices for the configuration.
The secure cipher suite and protocols should be set according to the above section HTTPS.
It is also a best practice not to use the default configuration, and to remove any banner that may also expose the version and type of web server.
For example, on Apache2, to remove the banner (default page returned at the root), just remove the folder /var/www/html.
Also, on Apache2, to remove headers identifying the Web Server, the value of ServerTokens and ServerSignature from the file security.conf should have the following values:
# ServerTokens # This directive configures what you return as the Server HTTP response # Header. The default is 'Full' which sends information about the OS-Type # and compiled in modules. # Set to one of: Full | OS | Minimal | Minor | Major | Prod # where Full conveys the most information, and Prod the least. ServerTokens Prod # Optionally add a line containing the server version and virtual host # name to server-generated pages (internal error documents, FTP directory # listings, mod_status and mod_info output etc., but not CGI generated # documents or custom error documents). # Set to "EMail" to also include a mailto: link to the ServerAdmin. # Set to one of: On | Off | EMail ServerSignature Off
The Web Server is the recommended way for setting restrictions with HTTP security headers. Be aware that headers related to the origin will impact authorized URLs for all resources returned by EBX®. That includes the content of fields of the URL type (example: image of avatar).
Here is a list of security headers and how to set them for EBX®. First, EBX® should be configured to not set any HTTP security headers. To do so, the property ebx.security.headers.activated must be set to 'false'.
X-XSS-Protection
The x-xss-protection header is designed to enable the cross-site scripting (XSS) filter built into modern web browsers. Here is what the header should look like.
x-xss-protection: 1; mode=block
For version 5.9.4, if the property ebx.security.headers.activated is not set or set to true, the security header must also be unset beforehand. For version 5.9.4, if the property ebx.security.headers.activated is set to false, the security header does not need to be unset, so ignore the first line in following snippets. For previous versions, the security header must be unset beforehand.
Enable in Nginx
header always unset x-xss-protection header always set x-xss-protection "1; mode=block"
Enable in Apache2
proxy_hide_header x-xss-protection; add_header x-xss-protection "1; mode=block" always;
x-Frame-Options
The x-frame-options header provides clickjacking protection by not allowing iframes to load on the site. Be aware, this may not be compatible with your configuration if EBX® is integrated through frames for example. Here is what the header should look like:
x-frame-options: SAMEORIGIN
Enable in Nginx
add_header x-frame-options "SAMEORIGIN" always;
Enable in Apache2
header always sets x-frame-options "SAMEORIGIN"
X-Content-Type-Options
The x-content-type-options header prevents Internet Explorer and Google Chrome from sniffing a response away from the declared content-type. This helps reduce the danger of drive-by downloads and helps treat the content properly. Here is what the header looks like.
x-content-type-options: nosniff
Enable in Nginx
add_header X-Content-Type-Options "nosniff" always;
Enable in Apache2
header always sets X-Content-Type-Options "nosniff"
Strict-Transport-Security
The strict-transport-security header is a security enhancement that restricts web browsers to access web servers solely over HTTPS. This ensures the connection cannot be established through an insecure HTTP connection which could be vulnerable to attacks. Here is what the header should look like:
strict-transport-security: max-age=31536000; includeSubDomains
Enable in Nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Enable in Apache2
header always sets Strict-Transport-Security "max-age=31536000; includeSubDomains"
Content-Security-Policy
The content-security-policy HTTP header provides an additional layer of security. This policy helps prevent attacks such as Cross Site Scripting (XSS) and other code injection attacks by defining content sources which are approved and thus allowing the browser to load them. Here is what the header shuould look like. Make sure to adapt it with your domain name (server.company.com in the example).
content-security-policy: default-src 'self'; font-src * data: server.company.com; img-src * data: server.company.com; script-src * 'unsafe-inline' 'unsafe-eval'; style-src * 'unsafe-inline';
Enable in Nginx
add_header Content-Security-Policy "default-src 'self'; font-src * data: server.company.com; img-src * data: server.company.com; script-src * 'unsafe-inline' 'unsafe-eval'; style-src * 'unsafe-inline';" always;
Enable in Apache2
header always sets Content-Security-Policy "default-src 'self'; font-src * data: server.company.com; img-src * data: server.company.com; script-src * 'unsafe-inline' 'unsafe-eval'; style-src * 'unsafe-inline';"
Referrer-Policy
The Referrer-Policy HTTP header governs which referrer information should be included with requests made. The Referrer-Policy tells the web browser how to handle referrer information that is sent when a user clicks on a link that leads to another page. Here is what it should look like:
Referrer-Policy: strict-origin
Enable in Nginx
add_header Referrer-Policy: "strict-origin" always;
Enable in Apache2
header always sets Referrer-Policy "strict-origin"
As for Web Servers, the same best practice applies: do not expose technical information on the Application Server. For example, for Tomcat, it is recommended to fill the attribute server of connector in server.xml with a generic value as AppServer.
<Connector port="8080" enableLookups="false" protocol="HTTP/1.1" useBodyEncodingForURI="true" server="AppServer"/>
If the Application Server is exposed through HTTPS, the secure cipher suite and Protocols should be set according to the above section HTTPS.
If there is a Web Server, it is also recommended to use ports higher than 1024 and let the Web Server do proxy.
If there is no Web Server, security headers should be set by the Application Server as described above.
It is recommended to follow the security best practices from Oracle. Last supported patches should also be applied as soon as they are available especially when they include security patches. Consider using the Server JRE for server systems, such as application servers or other long-running back-end processes. The Server JRE is the same as the regular JRE except that it does not contain the web-browser plugins.
Databases should be encrypted at rest and in transit. If there is a private key for encryption, it should not be stored in the same location as the data files. Regarding the JDBC connection, consider configuring the JDBC driver to use SSL/TLS. Contact your database administrator for detailed instructions. You should always use the last supported version or RDBMS including drivers.
For production and test platforms, EBX® must be integrated with a custom directory to enforce the password policy of your company. The default directory can be used only for development platforms.
According to the Separation of Duties best practice, administrators can manage users and grant access but should not have any functional rights.