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. While these practices are commonly regarded as beneficial, they may not be relevant to your particular infrastructure and security policy.
The 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 store a hash of their value, using the SHA_512 algorithm. This is, notably, the case for the password of users of the default directory.
It is recommended to use HTTPS for communication with clients (GUI and REST or SOAP). 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 is 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, being too restrictive on allowed cyphers may prevent some clients from connecting, as they may not be able to negotiate a 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, such as 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 is a good practice to protect them with a Web Server in a demilitarized zone, while EBX® and the database server can be in a production zone. Consider the following practices for your configuration.
The secure cipher suite and protocols should be set according to the above section HTTPS.
Do not use the default configuration, and remove any banner that might 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
Use the Web Server to set restrictions with HTTP security headers. Note that headers related to the origin 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, configure EBX® to not set any HTTP security headers. To do so, set the property ebx.security.headers.activated to false or unset.
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
Enable in Nginx
proxy_hide_header x-xss-protection; add_header x-xss-protection "1; mode=block" always;
Enable in Apache2
header always unset x-xss-protection header always set x-xss-protection "1; mode=block"
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 set 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 set 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 set 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 set 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 set Referrer-Policy "strict-origin"
Permissions-Policy
The Permissions-Policy HTTP header provides mechanisms for web developers to explicitly declare what functionality can and cannot be used in iframes. A set of "policies" that restrict what APIs the site's code can access or modify is defined and overwrites the browser's default behavior for certain features. Here is what it should look like:
Permission-Policy: "*=()"
Enable in Nginx
add_header Permissions-Policy: "*=()" always;
Enable in Apache2
Header always set Permissions-Policy "*=()"
Please note that this value may change depending on your needs. If your EBX® installation has customized frontend code that uses any relevant Api you may need to adapt it.
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"
allowBackslash="true" encodedSolidusHandling="passthrough" 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.
EBX® allows a very high level of customization through custom code. All integrated Java modules are considered by EBX® as trusted. Hence, all development on top of EBX® should be reviewed and validated. As an example, developers should not generate HTML from values coming from the database without proper escaping. For more details on this, see the Cross Site Scripting prevention on the OWASP site. Here is a proper escaping example: the name of a store is encoded before being displayed in an HTML form. The StringEscapeUtils class included in Apache Commons Lang is used for string encoding.
public class StoreMainPane implements UIFormPane
{
public static final String STORE_NAME_STYLE = "font-weight: bold; padding-top:20px; padding-bottom:20px";
@Override
public void writePane(final UIFormPaneWriter writer, final UIFormContext context)
{
String storeName = (String) context.getValueContext().getValue(Paths._Store._Name);
writer.add("<div ").addSafeAttribute("style", STORE_NAME_STYLE).add(">");
writer.addSafeInnerHTML("Data stored for " + storeName);
writer.add("</div>");
// ...
}
}
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.
On the server, the archive directory must be properly secured and/or encrypted. Indeed, any archive exported from the EBX® instance will be created there, and these archives are neither encrypted nor protected by password. As a consequence, any user with an access to these files will be able to see the content regardless of any permission defined in EBX®.
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.
Special care is required when defining permissions in EBX®. Persons in charge of this are expected to be aware of the content of the permission documentation, and especially the information provided in the Important considerations about permissions section.