Cloud Software Group, Inc. EBX®
Documentation > Security Guide
Navigation mode Documentation > Security Guide

# Security Best Practices

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.

## Encryption algorithms

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.

## HTTPS

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

## Installation

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.

## Web Server

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.

## Application Server

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.

## Java

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>");

    		// ...
    	}
    }

## Database

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.

## Archive directory

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®.

## User directory and Administration rights

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.

## Permissions

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.

Documentation > Security Guide