Security Hardening Guide - Deployment

This page provides a security guide for deploying Caplin products in a production environment. It outlines the recommended practices for hardening security across the entire Caplin product and solutions stack, including Caplin Platform and Caplin FX Professional

The provided information is intended for use by Architects, System Administrators, and Developers who wish to harden the security of Caplin products when deploying into production (live) environments.

For the recommended security practices when developing with Caplin products, see Security Hardening Guide - Developing.

Caplin Platform

Recommended security practices to consider when configuring the Caplin Platform for production environments:

Review open services on production servers

Limit access to the server to the minimum possible set of services and users.

Disable the LiberatorWebsite blade in production

The LiberatorWebsite blade enables Liberator’s HTTP interface and serves a status page and diagnostic tools suitable for debugging and development. This built-in website is not supported for use in production environments. For production environments, use the MinimalLiberatorWebsite blade, which enables Liberator’s HTTP interface but serves only a basic index page: "This is Liberator".

In production environments, deactivate the LiberatorWebsite blade and activate the MinimalLiberatorWebsite blade:

./dfw deactivate LiberatorWebsite
./dfw activate MinimalLiberatorWebsite

Caplin FX Professional

Front-end configuration

Recommended security practices for configuring FX Professional components on the client side.

Disable password autocomplete on login pages

Consider disabling autocomplete on the password fields:

  • HTML5 supports autocomplete='off' - however older browsers do not obey this protocol. Other solutions include randomising the fieldNames on the page.

  • See this Mozilla developer page for details

Disabling autocomplete can have unintended consequences. Removing the option to store passwords in the browser may cause some users to choose passwords that are easier to memorise (and so weaker).

Detect unsupported browsers

Caplin Trader and the Caplin FX Professional support Microsoft Internet Explorer 11, Google Chrome and Mozilla Firefox. In production, restricting access for unsupported browsers and/or displaying a disclaimer during login is something you should consider.

Browser detection can be useful because:

  • You can display a warning dialogue to users on untested browsers (e.g. Safari) to indicate that the application is not tested against current browser

  • You could redirect the user somewhere or prevent access, if you detect that they are using a significantly old version of Internet Explorer

    • This can also prevent users from seeing the application load with errors or bad-styling

    • Can potentially save support time and cost when investigating issues seen by users who are using browser versions you do not wish to support

Alternatives to browser detection:

  • Feature detection: instead of checking for specific browser versions, check to see if the features that your app requires are there (e.g. websockets)

  • Graceful degradation: a top-down approach where you build your app with all the features you want and tweak it to make it work with older browsers. Note that, potentially toning down performance overheads are not handled particularly well by older browsers.

See: Mozilla Developer Network: Browser detection using the user agent.

Server-side configuration

Recommended security practices for configuring FX Professional on the server side.

Don’t output stack traces in production

If not handled correctly, this could result in information disclosure if/when full stack traces are displayed. Use the application’s WEB-INF/web.xml configuration file to trap unhandled exceptions and display a default error page to end users.

Caplin Trader provides the feature to have conditional web.xml for development (via bladerunner start) and production (when the WAR is created). An <error-page> config is included by default in the FX Motif 1.7.1 release - FX Motif is a previous name for FX Professional.

The following web.xml snippet has the comment tags removed prior to building a WAR:

<!-- start-env: prod
<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/default-aspect/unbundled-resources/images/blank.gif</location>
</error-page>
end-env -->

Prevent 'clickjacking' attacks

To protect the application from clickjacking attacks, configure your application’s web server to add the following two HTTP headers to content:

  • Content-Security-Policy: frame-ancestors 'self'

  • X-Frame-Options: SAMEORIGIN

Content-Security-Policy is supported by modern browsers. X-Frame-Options is included for compatibility with older browsers.

For more information on the Content-Security-Policy header, see OWASP: Content Security Policy Cheatsheet.

For more information on the X-Frame-Options header, see OWASP: Clickjacking Defence Cheat Sheet.

Use HTTP Strict Transport Security

It is advisable to have a redirect from http://yoururl.com to https://yoururl.com

From CaplinTrader-3.11.0, an additional JAR 'caplin-redirect-filter-<version>.jar' is included which enables a HSTS header that redirects to https.

To enable this for your war, your web.xml would look something like this:

<!-- start-env: prod
<filter>
    <filter-name>bladerunner-prod-filters</filter-name>
    <filter-class>com.caplin.cutlass.filter.BladerunnerProdFilters
    </filter-class>
</filter>Than
<filter-mapping>
    <filter-name>bladerunner-prod-filters</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>FORWARD</dispatcher>
</filter-mapping>
<filter>
    <filter-name>HTTPS</filter-name>
    <filter-class>com.caplin.trader.filter.HttpsRedirect</filter-class>
</filter>
    <filter-mapping>
    <filter-name>HTTPS</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
end-env -->

Be wary of sensitive data in cachable data

It’s possible for sensitive data to be extracted by inspecting the browser cache of a machine that has previously logged in to the FX Professional web application. Our recommendation is to ensure that any custom implementation of FX Professional does not cache sensitive data.

This can be done by adding "Cache-Control: no-store" and "Pragma: no-cache" headers to all responses which contain sensitive data.

Since version 1.7.1, out-the-box FX Professional does not expose sensitive data in HTTPS responses.

Use JNDI tokens for environment specific configuration

Avoid introducing programmatic concepts of 'modes' into your code, as this often leads to bugs that are only seen in production environments.

The FX Motif (now known as FX Professional) already makes use of JNDI environment token values for the following:

  • Primary Liberator URL

  • Primary Liberator Port

  • Secondary Liberator URL

  • Secondary Liberator Port

  • Webcentric JDBC URL

  • KeyMaster privatekey location

  • Enable URL parameters to point client to a server URL (in Caplin Dev Mode)

When running in BladeRunner, these are defined inside WEB-INF/jetty-env.xml

Each web application server will have its own config mechanism to declare key/value pairs for these tokens.

Example - Tomcat (Application Server) JNDI token config snippet:

<Environment name="LIBERATOR.PRIMARY.ADDRESS" value="machine.domain.com" type="java.lang.String" override="false" />
<Environment name="LIBERATOR.PRIMARY.PORT" value="50180" type="java.lang.String" override="false" />
<Environment name="CAPLIN.DEV.MODE" value="false" type="java.lang.String" override="false" />

See also: