Confluence behind LoadBalancer with another domain results in XSRF error

If you have an atlassian confluence running, which is published by a loadbalancer or reverse proxy using another domain, you might run into an XSRF error.

Example

Confluence FQDN: somehostname.domain.tld

LoadBalancer Confluence FQDN: confluence.domain.tld

Some actions like uploading your profile picture (https://confluence.domain.tld/users/profile/editmyprofilepicture.action) do not work. You'll receive an generic error from the confluence page (see red box of the screenshot below). If you check the HTTP Header response, you'll see XSRF check failed. It is caused by the confluence cross site request forgery (CSRF) protection.

Solution

Edit confluence server.xml and add the FQDN from the LoadBalancer or reverse proxy.

More information can be found here: https://confluence.atlassian.com/kb/cross-site-request-forgery-csrf-protection-changes-in-atlassian-rest-779294918.html

PRTG Hardening Security CSRF

PRTG version 22.1.74 introduces protection from Cross Site Request Forgery (CSRF) attacks to harden the products security. 

In CSRF the attacker sends the victim an URL with an action, like adding an administrative account, transfering some money to another bankaccount or something similar. When the victim clicks on the link, the (unintended) action is executed with the victims permissions. Implementing XSRF tokens prevent this attack. 

Updating PRTG server to 22.1.74 prevents changes to PRTG via web forms that attackers may use to trick PRTG users into performing requests with the user account's context. (CVE-2021-34547)

Source: https://www.paessler.com/prtg/history/stable

Exploit:  https://github.com/likhihcv/PRTG_Network_Monitor_20.1.55.1775_CSRF

Explot payload: 

PRTG user accounts after executing payload: