Securing Cadenza

How to Protect Against Common Attacks and Vulnerabilities

Cadenza is always part of a bigger deployment environment and some attacks can not be mitigated by Cadenza alone. We will outline what Cadenza protects against out of the box, what measures you can take with Cadenza to have more security, and we will highlight where it is necessary to make sure that your deployment environment is correctly set up.

Session Hijacking

Cadenza Web protects itself against Session Hijacking by generating a new session after a successful authentication request, and invalidating the old session. In addition, in normal operating mode, the session id is modeled as a cookie that is not accessible from JavaScript.

See also: OWASP description

Cross Site Scripting (XSS)

The foundation of our defense against XSS is that we minimize rendering user submitted content and when we do output it, it is always escaped.

See also: OWASPs description of XSS

Cross Site Request Forgery (CSRF)

See also: OWASPs description of CSRF

Cadenza has a same origin check that automatically verifies whether requests are coming from the same origin as Cadenza is running on. We reject all requests that violate this constraint and thus prevent CSRF attacks.

If you get warnings that some requests are being blocked by Cadenza, you may have a faulty reverse proxy configuration. See Reverse Proxy and Load Balancer Requirements.

SQL Injection

In the few cases where user submitted values are passed on to our data access layer, we use PreparedStatements with placeholders to insert these values. This prevents SQL Injection completely.

Note there is an explicit exception from this: If you define function attributes in workbooks then you are able to enter any SQL function. Unauthorized access here could lead to SQL Injection. The current mitigation strategy here is to secure this feature organizationally. This is considered an admin-feature only.

See also: OWASPs description on SQL injection

Clickjacking

Clickjacking is an attack where a malicious user crafts a webpage that will entice users to click on a certain location for example by offering something that can be won, and in reality having the user click on a UI control in a different webpage that is to the advantage of an attacker. This can be done by overlaying an iframe on top of other content and making that iframe transparent. The user will click on the "Win a free iPhone" button, but in reality he has modified some crucial security setting in the overlayed iframe.

This attack is described and documented in the Clickjacking arcticle 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.xml:

  …
  <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 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.

Content Sniffing by Browsers

Since Cadenza 9.3 we always set the response header X-Content-Type-Options HTTP header to the value nosniff. This prevents browsers from interpreting the media type of a resource when it is not explicitly advertised, and it 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.

See also Mozillas documentation on Content-Types

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

Enable Strict Transport Security

The Strict-Transport-Security HTTP header (HSTS) is a way to inform browsers that the site should only be accessed using HTTPS.

The HSTS header should be set by the instance that also does TLS termination. Usually this is some sort of reverse proxy. See also Reverse Proxy and Load Balancer Requirements.

For maximum security, HTTPS should be enforced also for possible future Cadenza sub-domains (not used atm) and for maximum performance, preloading should be used.

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

See also Mozillas documentation on HSTS

Caching by (Forward) Proxy Servers

Cadenza controls in detail for how long forward proxies and clients are allowed to cache its responses using 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.

See also Mozillas documentation on Cache-Control

Referrer Information Leaking

When a site a links to site b, the browser includes some info about site a when following that link for site b to access that info (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.

See also Mozillas documentation on Referrer Policy