Activate Clickjacking-Framing-Protection service

SAP NetWeaver comes with its own solution to prevent clickjacking for its most relevant UI frameworks. For more information about this protection, see the corresponding SAP Notes.

By default, clickjacking protection is disabled. To activate it, you need to insert a value into table HTTP_WHITELIST.

Insert values into table HTTP_WHITELIST

Transaction: SE16

Check if clickjacking protection service is enabled or disabled. It is disabled, if no record with ENTRY_TYPE=30 is in the table, or if the table is empty.

Table name: HTTP_WHITELIST

Execute

Result

By default, no values are in the table and the service is not enabled. For data that needs to be inserted into table HTTP_WHITELIST, see SAP Note 2142551. Creating an entry type with vale 30 activates the whitelist.

Transaction: SE16

Select F5 or click on the new entry icon.

Insert data. See links below for additional information on possible values.

Click save to persist the entry in the table.

Afterwards, the table will contain one record. As the record has value 30 for column ENTRY_TYPE, the clickjacking protection service is enabled.

Activate ICF whitelist service

Adding a record activates the service, but to make apps working, additional configuration steps must be taken. For instance, accessing now a WDA app (e.g. SAML2) will resolve in a HTTP 500 internal server error. This is caused by having the clickjacking protection activated, but not the whitelist service.

To solve the HTTP 500 error, you need to activate the ICF whitelist service.

Transaction SICF_INST
Technical name: UICS_BASIC

Execute. This will activate the ICF node

/sap/public/bc/uics/whitelist

Result

After enabling the service and the ICF node, the above WDA app will open in the browser.

https://vhcalnplci:44300/sap/bc/webdynpro/sap/saml2

Additional information on setting whitelist entries.

 

OpenVPN Assign static IP to client

After configuring the overall OpenVPN client and server infrastructure, my clients can connect to a VPN. The client can access server resources and vice versa. While the server gets normally always the same IP assigned, the client IP address is assigned dynamically from a pool of IP addresses. Meaning: there is no guarantee that the client always gets the same IP address. Normally, this is not a problem, as the client connects to consume server resources. Such like a web site, or git repository. In my case, the architecture is that the OpenVPN server acts as a proxy to internal services. The web site, git repository, etc are running on the client. Therefore, the server must be able to connect to the client using a fix address.

To make this work, each time a client connects, the same IP must be assigned to. OpenVPN allows to assign a static IP to a client.

Configuration

  1. In /etc/openvpn create folder ccd. Ccd stands for client config directory, meaning: it contains the configuration for a client.
  2. Edit file server.conf and add line “client-config-dir ccd
# EXAMPLE: Suppose the client
# having the certificate common name "Thelonious"
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
client-config-dir ccd

3. Create a configuration file for each client and put into directory ccd. As file name, use the same name for the client as used in the CN field of the client certificate.

ifconfig-push IP MASK

Example:

ifconfig-push 10.8.0.2 255.255.255.255

CLI steps

sudo mkdir /etc/openvpn/ccd
sudo touch /etc/openvpn/ccd/client1
sudo vim /etc/openvpn/server.conf
Uncomment the line containing client config parameter
client-config-dir ccd

sudo vim /etc/openvpn/ccd/client1
Insert:
ifconfig-push 10.8.0.2 255.255.255.255
Restart OpenVPN service on server
sudo /etc/init.d/openvpn restart

Client with automatic assignment of IP: 10.8.0.6

After restart of OpenVPN server: IP is now 10.8.0.2

Server log

 

Additional information can be found in OpenVPN documentation.

client-config-dir

“This file can specify a fixed IP address for a given client using –ifconfig-push, as well as fixed subnets owned by the client using –iroute.https://openvpn.net/index.php/open-source/documentation/manuals/65-openvpn-20x-manpage.html

ifconfig-push

„Push virtual IP endpoints for client tunnel, overriding the –ifconfig-pool dynamic allocation.” https://openvpn.net/index.php/open-source/documentation/manuals/65-openvpn-20x-manpage.html

ERR_CONTENT_DECODING_FAILED

Configuring a reverse proxy is not an easy task. It involves some trial and error and dealing with unexpected errors. One of those errors is ERR_CONTENT_DECODING_FAILED. The web site won’t load in your browser will show this error message:

Error ERR_CONTENT_DECODING_FAILED may show up in your browser when a resource is configured on your reverse proxy, and the backend communication is working. That is: the backend is returning data, but not in a form the browser expects.

Example: browser expects a GZIP response, but receives plain text. Therefore the hint from your browser about content decoding failed. The content is received, but the browser is not able to decode / understand the data. If a plain text response is expected, but the received response from the backend is zipped, the browser cannot read the content.

To solve this error, reset the Accept-Encoding request header in your Reverse Proxy configuration.

Apache

Documentation

RequestHeader unset Accept-Encoding

Example

<Location /test>
    RequestHeader unset Accept-Encoding
    ProxyPass https://0.0.0.0:443
    ProxyPassReverse https://0.0.0.0:443/
    Order allow,deny
    Allow from all
</Location>

NGINX

Documentation

proxy_set_header Accept-Encoding "";