Security

This page describes the built-in security features of the BPC as well as measures recommended for secure production use.

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

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

Diagram of the Recommended Architecture
Illustration 1. Diagram of the Recommended Architecture

TLS / HTTPS

It is recommended to configure a Secure Connection (TLS/HTTPS) for the BPC. This ensures encrypted transmission over the network.

Once this is implemented, you should also enable secure cookies.

Reverse Proxy

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

The BPC uses WebSockets (at /websocket). Depending on the software used, this may require additional configuration.

NGINX

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

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

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 is intended only as a simple example.

As a rule, the configuration must be adapted to your specific circumstances. No claim is made as 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 is intended only as a simple example.

As a rule, the configuration must be adapted to your specific circumstances. No claim is made as 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/*.* (z.B: /index.html /index.jsp /app.js)
SERVER/cxf/** -> (z.B. /cxf/bpc-core/configuration)
SERVER/resources/**
SERVER/bpc-fe-*/**
SERVER/bpc-theme-*/**
SERVER/websocket

ModSecurity is often used for this purpose.

Database Connections

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

Additional Measures to Increase Security

The following describes security measures integrated into the BPC.

Cross-Site Request Forgery

The BPC attempts to prevent CSRF attacks. If you use your own modules or integrate external applications via the BPC, you may need to make adjustments so that you are not restricted by the protection mechanism itself.
See CSRF Protection

For backend Connections of type http_proxy, it is possible to disable the CSRF check.

User Session IP Pinning

To prevent a user session from being “stolen,” the BPC records the user’s IP address upon login (session fixation). This information is compared with the IP address of each subsequent request. If the IP address of the request differs from the one associated with the user session, the request is rejected.

For this feature to work, the HTTP header X-Forwarded-For must be set correctly when using proxies. This also applies to WebSockets.

Content Security Policy

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

It may be necessary to customize the CSP to suit your needs. To do this, you must change the header setting as described on the page HTTP Headers.

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 disable this sanitization using the sanitizeHTML setting for the respective module.

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


Keywords: