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.
Unable to render {include} The included page could not be found.
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.
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:
- 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.
- On any subsequent POST requests to a protected URL, the client must send the CSRF token
- 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
- 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:
| Header | Value |
|---|---|
X-Frame-Options | SAMEORIGIN |
Content-Security-Policy | frame-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.
Unable to render {include} The included page could not be found.
Overview
Content Tools