Security

This document contains essential information about Sirveo’s security properties. If you are running Sirveo on your own infrastructure, please familiarize yourself with it.

We are the first to deploy new Sirveo releases in production. This means that we are affected first by bugs, breaking changes and - notably - security problems. Sirveo powers our CRM-related functions, communication, the provisioning of Sirveo cloud environments and sandboxes, as well as Sirveo’s license management. Not just because of our use-your-own-stuff philosophy, but because Sirveo is the appropriate tool for solving our integration and automation needs well.

As with any powerful software, it requires a responsible understanding of its features, capabilities and configuration.

If you have security-related questions for your deployment scenario, get in touch.

Deployment essentials checklist

When deploying Sirveo for production use:

1. Read this document
2. Use TLS for UI and API access
3. If possible, leverage the network isolation feature
4. Use TLS for the database connection (SIRVEO_DB_SSLMODE=require)
5. Favor shorter JWT expiry times (SIRVEO_JWT_EXPIRY=2h)
6. Thoroughly test flows
7. Aim to keep binaries current, or close to the latest release
8. Read the changelog before upgrading

Outbound Network Behaviour (Server)

Flows can be configured to perform arbitrary outbound HTTP requests. Apart from what flows are configured to do, there are only three cases in which the server will make additional outbound requests;

(1) Online license verification

If a Sirveo server is (a) configured with a valid license, and (b) if that license requires online license verification, the server attempts periodic HTTP requests to license.sirveo.io, to activate or renew license verification information.

(2) Custom Telemetry

If a custom telemetry destination is configured with:

• SIRVEO_TELEMETRY_MODE="custom"
• SIRVEO_TELEMETRY_URL="https://<your destination>"

The server will attempt periodic requests to the configured URL. See the telemetry reference.

(3) Default Telemetry

If the telemetry mode is changed from the default disabled value to either:

• SIRVEO_TELEMETRY_MODE="default" or;
• SIRVEO_TELEMETRY_MODE="both"

The server will attempt to make periodic requests to https://license.sirveo.io. See the telemetry reference.

Important

Do not configure SIRVEO_TELEMETRY_MODE with either default or both, unless you want to send us basic telemetry data.

Outbound Network Behaviour (UI)

From version 0.2.5, the UI’s dashboard fetches announcements about new Sirveo releases from the web. This causes the browser to make an HTTP GET request to the following URL:

https://srv.cloud.sirveo.io/w/dashboard-news-v1?src=dashboard&ver=0.x.x

If the UI can determine the server’s version, it is included in the request. The version information may be used to customize the retrieved announcements, typically to urge an upgrade when a security-related issue has been addressed in a more recent release.

Networking and HTTP

• See network isolation for details about separating the server’s admin and inbound ports
• When running Sirveo behind a reverse proxy to terminate TLS, it is important to configure the correct IP resolution from HTTP request headers. See client IP header configuration
• When exposing flows via webhooks and links, Sirveo guarantees that flow input data will be valid, parse-able JSON objects.
• When performing HTTP requests from within flows, response bodies larger than 256 KiB are pre-emptively rejected, and will cause the HTTP node to output an error to that effect. This prevents unexpected, arbitrarily large inputs from entering flows.

Do…

Ensure that Sirveo resolves the correct client IP addresses. Use the UI’s event browser to inspect auth.ok event data.

Note

The upstream reverse proxy that sends requests to Sirveo should be trustworthy. Otherwise it may be spoofing IPs, or allow IP header spoofing through inappropriate configuration.

Authentication

• Password hashing is handled by Bcrypt, supporting a maximum password length of 72 bytes, and provides constant-time comparison
• The server’s HTTP API uses a JWT-based authentication scheme.
• The signing method is HMAC using SHA-512
• Signing secrets are configurable via SIRVEO_JWT_SIGNING_SECRET, which requires a hex-encoded value which must contain between 32 to 64 bytes.
• If not provided, a random 64-byte signing secret is generated on each server startup
• JWTs contain exp, including nbf and iat claims, and are validated accordingly
• The default JWT validity period is 4 hours (as of 0.1.0)
• You should configure a validity period appropriate for your deployment scenario. SIRVEO_JWT_EXPIRY accepts values between 15m and 168hh (7 days). Shorter is better.

Do not…

Expose Sirveo to the internet without TLS

Do…

Ensure that the network path between Sirveo and the upstream reverse proxy that handles TLS termination is trusted

Data storage

• Sirveo server stores all it’s data in the configured PostgreSQL database.
• The server does not currently perform application-level encryption any database content

Do…

Use SSL for database configuration, preferably sslmode=require,

General Design

By design, Sirveo does not provide features which:

• provide filesystem access
• provide the ability to run arbitrary shell commands or sub processes
• provide automatic binary updates

Server variables

Server variables can be marked as secrets. The server’s API treats secret server variables on an input-only basis. This means that it is not possible to retrieve the values secret server variables via the API. However, note that secret server variables are stored plainly in the database.

Important

While the server’s API won’t output the values of server variables marked as secrets, it is technically possible to purposefully configure flows to expose server variables (including secrets) in flow output.

Server variables can be accessed in flows when flows are configured with associated flow variables. Flows should not be configured to access more server variables than required for their execution. There are three scenarios where careful attention should be given:

1) When using HTTP nodes

HTTP nodes can send data to external systems. It is common to add authentication headers to outbound HTTP requests. For example:

Authentication: Bearer ${vars:my-api-token}

When enabling the “send input data” setting on HTTP nodes, it will send whatever input data the node receives to the target URL (when using a request method that allows request bodies). Take care that you know exactly what input data the flow will/may generate for that HTTP node.

2) When exposing flows externally

As a inherent and useful feature, flows can be exposed through configuring links (for web flows) and webhooks (for task & graph flows) in the admin UI. Even if links/webhooks are configured, the associated flows must be active for them to work.

Links are not authenticated. Webhooks may be configured to require an access key. It is also possible to implement your own authentication schemes within flows. Test flow output thoroughly when exposing them via links and webhooks. You should know exactly what output may occur in your externally-accessible flows.

Do…

Make use of output nodes in flows which expose data externally via webhooks. Output nodes provide explicit control over flow output data, and can reduce or eliminate the risk of unintended output data from being included in webhook’s HTTP response bodies.

3) Exposing variables and internal data

To help You avoid doing this unintentionally, we’ll show you how to expose flow variables (and potentially server variables) in external flows. The simplest way to do this by explicitly copying a flow’s variable store into the output of a node:

1. Configure at least one flow variable, which may or may not have an associated server variable
2. Make a new graph flow
3. Add a JS Code node that contains: $out = $vars
4. Run the flow, and notice how the node output contains the flow variable(s).

In this example, the JS Code node replaces its output with the content of the flow’s $vars store.

This does not expose the flow variables outside the authenticated context of the UI’s flow editor. To do that, the flow must be active, and exposed via a webhook configuration.

In the same way, a JS code node can inject the content of a flow’s $data store into its output, and therefore flow output, in some cases:

$out = $data

In web flows, take care not to copy any values from the $vars or $data stores into the flow’s $ui store, as that will expose values in plain text to the client. Prior to version 0.2.3, the contents of the $data store in web flows was AES-encrypted in client responses. From version 0.2.3, the $data store is temporarily persisted on the server, and entirely absent from client responses during web flow interactions.

For more information, see the flow stores reference.

Summary

• For HTTP nodes with the “send input data” enabled, make sure you know what the input could contain
• Be careful when assigning from the $vars and $data stores…
  • to the $out store in JS code nodes
  • to the $ui store in web flows
• When exposing flows via links and webhooks, test their output thoroughly (in your browser, or via postman, as appropriate)

Do…

Make sure that you test flow output data thoroughly