com.atlassian.confluence.content.render.xhtml.migration.exceptions.UnknownMacroMigrationException: The macro 'next_previous_link3' is unknown.

Securing Jaggery Applications

This section explains how to minimize the security threats to the Jaggery applications that are hosted within your WSO2 DAS pack. This is achieved via headers that can be embedded in the HTTP responses of these applications.

Available headers

The following is a list of headers that need to be enabled to enhance the security aspects of Jaggery Applications.

HeaderPurpose
X-XSS-Protection: 1; mode=blockThis enables reflected XSS protection in supported web browsers.
X-Content-Type-Options: nosniffThis disables mime sniffing that can result in reflected or stored XSS in certain browsers.
Cache-Control: no-store, no-cache, must-revalidate, privateThis prevents sensitive information from being cached in web browsers, proxies and other intermediate network devices.

In addition, the following are headers that need to be enabled based on the requirement of the application. These headers can be customized based on the URL pattern.

HeaderPurpose
X-Frame-Options: DENYThis disables embedding Jaggery apps in iframes or frames.
X-Frame-Options: SAMEORIGINThis allows you to embed Jaggery apps in iframes or frames within the same origin.

The X-Frame-Options header mitigates the clickjacking attacks. Out-of-the-box Jaggery applications need to use the SAMEORIGIN option. The DENY option should not be used because some out-of-the-box dashboards may use framing. If an application that resides outside the origin needs to frame a Jaggery app, then the X-Frame-Options header must  not be returned at all. This must be configured as per application requirement, taking the security risk into consideration.

The following is an optional header to be enabled for the production and staging environments for additional security.

HeaderPurpose
Strict-Transport-Security: max-age=15768000; includeSubDomains

This header prevents any communication over HTTP from taking place for the number of milliseconds specified via the max-age parameter, starting from the time the latest response with the aforementioned header was received.

Enabling this header in a development environment where URLs and certificates may change can result in causing inconvenience. This is because, when some browsers do not forget the preference of that domain until the time specified via the max-age parameter has elapsed, even when the browser cache is cleared. Therefore, it is recommended to enable these headers in only production and staging environments.


Enabling a header

To apply the basic security headers required to secure Jaggery applications, update the <DAS_HOME>/repository/deployment/server/jaggeryapps/<app-name>/jaggery.conf file as shown in the steps below. These steps demonstrate an example scenario where the HttpHeaderSecurityFilter and ContentTypeBasedCachePreventionFilter headers are enabled for both developer and production environments.

For development environments:

  1. Add the two filters named HttpHeaderSecurityFilter and ContentTypeBasedCachePreventionFilter in the "filters": [] section as shown below. 

    "filters":[
      {
        "name":"HttpHeaderSecurityFilter",
        "class":"org.apache.catalina.filters.HttpHeaderSecurityFilter",
        "params" : [
            {"name" : "hstsEnabled", "value" : "false"},
                        { "name": "antiClickJackingOption", "value": "SAMEORIGIN" }
     	     ]
      },
      {
        "name": "ContentTypeBasedCachePreventionFilter",
        "class": "org.wso2.carbon.ui.filters.cache.ContentTypeBasedCachePreventionFilter",
        "params":[
          {"name": "patterns", "value": "text/html\" ,application/json\" ,plain/text"},
          {"name": "filterAction", "value": "enforce"},
          {"name": "httpHeaders", "value": "Cache-Control: no-store, no-cache, must-revalidate, private"}
        ]
      }
    ],
  2. Add the filter mappings for the two filters you added. These two filter mapping configurations need to be added in the "filterMappings":[] as shown below.

    "filterMappings":[
      {
        "name":"HttpHeaderSecurityFilter", 
        "url":"*"
      },
      {
        "name": "ContentTypeBasedCachePreventionFilter",
        "url": "*"
      }
    ]
  3. Save your changes.

For production environments:

  1. Add the two filters named HttpHeaderSecurityFilter and ContentTypeBasedCachePreventionFilter in the "filters": [] section as shown below. 

    "filters": [
        {
            "name": "HttpHeaderSecurityFilter",
            "class": "org.apache.catalina.filters.HttpHeaderSecurityFilter",
            "params": [
    	  {"name": "hstsMaxAgeSeconds",  "value": "15768000"},
                  { "name": "antiClickJackingOption", "value": "SAMEORIGIN" }
            ]
         },
         {
            "name": "ContentTypeBasedCachePreventionFilter",
            "class": "org.wso2.carbon.ui.filters.cache.ContentTypeBasedCachePreventionFilter",
            "params":  [
    	{ "name": "patterns", "value": "text/html\" ,application/json\" ,plain/text" },
    	{ "name": "filterAction", "value": "enforce"},
    	{ "name": "httpHeaders", "value": "Cache-Control: no-store, no-cache, must-revalidate, private" }
            ]
        }
    ],
  2. Add the filter mappings for the two filters you added. These two filter mapping configurations need to be added in the "filterMappings":[] as shown below.

    "filterMappings": [
        { "name": "HttpHeaderSecurityFilter", "url": "*" },
        { "name": "ContentTypeBasedCachePreventionFilter", "url": "*"}
    ]
  3. Save your changes.

Catering to customizations of Jaggery applications

As mentioned before, some headers can be customized based on the URL pattern.

e.g., To enable X-Frame-Options only for particular page in a Jaggery application, configuration can be done as follows:

  1. Open the <DAS_HOME>/repository/deployment/server/jaggeryapps/<app-name>/jaggery.conf file and add a filter as shown below.

    "filters":[
      {
    	"name":"HttpHeaderSecurityFilter",
    	"class":"org.apache.catalina.filters.HttpHeaderSecurityFilter",
    	"params" : [{"name" : "antiClickJackingEnabled", "value" : "false"}]
      },
      {
    	"name":"HttpHeaderSecurityFilter_AntiClickJacking",
    	"class":"org.apache.catalina.filters.HttpHeaderSecurityFilter",
    	"params" : [
      	{"name" : "hstsEnabled", "value" : "false"},
      	{"name" : "blockContentTypeSniffingEnabled", "value" : "false"},
      	{"name" : "xssProtectionEnabled", "value" : "false"}
    	]
      }
    ],
  2. Add a filter mapping as shown below.

    "filterMappings":[
      {
    	"name":"HttpHeaderSecurityFilter",
    	"url":"*"
      },
      {
    	"name":"HttpHeaderSecurityFilter_AntiClickJacking",
    	"url":"/portal/dashboards/mydashboard"
      }
    ]

    In the above configuration, the X-Frame-Options header is sent only for the /portal/dashboards/mydashboard page assuming that mydashboard is available in the application. Disabling other headers (i.e., other than X-Frame-Options) is not required, but doing so enhances performance. 

  3. Save the changes.

For more information about enabling these headers via filters, see Apache Tomcat Documentation.

com.atlassian.confluence.content.render.xhtml.migration.exceptions.UnknownMacroMigrationException: The macro 'next_previous_links2' is unknown.