Security
This page describes the built-in security features of the BPC as well as measures recommended for secure production use.
Recommended System Architecture
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.
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 modifications to network traffic and offers other features, such as caching.
|
The BPC uses WebSockets (at |
NGINX
NGINX is a very commonly used web server/reverse proxy.
The following configuration can be used to make the BPC available at the path HOSTNAME/BPC.
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.
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/websocketModSecurity 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.
