ANTICROSSSITEREQUESTFORGERY - Detailed description

Overview

Parameter:ANTICROSSSITEREQUESTFORGERY
Category: Custom Default
value: 0 (disabled)
Product: eTASK.Other (Custom)

What does this parameter do?

This parameter enables a security mechanism to protect against Cross-Site Request Forgery (CSRF) attacks. CSRF is an attack method in which an attacker attempts to perform unwanted actions on behalf of a logged-in user. When enabled, the portal checks a special security token with every request to ensure that the request actually originates from the user and was not initiated by a third-party website.

This parameter is currently in BETA status. If you encounter issues with specific use cases after enabling it, please let us know and disable the feature again.

This parameter is in BETA status. If you encounter issues with specific use cases after activation, please let us know and disable the feature again.

What is this parameter used for?

• Protection against Cross-Site Request Forgery (CSRF) attacks on the portal

• Validation of the origin of user requests through token verification

• Increased security for sensitive actions such as data changes

• Prevention of unauthorized actions via manipulated external links

• Meeting security requirements and compliance standards

Technical Details (for Administrators)

Format: Numeric value (0 or 1)
Default value: 0 (disabled)

Valid values:

• 0 = Anti-CSRF protection is DISABLED (default)

• 1 = Anti-CSRF protection is ENABLED

Important notes:

• When enabled, an anti-forgery token is validated with every request

• The system checks the Referer header to ensure that requests come from the same domain

• When protection is enabled, JavaScript libraries that manage tokens are automatically included

• This parameter works in conjunction with the ALLOWEDREFERERS parameter to allow external login services (e.g., Microsoft Azure)

• Requests without a valid token are blocked and logged

Interaction with other parameters:

This parameter requires ALLOWEDREFERERS when external authentication services (e.g., Azure Active Directory) are used. Trusted domains from which redirects are permitted are entered in ALLOWEDREFERERS.

When should you change this value?

Set the value to 1 (enable CSRF protection) if:

• You have increased security requirements for your portal

• Compliance requirements or security policies require it

• Your portal is publicly accessible via the Internet

• You manage sensitive data that requires special protection

• Security audits recommend enabling CSRF protection

Leave the value set to 0 (CSRF protection disabled) if:

• The portal is operated only on an internal network without internet access

• You want to avoid compatibility issues with certain integrations

• The allowed referrers have not yet been fully configured

• Problems with token validation occur during the testing phase

Important Notes

1. Configuration of ALLOWEDREFERERS required
   If you use external authentication services such as Azure Active Directory, you must enter the corresponding domains in the ALLOWEDREFERERS parameter (e.g., https://login.microsoftonline.com). Otherwise, redirects from the login service will be blocked.

2. Impact on existing integrations
   Activation may affect existing interfaces and external applications that access the portal. Test the activation in a test environment first.

3. Logging for blocked requests
   Blocked requests are recorded in the application log. After activation, monitor the log to identify legitimate requests that may be blocked due to missing referer entries.

4. Deactivation Not Recommended
   Once you have enabled this protection, you should not disable it again for security reasons, unless serious technical issues arise.

Security

Does changing this parameter affect security?

Yes, enabling this parameter has direct and significant security implications. The parameter implements a key protection mechanism against a common type of attack.

Positive aspects:

• Effective protection against Cross-Site Request Forgery (CSRF) attacks

• Prevents unintended actions caused by manipulated external links

• Blocks unauthorized access from third-party websites

• Meets modern security standards for web applications

• Protects users from unnoticed, malicious actions

Note:

• Incorrect configuration may result in legitimate requests being blocked

• External integrations must be configured in ALLOWEDREFERERS

• Increased implementation effort during initial setup

Data protection assessment: - Increased protection of personal data by preventing unauthorized changes - Reduced risk of data breaches caused by CSRF attacks

Recommendation: Be sure to enable this protection for production systems, especially if the portal is accessible via the Internet. Configure ALLOWEDREFERERS correctly for all external services used and monitor the log for blocked legitimate requests after activation.

Practical example

Initial situation: Your eTASK.FM portal is accessible via the Internet and uses Azure Active Directory for login. You want to protect the portal against CSRF attacks, in which an attacker attempts to perform actions on behalf of logged-in users via a specially crafted email or website.

Configuration: ANTICROSSSITEREQUESTFORGERY = 1 (enabled)
ALLOWEDREFERERS = https://login.microsoftonline.com

After the change:

• An anti-forgery token is automatically generated with every page view

• The portal checks for a valid token with every request

• Requests from external websites are detected and blocked

• Redirects from the Azure login are allowed, since the domain is listed in ALLOWEDREFERERS

• Blocked attack attempts are logged

Result: An attacker can no longer trigger actions in the portal via manipulated links or emails. Even if a user clicks on a malicious link, the request is blocked because it does not contain a valid anti-forgery token. Legitimate requests from the Azure login continue to function flawlessly.

Alternative scenarios:

Scenario A - Internal portal without external authentication:

• ANTICROSSSITEREQUESTFORGERY = 0 (disabled)

• Portal accessible only on the intranet

• Lower risk, simpler configuration

Scenario B - Portal with multiple external services:

• ANTICROSSSITEREQUESTFORGERY = 1 (enabled)

• ALLOWEDREFERERS = https://login.microsoftonline.com,https://login.partner.com

• Multiple trusted domains for various integrations

Recommended setting

For standard installations:1(enabled)

Reason:

• CSRF attacks are among the most common threats to web applications

• Modern security standards require protection against CSRF

• The protection mechanism is mature and proven

• Minimal performance overhead with significant security gains

Exceptions (deactivation with value 0):

• Purely internal portals without internet access in highly secured networks

• Test environments during the development phase

• Temporary deactivation for error analysis in case of technical issues

• Legacy integrations that are not compatible with token validation

Tip: First enable protection in a test environment and verify all functions and integrations. Identify all external services that require access and add them to ALLOWEDREFERERS. After a successful test phase, enable protection in the production system and monitor the log for unexpected blockages during the first few days.