Security Hardening Guide - Deployment

This page provides a security guide for deploying Caplin products in a production environment and 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 product(s) when deploying into production (live) environments. See further down for a list of current Caplin products and the associated security hardening procedures for each product.

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

General hardening procedures for deployment

Recommended security hardening procedures to consider for your production environment:

Details Recommended practice

Disable the 'LiberatorWebsite' (admin pages) Platform blade in production

This web site is only intended to be used for debugging. If you need to monitor active server-side components in your deployed system, consider using the Caplin Management Console or the JMX extensions of all Caplin Platform components. For further information - please contact Caplin Support.

To disable the LiberatorWebsite Platform blade, use the deactivate command of the Deployment Framework command utility (dfw). You can enable the MinimalLiberatorWebsite blade instead; this provides a minimal status page and associated configuration for Liberator that is suitable for secure product deployment. To enable this blade use the dfw activate command. Also see Deployment Framework Built-in blades.

Caplin Platform

Caplin Platform configuration

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

Details Recommended practice

Review potentially dangerous services open on production box

Wherever possible, you will need to prevent access to any dangerous services by default 'out of the box' via the usage of 'iptables' rules. Limit access to the server to the minimum possible set of services and users.

Caplin FX Professional

You may find references below to 'FX Motif' - note that this is a previously used name for FX Professional.

Client configuration

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

Details Recommended practice

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 may have negative security consequences (drawbacks) such as encouraging users to use weaker passwords, or reusing passwords

Protecting application from 'Clickjacking' vulnerabilities

There are two well-known mechanisms for mitigating clickjacking attacks:

  • Modern web browsers accommodate headers, such asX-Frame-Options, that extend the browser security model to block malicious framing

  • JavaScript code can force pages to load unframed or not at all

From CaplinTrader 3.11.0 onwards, the 'caplin-bladerunner-prod-servlets-<version>.jar' includes X-Frame-Options to protect against this.

Browser detection for unsupported browsers

Caplin Trader and 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:

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

  2. You could redirect the user somewhere/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/bad styling

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

Alternatives:

  • 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

Useful links:

Application server configuration

Details Recommended practice

Avoid stack traces being output to the user’s browser 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 3 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 -->

Use HTTP Strict Transport Security (HSTS)

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 potentially sensitive data in cache-able HTTPS responses

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.

KeyMaster/FX Motif config - Use JNDI tokens for environment specific config

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" />

Related documentation: