You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.

Runtime

Encrypting connection passwords

Connection passwords will be encrypted when configured by the development dashboard.

The development dashboard provides an interface to configure a Blueriq Studio connection to retrieve projects and SOAP or REST connections which use authentication.

In R10+, Blueriq provides a password encryptor which can be used without the development dashboard Property Encryptor.

Authentication

Out-of-the-box, Blueriq comes with an in-memory authentication provider. This default implementation should be used for development purposes as they store the credentials in plain text on the file system. To configure an authentication provider for production purposes, please read Runtime Authentication and HTTP Security in Runtime.

Blueriq session & cookie

Blueriq Runtime and Publisher are using the HTTP session to store data before it is persisted. As stated by OWASP, the session timeout should be set as low as possible (https://owasp.org/www-community/Session_Timeout). Depending on your infrastructure it is possible to set the Secure flag of the session cookie (https://owasp.org/www-community/controls/SecureCookieAttribute). Both the session timeout and the secure flag can be configured by following the steps in the articles below:

By default the secure flag of the session cookie is enabled since release 16.0 and onwards. In earlier versions, the property was disabled by default.

Disabling the secure session cookie from Blueriq version 14.7 onwards can be done by configuring the following property:

application.properties
blueriq.session.cookie.secure=false


When the secure flag is set on the session cookie, the cookie will only be sent to the server over a secured connection (HTTPS).

If your runtime runs in HTTP mode, despite the cookie having the secure flag, you will get errors about Blueriq Sessions not being found or being expired.


Additionally, the SameSite attribute can be set on the session cookie: Security: SameSite.

Runtime protection

Out-of-the-box, Blueriq comes with an in-memory authentication provider. This default implementation should be used for development purposes as they store the credentials in plain text on the file system. To configure an authentication provider for production purposes, please read Runtime Authentication and HTTP Security in Runtime.

Default exposed endpoints

The following list contains all endpoints that are exposed in Blueriq by default.

Note that everything behind /server/** may not be blocked.

Endpoint

Method

/GET
/displayNamesPUT
/endpointsGET
/endpoints/{name}GET
/projectsGET
/projects/{id}GET
/projects/{id}/metadataGET

/shortcuts

GET

/shortcuts/{name}

GET
/caseEventsGET
/caseEvents/{eventId}GET
/caseEvents/{eventId}POST

/cases

GET
/cases/{caseId}GET
/cases/{caseId}/attributesGET
/endpointsGET
/endpoints/{name}GET

/tasks

GET

/tasks/{taskId}

GET

/tasks/{taskId}

PUT
/tasks/{taskId}/customFieldsGET

/api/v1/api-docs

GET
/session/{sessionId}/api/authentication/logoutGET
/session/{sessionId}/api/document/{type}/{documentName}/{pageName}

GET

/session/{sessionId}/api/image/{imageName}GET
/session/{subscriptionId}/api/subscribePOST
/session/{sessionId}/api/subscribe/{subscriptionId}POST
/session/{sessionId}/api/subscription/{subscriptionId}/handleEventPOST
/session/{sessionId}/api/subscription/{subscriptionId}/startFlow/{flowName}POST
/session/{sessionId}/api/utility/keepAliveGET
/session/{sessionId}/api/dmn/{entityName}/{instanceId}/{attributeName}GET
/session/{sessionId}/filedownload/{connectionName}/{fileId}/GET
/session/{sessionId}/api/widget/{infoKey}POST

In case some of them are unnecessary they should be blocked by the firewall.


Shortcuts

In a production environment shortcuts should be used instead of exposed flows. By default, all exposed flows can be started externally. Please read Create a shortcut in the Runtime on how to create a shortcut. Disabling starting all exposed flows can be done by setting the blueriq.production.shortcuts-only to true in application.properties.

Example in application.properties:

blueriq.production.shortcuts-only=true

AQ_StartProject

By default shortcuts can be accessed externally via the url (e.q. http://localhost:91/Runtime/server/start/<SHORTCUT_NAME>). When using shortcuts in combination with AQ_StartProject you should be aware that this shortcut can also be accessed externally. To prevent this from happening, you should set the property privateAccess to true. The reason for this is that via the AQ_StartProject, parameters are passed to the shortcut application and are picked up via the AQ_GetRequestParameters service. The AQ_GetRequestParameters does not distinguish on how parameters are send, by the AQ_StartProject service or the end user threw the URL. For more information about passing parameters via the AQ_StartProject, please read AQ_StartProject#Security.

Example shortcut in application.properties:

blueriq.shortcut.<SHORTCUT_NAME>.flow=<FLOW>
blueriq.shortcut.<SHORTCUT_NAME>.languageCode=<LANGUAGE>
blueriq.shortcut.<SHORTCUT_NAME>.project=<PROJECT>
blueriq.shortcut.<SHORTCUT_NAME>.theme=<THEME>
blueriq.shortcut.<SHORTCUT_NAME>.ui=<MVC>
blueriq.shortcut.<SHORTCUT_NAME>.version=<VERSION>
blueriq.shortcut.<SHORTCUT_NAME>.privateAccess=true

AQ_GetRequestParameters

The AQ_GetRequestParameters service is able to retrieve parameters from the URL. You should treat these parameters as "dirty", which means you should validate these parameters before using them. 


Security properties

Blueriq Runtime has build in security and is enabled by default with application properties.
The security configuration can be customized as needed. For a better understanding of the properties and default configuration, below is a list of all the security properties Blueriq contains.

Block HTTP Methods

If you would like to block certain HTTP request methods in order to minimize security risks, the Blueriq Runtime provides a configuration option to list blocked HTTP requests methods. These methods will be blocked globally. Examples of HTTP request methods that you may want to block include HEAD, OPTIONS or TRACE. By default, no HTTP request methods are blocked. The Blueriq Runtime will respond with status code 405 Method Not Allowed to requests made with a blocked HTTP method.

 

By default nothing is blocked.

The property should be:

blueriq.security.http.restricted-methods=

To block use:

blueriq.security.http.restricted-methods=head,options

HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is a enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.

By default this is enabled since release 16.0 and onwards. For previous releases it was disabled by default.

By default this is enabled.

To disable:

application.properties
blueriq.security.strict-transport-security.enabled=false

To enable again:

application.properties
blueriq.security.strict-transport-security.enabled=true

Frontend Deployment

Security headers generated by the Runtime are only applied to pages that are served from the Runtime itself. In case the Blueriq Frontend is served from a CDN or via Reverse Proxy these headers will need to be configured from the CDN or Reverse Proxy, for the headers to be applied.

Content sniffing protection

Historically browsers, including Internet Explorer, would try to guess the content type of a request using content sniffing. This allowed browsers to improve the user experience by guessing the content type on resources that had not specified the content type. For example, if a browser encountered a JavaScript file that did not have the content type specified, it would be able to guess the content type and then execute it.
The problem with content sniffing is that this allowed malicious users to use polyglots (i.e. a file that is valid as multiple content types) to execute XSS attacks. For example, some sites may allow users to submit a valid postscript document to a website and view it. A malicious user might create a postscript document that is also a valid JavaScript file and execute a XSS attack with it.

By default this is enabled.

The property should be:

blueriq.security.x-content-type-protection.enabled=true

To disable use:

blueriq.security.x-content-type-protection.enabled=false

Frontend Deployment

Security headers generated by the Runtime are only applied to pages that are served from the Runtime itself. In case the Blueriq Frontend is served from a CDN or via Reverse Proxy these headers will need to be configured from the CDN or Reverse Proxy, for the headers to be applied.

Cross-Site request forgery protection (CSRF)

The Runtime uses Cross-Site Request Forgery (CSRF) protection using a variant of Synchronizer Token pattern for POST requests to the /session/ URL pattern. Only Blueriq's own controllers are protected, as customers may use other methods/frameworks for this purpose. Both Spring MVC and ASP.NET MVC have specific methods for CSRF protection. The CSRF mechanism is as follows:

  1. On every full page reload a CSRF token is generated, this token is stored in the session and send to the client inside the json message.
  2. On any subsequent POST requests to a protected URL, the client must send the CSRF token
  3. the CSRF interceptor checks whether the token is sent by the client and whether it matches the token stored in the session and allows access only if there is a match
  4. if the token is not present or does not match, access to the protected URL is denied and the interceptor responds with 403 Invalid CSRF Token.

The Synchronizer pattern has been extended to support multiple blueriq sessions.

Clickjacking protection

Also known as User Interface redress attack, UI Redress attack or UI redressing is a malicious technique of tricking a web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information

Clickjacking protection is implemented as described on the OWASP, by appending the headers:

HeaderValue
X-Frame-OptionsSAMEORIGIN
Content-Security-Policyframe-ancestors 'self'; default-src 'self'; script-src 'self'; style-src 'self'; font-src 'self'; img-src 'self'

For more information about the subject, please consult the official Content Security Policy documentation, available here.


The use of eval, setTimeout with a string argument, setInterval with a string argument and new Function with the function body given as a string should be avoided in the front-end code, as the 'unsafe-eval' directive is in effect. 

If a custom front-end is used which does not use KnockoutJS or other frameworks that make use of the above-mentioned javascript functions, we recommend to remove the 'unsafe-eval' directive from script-src. We also recommend to keep other XSS protection measures enabled, such as the XSS protection header, XSS whitelist and/or XSS blacklist.


When it should be disabled

This option needs to be disabled when the blueriq application is used inside a frame that originates from a website on another domain

The Clickjacking protection is enabled by default.


Setting the following property in application.properties will disable it:

blueriq.security.click-jacking-protection.enabled = false


Configure parameters

Default value for the 'Content-Security-Policy' header in Production mode (without the Development Tools Component) is : 

'frame-ancestors 'self'; default-src 'self'; script-src 'self' 'unsafe-eval';

The values for this header for the Java Runtime can be configured in  application.properties:

blueriq.security.click-jacking-protection.content-security-policy.default-src = 'self'
blueriq.security.click-jacking-protection.content-security-policy.script-src = 'self' 'unsafe-inline' 'unsafe-eval'
blueriq.security.click-jacking-protection.content-security-policy.style-src = 'self' 'unsafe-inline'
blueriq.security.click-jacking-protection.content-security-policy.font-src = 'self' data:
blueriq.security.click-jacking-protection.content-security-policy.img-src = 'self' <source> <source>
blueriq.security.click-jacking-protection.content-security-policy.frame-ancestors = 'self' <source> <source>

Property value overrides in development

When the Development Tools component is present and active, additional settings are required for the Content Security Policy, due to the frameworks used by this component.

In the Runtime, this is achieved by overriding the property values in the application-development-tools.properties file. The default values for the Content Security Policy in application-development-tools.properties are:

blueriq.security.click-jacking-protection.content-security-policy.script-src = 'self' 'unsafe-eval' 'unsafe-inline'
blueriq.security.click-jacking-protection.content-security-policy.style-src = 'self' 'unsafe-inline'
blueriq.security.click-jacking-protection.content-security-policy.img-src = 'self' 'unsafe-inline' data:



Frontend Deployment

Security headers generated by the Runtime are only applied to pages that are served from the Runtime itself. In case the Blueriq Frontend is served from a CDN or via Reverse Proxy these headers will need to be configured from the CDN or Reverse Proxy, for the headers to be applied.


Cross-site scripting (XSS) protection

Cross-site scripting, also known as XSS protection, is implemented as an IValueFormatter for values coming from external sources. It implements basic HTML escaping as described on the OWASP website using a normalization and targeted replace technique.

  1. Web application - data from inputs are formatted in the controllers before being processed;
  2. Development plugin - modifying the profile from the development plugin will use formatted values as well;
  3. Web services - both REST and SOAP services are protected against XSS by the formatter;
  4. The Request Parameters plugin.

Canonicalization

All input is transformed into a canonical form before validation. Canonicalization involves URL- and HTML-decoding the input.

We use ESAPI to canonicalize the input string to improve the detection. We allow mixed and multiple encodings before we validate if no malicious pattern is found. You can disallow multiple and mixed encoding by specifying your own ESAPI.properties. You can specify the location of this file by passing the environment setting org.owasp.esapi.resources. When ESAPI throws an IntrusionException an empty string will be used.

By default this is enabled.

The property should be:

blueriq.security.xss-protection.enabled=true

To disable use:

blueriq.security.xss-protection.enabled=false

XSS Components

The above properties enable/disable cross site scripting protection as a whole. If needed, custom rules can be applied, as described below. Cross site scripting protection has the following components :

  1. Setting the HTTP header
  2. Request body validation
  3. Request parameters validation
  4. Request url validation
  5. Multipart request validation
  6. Whitelist
  7. Blacklist

By default all components are enabled.

By default all components are enabled.

The properties should be:

blueriq.security.xss-protection.header.enabled=true
blueriq.security.xss-protection.request-body-validation.enabled=true
blueriq.security.xss-protection.request-parameter-validation.enabled=true
blueriq.security.xss-protection.request-url-validation.enabled=true
blueriq.security.xss-protection.whitelist.enabled=true
blueriq.security.xss-protection.blacklist.enabled=true

To disable use:

blueriq.security.xss-protection.header.enabled=false
blueriq.security.xss-protection.request-body-validation.enabled=false
blueriq.security.xss-protection.request-parameter-validation.enabled=false
blueriq.security.xss-protection.request-url-validation.enabled=false
blueriq.security.xss-protection.whitelist.enabled=false
blueriq.security.xss-protection.blacklist.enabled=false

 1 Header

For the header there are no additional parameters.

2 Request Body Validation

This property refers to validation for POST requests that contain an application/json request body. When this type of validation is enabled, the request is blocked if dangerous input is detected in the request body.

3 Request Parameter Validation

This property refers to validation for request parameters. When this type of validation is enabled, the request is blocked if dangerous input is detected in the request parameters.

4 Request URL Validation

This property refers to validation for request URL. When this type of validation is enabled, the request is blocked if dangerous input is detected in the request URL.

5 Multipart Request Validation

This property refers to validation for multipart requests. Body parts that have content-type "application/json" are validated the same way as for the Request Body Validation. When this type of validation is enabled, the request is blocked if dangerous input is detected in the JSON request parts.

Note: for all of the properties above , dangerous input is determined by the blacklist and whitelist configuration.

6 Whitelist Customization

(White list validation is appropriate for all input fields provided by the user. White list validation involves defining exactly what IS authorized, and by definition, everything else is not authorized.)
By default, when the XSS Whitelist protection is activated, all tags and attributes are blocked.

PropertyDescription
blueriq.security.xss-protection.whitelist.allowed-protocolsdefines the allowed protocols for URI attributes
blueriq.security.xss-protection.whitelist.allowed-tagshtml tags that will be allowed
blueriq.security.xss-protection.whitelist.allowed-global-attributesattributes that will be allowed for all the allowed tags
blueriq.security.xss-protection.whitelist.allowed-attributes.<tag name>allows fine tuning of allowed attributes for a specific tag name
blueriq.security.xss-protection.whitelist.uri-attributes.<tag name>

allows specifying for a specific tag what attributes are URI attributes and the protocols allowed will be the ones globally defined(first property in this table)

Note: If an attribute is marked as an URI attribute, then the attribute value must be a URI, otherwise it will not pass the validation and it will be removed

Note: If an attribute is marked as an URI attribute, then the attribute value must be a URI, otherwise it will not pass the validation and itwill be removed


Whitelist configuration examples

The example is just a simple example for understanding how whitelist properties work. This is not meant for production use! Please define your own whitelist properties tailored for your project needs.

blueriq.security.xss-protection.whitelist.enabled=true
# define what protocols are allowed on uri attributes
blueriq.security.xss-protection.whitelist.allowed-protocols=http,https
# define what tags are allowed
blueriq.security.xss-protection.whitelist.allowed-tags=b,i,u,q,img
# define what attributes are allowed on all the allowed tags
blueriq.security.xss-protection.whitelist.allowed-global-attributes=class,tabindex,title
# define what attribute are allowed on each tag
blueriq.security.xss-protection.whitelist.allowed-attributes.q=cite
blueriq.security.xss-protection.whitelist.allowed-attributes.img=src,alt
# define which attributes of which tags can contain URIs and are subject to the allowed-protocols restrictions
blueriq.security.xss-protection.whitelist.uri-attributes.a=href
blueriq.security.xss-protection.whitelist.uri-attributes.img=src



7 Blacklist

The blacklist checks the input against predefined regular expressions. The blacklist can be enabled or disabled with the following settings:

By default this is enabled.

The property should be:

blueriq.security.xss-protection.blacklist.enabled=true

To disable use:

blueriq.security.xss-protection.blacklist.enabled=false

X-XSS-Protection Header

The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting attacks. Although these protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline'), they can still provide protections for users of older web browsers that don't yet support CSP. The response header that will be sent:

X-XSS-Protection: 1; mode=block

Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.

By default all components are enabled.

The properties should be:

blueriq.security.xss-protection.header.enabled=true

To disable use:

blueriq.security.xss-protection.header.enabled=false

Registering custom XSS protection components

In case the default blacklist and/or whitelist implementations are not sufficient, it is possible to register custom blacklist and/or whitelist implementations.

Create your own blacklist implementation:

import com.aquima.interactions.project.impl.xss;

public class SampleXssBlacklist implements IXssBlacklist {
  public String sanitize(String input) {
    // custom input sanitization
  }
  public boolean isValid(String input) {
    // custom input validation
  }
}

Create your own whitelist implementation:

import com.aquima.interactions.project.impl.xss;
public class SampleXssWhitelist implements IXssWhitelist {
  public String sanitize(String input) {
    // custom input sanitization
  }
  public boolean isValid(String input) {
    // custom input validation
  }
}

Expose your custom blacklist and/or whitelist implementations as Spring beans:

@Configuration
public class SampleXssConfiguration {
  @Bean
  public IXssBlacklist xssBlacklist() {
    return new SampleXssBlacklist();
  }
  @Bean
  public IXssWhitelist xssWhitelist() {
    return new SampleXssWhitelist();
  }
}

The Runtime will automatically detect your custom implementations and register them instead of the default implementations.


Potential problems

  1. In its current form, the formatter does not provide 100% protection against cross-site scripting. Other countermeasures (such as a web application firewall) are recommended. See the OWASP website for more information on XSS attacks.
  2. It is not possible to disallow XML/HTML content in the profile values because there are valid use cases which require this. Therefore the decision to protect only the entry points mentioned above has been made. It is the responsibility of the developer using extension points to make sure the values inserted into the profile are validated against XSS.
  3. Requests with parameters containing tags with URI attributes of the form "http://www.example.com" (i.e. without a trailing slash) will be blocked
  4. Values entered in fields (profile) or comments containing tags with URI attributes will be sanitized (eg. the input <a href="http://www.example.com">link</a> will be sanitized to <a href="http://www.example.com/">link</a>)

Hiding the WSDL

WSDL files provide detailed information about the services ports and bindings available to web server. An attacker can try to submit special characters or malicious content to the Web service and potentially cause a denial of service condition or unauthorised access to database records. In addition, the attacker may try to guess other 'private' (unexposed) methods by using the information provided in the WSDL files.

For example the following web service description was discovered:

ManagementService.wsdl

The URL of the above WSDL is:

https://<host>:<port>/Services/Managementsservice?singleWsdl

Recommendation: The access to WSDL file should be limited as much as possible (for example the entry point should go thourgh nginx [https://nginx.org/en/] or something similar). If services are provided only to a limited number of entities, it may be better to provide WSDL privately to each of these entities than to publish WSDL publicly.

Blueriq SameSite cookie attribute

With the SameSite cookie attribute it is possible to declare whether blueriq sends cookies while doing cross-site-requests.  More and more browsers are blocking the cookies from being sent when this attribute is not set correctly. For more information, see https://owasp.org/www-community/SameSite.

Blueriq has two properties that enable the attribute and make it possible to declare the value of it. 

The attribute can have 3 possible values: 

  • strict: the cookies are only sent when the origin of the requesting page is the same as one of the resources it is accessing.
  • lax: cookies get only attached to requests from the same origin or are top-level redirects
  • none: the cookie gets attached with the request regardless of the requests origin or type


By default, the SameSite attribute of the cookie is disabled.

Enabling the same site cookie attribute can be done by configuring the following property:
application.properties

blueriq.security.cookie-same-site.enabled=true


By default the value is set to strict if same site is enabled.

Setting the value of the SameSite cookie attribute can be done by configuring the following property:

application.properties

blueriq.security.cookie-same-site.value=strict

The SameSite value can have the following three values, which are explained above:

  • strict
  • lax
  • none