Tech Mastery: Deep Dives into AEM, Cloud Technologies, AI Innovations, and Advanced Marketing Strate

 What is CSRF?

Cross-site request forgery (CSRF) is a web vulnerability that lets a malicious hacker trick the victim into submitting a request that allows the attacker to perform state-changing actions on behalf of the victim.

1. The victim is authenticated in the target web application (e.g., www.example.com).
2. The attacker uses social engineering to trick the victim into visiting a malicious website (e.g.,checkthiscoupen.com).
3. The malicious web page includes code that causes the victim’s browser to send an implicit request to the target (www.example.com).
4. The malicious request causes the target to perform state change actions that the user did not intend.

Protecting against CSRF requires two things: ensuring that HTTP Methods are used appropriately, e.g., GET requests are not performing state-changing operations, and ensuring that non-GET requests can only be originated from your client-side code.

A CSRF token is a unique, secret, and unpredictable value generated by the server-side application and shared with the client. When requesting a sensitive action, such as submitting a form, the client must include the correct CSRF token. The CSRF token helps to ensure that the state change requests originated from the actual website, not from a malicious website, and helps to protect the websites from CSRF attacks.

How CSRF Protection Enabled in AEM?

AEM uses CSRF tokens to protect the websites from CSRF attacks — malicious users performing state-changing operations on behalf of authenticated users.

Valid Scenario:

The Authenticated Users send a state change request to the server; the client-side script (Granite jQuery or Granite CSRF standalone library) requests the CSRF token through CSRF Servlet — /libs/granite/csrf/token.json (For forms server embed the CSRF Token in the form while sending the form HTML to the client) and embed the token to the request. The CSRF filter validates the incoming CSRF token and allows the request if the token is valid — in this case, the token should be valid so the request will be processed.

Malicious Attack:

Authenticated user (authenticated to target website www.example.com) clicks on a malicious website link(checkthiscoupen.com) that sends the request to the original website(www.example.com) with the malicious data but without the valid CSRF token.

The CSRF Filter rejects the request due to missing a valid CSRF token in the request, and the attacker cannot perform any state change operations.

Granite jQuery or Granite CSRF standalone library:

Any component that relies on the granite.jquery client library dependency will benefit from the CSRF Protection Framework automatically. In case of granite jquery can't be used due to any restrictions, you can use granite.csrf.standalone client library to enable CSRF protection.

Include granite.jquery or granite.csrf.standalone to enable the CSRF protection for AEM websites.

The granite.jquery or granite.csrf.standalone client library invokes the CSRF token endpoint and embeds the CSRF token as part of every State change call.

For the forms, the tokens are generated when the form is sent to the client and validated when the form is sent back to the server. The token is added as a request parameter — :cq_csrf_token; for Ajax calls, the token is added as a request header — CSRF-Token

CSRF Token Servlet:

Invoking the token servlet — /libs/granite/csrf/token.json returns the CSRF token for the authenticated users; this means the CSRF protection will be enabled only for authenticated users and not for anonymous users — invoking the token endpoint for the anonymous user returns the blank result.

The validity of the token can be controlled through the “Adobe Granite CSRF Servlet” OSGI configuration — the default validity of the token is 600 sec.

CSRF Filter:

AEM enabled with a global Filter that will be invoked for every request, forwards, and includes that accept/reject the request based on the validity of the CSRF token in the request and other configurations.

The “Adobe Granite CSRF Filter” OSGI configuration can be modified to control the filtering criteria:
Add the methods that the filter should validate.
Enable User Agent validation and Configure Safe User Agents.
Enable the paths that should be skipped from filtering.

HMAC Key Sync:

You must replicate the HMAC binary to all server instances in a specific environment to use the tokens. Refer to The CSRF Protection Framework | Adobe Experience Manager for more information.

Dispatcher Configuration:

Minimal Dispatcher configurations are required to support the CSRF Protection Framework (allow CSRF-Token header; allow token endpoint and block the dispatcher from caching the token.json). For more information, refer to Configuring Dispatcher to Prevent CSRF Attacks | Adobe Experience Manager.

Conclusion:

The CSRF Protection Framework helps us to protect our websites from Cross-Site Request Forgery (CSRF) attacks. Ensure the CSRF Protection Framework is rightly configured to mitigate CSRF attacks.

The CSRF is meant to protect authenticated sessions; the server provides a CSRF token to the client for all authenticated sessions, and the client should pass the same CSRF token to the server with each subsequent request. If a request comes without the token, the server should ignore/log it.