Security

This page describes integrated security functions of the Business Process Center and measures that are recommended for secure productive use.

A combination of different measures is recommended for the secure use of the BPC.

Make sure that transport encryption (see TLS / HTTPS) is used. You should also set up Reverse proxy and Web Application Firewall in front of the BPC.

Display of the recommended architecture
Illustration 1. Display of the recommended architecture

TLS / HTTPS

It is recommended that you configure Secure connection (TLS/HTTPS) for the BPC. This ensures encrypted transmission in the network.

If this is implemented, you should also use secure cookies

Reverse proxy

The use of a reverse proxy is strongly recommended. This ensures that the BPC is isolated at network level and only targeted network traffic is forwarded. A reverse proxy can make additional changes to the network traffic and offers further functions, such as caching. Caching.

The BPC uses websockets (under /websocket). This requires additional settings depending on the software used.

NGINX

NGINX is a very frequently used web server/reverse proxy.

The following configuration can be used to make the BPC available under the HOSTNAME/bpc path.

Beispielkonfiguration NGINX
server {
    server_name HOSTNAME;

    listen 80 default_server;
    listen [::]:80 default_server;

    # TODO TLS configuration

    keepalive_timeout 300s;
    client_max_body_size 2048m;
    proxy_connect_timeout 300s;
    proxy_send_timeout 300s;
    proxy_read_timeout 300s;
    fastcgi_read_timeout 300s;

    location /bpc/ {
        # needed for websockets
        proxy_set_header Upgrade "websocket";
        proxy_set_header Connection "Upgrade";

        proxy_set_header X-Real_IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;

        proxy_read_timeout 36000s;

        # This is necessary to pass the correct IP to be hashed
        real_ip_header X-Real-IP;
        proxy_redirect off;

        proxy_pass http://127.0.0.1:8181/;
    }
}

This configuration serves only as a simple example.

The configuration must generally be adapted to your circumstances. There is no claim to completeness or accuracy.

HAProxy

Der HAProxy ist ebenfalls eine etablierte Option.

Beispielkonfiguration HAProxy
global
    log /dev/log local0
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    user haproxy
    group haproxy
    daemon
    ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
    ssl-default-bind-ciphers HIGH:!aNULL:!MD5

defaults
    log global
    option httplog
    timeout connect 300s
    timeout client 300s
    timeout server 300s

frontend bpc_frontend
    bind :80
    bind :443 tfo ssl crt /etc/haproxy/certs/ alpn h2,http/1.1
    mode http
    http-request redirect scheme https unless { ssl_fc }
    http-request set-header Host %[req.hdr(Host)]
    http-request set-header X-Real-IP %[src]
    http-request set-header X-Forwarded-For %[src]
    http-request set-header X-Forwarded-Proto https
    default_backend bpc_backend

backend bpc_backend
    mode http
    server bpc1 127.0.0.1:8181 check

This configuration serves only as a simple example.

The configuration must generally be adapted to your circumstances. There is no claim to completeness or accuracy.

Web Application Firewall

Mit einer Web Application Firewall kann der Netzwerkverkehr gescannt und gefiltert werden. Dabei können typische Angriffe erkannt und abgewehrt werden.

Für den Client-Zugriff (User mittels Webbrowser) sollten Sie eine Allowlist mit folgenden Werten aufsetzen:

SERVER/*.* (e.g.: /index.html /index.jsp /app.js)
SERVER/cxf/** -> (e.g. /cxf/bpc-core/configuration)
SERVER/resources/**
* SERVER/bpc-fe-/**
* SERVER/bpc-theme-/**
SERVER/websocket

ModSecurity is often used for this.

Database connections

For connections to relational databases (Databases and Backend Connections of type data_source), only a read-only connection is required in most cases. To prevent security problems, it is recommended to use a database user with read-only rights in accordance with the least privilege principle.

Further measures to increase the security level

The following describes security measures integrated in the BPC.

Cross-site request forgery

The BPC attempts to fend off CSRF attacks. If you use your own modules or integrate external applications via the BPC, you may have to make adjustments so that you are restricted by the protection mechanism itself.
See also CSRF defense

For backend Connections of type http_proxy, it is possible to switch off the CSRF check can be switched off.

User session IP pinning

To prevent a user session from being "stolen", the BPC remembers the user’s IPhttps://de.wikipedia.org/wiki/Session_Fixation[(session fixation]) when logging in. This information is compared with the IP address of the call for each subsequent call. If the IP address of the call differs from that of the user session, the call is rejected.

For this function to take effect, the HTTP header X-Forwarded-For must be set correctly when using proxies. This also applies to the web socket.

Content Security Policy

A Content Security Policy (CSP) is defined via HTTP header. This is implemented by the browser. This is implemented by the browser and means that resources such as images and script files are not loaded from unknown sources.

It may be necessary to adapt the CSP to your requirements. To do this, the header setting must be changed as described on the HTTP header page.

HTML Sanitizing

In the frontend, the HTML code generated by the modules is automatically sanitized. JavaScript and invalid elements are removed to prevent scripting attacks. If your modules require inline JavaScript, you can do this via the setting sanitzeHTML setting on the respective module.

If the cleanup removes elements from the HTML, this is logged in the browser console. In order to view these logs, you may need to set the log level to debug/verbose.


Keywords: