Securing Cadenza

Cadenza is always part of a bigger deployment environment and some attacks cannot be mitigated by Cadenza alone. This document explains how to secure your Cadenza installation and is divided into two parts:

Essential Security Configuration — security measures that must be actively reviewed and configured correctly by operators.
How Cadenza Defends Against Common Attacks — background information on typical attack classes and the protections Cadenza provides out of the box.

Essential Security Configuration

The following settings and deployment aspects should be actively reviewed and configured to ensure a secure Cadenza installation.

Reverse Proxy and Origin Configuration

Cadenza has a same-origin check that automatically verifies whether requests are coming from the same origin as Cadenza is running on. Cadenza rejects all requests that violate this constraint and thus prevent Cross-Site Request Forgery (CSRF) attacks.

If you get warnings that some requests are being blocked by Cadenza, you may have a faulty reverse proxy configuration. In that case, ensure that:

All user requests reach Cadenza through the same canonical origin (protocol + host + port).
The reverse proxy forwards the relevant headers correctly.
There are no inconsistencies between external and internal URLs.

See Reverse Proxy and Load Balancer Requirements for more details on how to configure the reverse proxy correctly.

Enable Strict Transport Security (HSTS)

The Strict-Transport-Security HTTP header (HSTS) is a way to inform browsers that the site should only be accessed using HTTPS. This prevents downgrade attacks and cookie leakage through plain HTTP.

The HSTS header should be set by the instance that also does TLS termination. Usually this is some sort of reverse proxy.

For maximum security, HTTPS should be enforced also for possible future Cadenza sub-domains (not used at the moment) and for maximum performance, preloading should be used:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Clickjacking Prevention and Embedding

Clickjacking is an attack where a malicious user crafts a webpage that will entice users to click on a certain location (e.g. “Win a free iPhone”) but in reality overlays a transparent iframe pointing to a victim application. The user believes they are clicking on the visible button, but in reality they are interacting with a hidden Cadenza UI element — for example changing a security setting.

This attack is described and documented in the clickjacking article by OWASP.

By default, Cadenza prevents this kind of attack by setting the frame-ancestors directive of the Content-Security-Policy header to self. This effectively prevents Cadenza from being embedded into a page/application other than Cadenza itself (except if Cadenza and the page/application are running behind a proxy server that serves both on the same origin).

If you want to explicitly embed Cadenza into a page/application, then you need to configure the origin of that page/application as a frame-ancestors source in the basicweb config:

  …
  <csp>
    <frame-ancestors enabled="true">
      <source>https://example.com</source>
    </frame-ancestors>
  </csp>
  …

See the basicweb configuration reference for more details on this configuration.

More details on frame-ancestors and its possible values can be found at the Mozilla documentation on CSP-Headers.

It is not recommended to disable the frame-ancestors directive in production.

Configuring a frame-ancestors source none is not allowed (will throw an exception), because Cadenza Web embeds itself in many places inside iframes.

Protecting Against Server-Side Request Forgery (SSRF)

Cadenza strictly enforces and validates that it communicates with servers using a well-defined protocol and will not allow invalid answers to reach a user. This means Server-Side Request Forgery in general is prevented.

There is one exception to this by design:

Cadenza includes a feature that allows embedding of web pages in worksheets. In normal operation your users will see this view in their browser, and therefore they will only be allowed to see the page if their browser generally allows it.

However, you can also create reports that include a webpage view and in that case the browser is running on the Cadenza backend as it generates the PDF and requests the web page. This could theoretically allow someone to access services they may not normally have access to. For example, a webserver reachable by the Cadenza server but not your normal users. This would be a form of Server-Side Request Forgery (SSRF) attack.

Administrators must configure this feature carefully to avoid misuse by users: The URLs available to the web page view are based on the base links that are defined in the External Links section of the Management Center. They can and should restrict access to that configuration to authorized users only.

If misconfigured, this feature could be used by an authenticated user to make Cadenza issue requests to unintended targets. This does not bypass authentication but could reach internal services.

HTTP Caching Headers

Cadenza controls in detail for how long forward proxies and clients are allowed to cache its responses using caching headers like the Cache-Control header. If content is generally cacheable, then proxies are allowed to cache responses. There is no need to further restrict proxy server caching behaviour.

In fact, reverse proxies in front of Cadenza should allow all cache related headers to pass to and from Cadenza to ensure correct and performant behaviour.

How Cadenza Defends Against Common Attacks

The following sections describe common web security attacks and how Cadenza mitigates them by default. You generally do not need to configure anything for these protections.

Session Hijacking

Cadenza protects itself against session hijacking by generating a new session after a successful authentication request and invalidating the old session. The session ID is stored as a HttpOnly cookie that is not accessible from JavaScript.

Cross-Site Scripting (XSS)

The foundation of our defense against XSS is escaping all user-submitted content.

Additionally, the HTTP header Content-Security-Policy: script-src 'none'; is set whenever Cadenza serves SVG content in order to prevent any embedded scripts from running.

Cross-Site Request Forgery (CSRF)

Cadenza has a same-origin check that automatically verifies whether requests are coming from the same origin as Cadenza is running on. Cadenza prevents CSRF attacks by rejecting all requests that violate this constraint.

If you get warnings that some requests are being blocked by Cadenza, see Reverse Proxy and Origin Configuration.

SQL Injection

Cadenza uses PreparedStatements with placeholders for all SQL queries. This prevents SQL Injection.

There is one explicit exception to this rule: when authorized users define function attributes in the Cadenza Management Center, they can enter any SQL function. Unauthorized access could lead to SQL injection in this case. The risk mitigation strategy is to secure this feature organizationally. This is considered a Cadenza administrator feature only. It is disabled by default.

Content Sniffing by Browsers

Cadenza always sets the HTTP response header X-Content-Type-Options to the value nosniff. This prevents browsers from interpreting a resource’s media type when it is not explicitly advertised. It also limits resources in style elements to be of type text/css and script tags to a JavaScript media type.

This header causes browsers to be more conservative with content that has an unknown media type and could prevent accidental execution with unclear media types.

Cadenza is always precise about the type of assets that are included in the page and sets the Content-Type header accordingly. Disabling content sniffing is only an additional security measure.

Referrer Information Leaking

When a site A links to site B, the browser includes some information about site A when following that link (the so-called referrer information). This is a potential security and privacy issue. But in all browsers that Cadenza supports, the referrer information is restricted sufficiently, so there’s no need to set a special referrer policy.