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.
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
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.
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
fieldNameson the page.
- See this Mozilla developer page for details
Detect unsupported browsers
Caplin Trader and the Caplin FX Professional support Microsoft Internet Explorer 11, Microsoft Edge, 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.
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" />