Cross-site request forgery (CSRF) is a web site vulnerability where a valid user’s browser is used to send a malicious request, possibly via an iFrame. Because the browser sends cookies on a domain basis, if the user is currently logged in to an application, the user’s data may be compromised.
For example, consider a scenario where you are logged in to administration console in a browser. You receive an email message containing a link. You click the link, which opens a new tab in your browser. The page that you opened contains a hidden iFrame that makes a malicious request to the forms server using the cookie from your authenticated AEM forms session. Because User Management receives a valid cookie, it passes the request.
Referer: The address of the source page from which a request is coming. For example, a web page on site1.com contains a link to site2.com. Clicking the link posts a request to site2.com. The referer of this request is site1.com because the request is made from a page whose source is site1.com.
Whitelisted URIs: URIs identify resources on the forms server that are being requested, for example, /adminui or /contentspace. Some resources may allow a request to enter the application from external sites. These resources are considered allowlisted URIs. The forms server never performs a referer check from allowlisted URIs.
Null referer: When you open a new browser window or tab, then type an address and press Enter, the referer is null. The request is entirely new and not originating from a parent web page; therefore, there is no referer for the request. The forms server can receive a null referer from:
Allow a null referer on SOAP and REST endpoints. Also allow a null referer on all URI login pages such as /adminui and /contentspace and their corresponding mapped resources. For example, the mapped servlet for /contentspace is /contentspace/faces/jsp/login.jsp, which should be a null referer exception. This exception is required only if you enable GET filtering for your web application. Your applications can specify whether to allow null referers. See “Protecting from Cross-Site Request Forgery attacks” in Hardening and Security for AEM forms.
Allowed Referer Exception: Allowed Referer Exception is a sublist of the list of allowed referers, from which requests are blocked. Allowed Refer Exceptions are particular to a web application. If a subset of the Allowed Referers should not be allowed to invoke a particular web application, you can blocklist the referers via Allowed Referer Exceptions. Allowed Referer Exceptions are specified in the web.xml file for your application. (See “Protecting from Cross-Site Request Forgery attacks” in Hardening and Security for AEM forms on Help and Tutorials page.)
AEM forms provides referer filtering, which can help prevent CSRF attacks. Here is how referer filtering works:
The forms server checks the HTTP method used for invocation:
The forms server checks whether the requested URI is allowlisted:
If there is a referer in the request, the server checks whether it is an allowed referer. If it is allowed, the server checks for a referer exception:
If there is no referer in the request, the server checks whether a null referer is allowed.
When you run Configuration Manager, the default host and IP address or the forms server are added to the Allowed Referer list. You can edit this list in administration console.
In administration console, click Settings > User Management > Configuration > Configure Allowed Referer URL’s. The Allowed Referer list appears at the bottom of the page.
To add an allowed referer:
0(zero) in the boxes, all ports on that server are enabled. You can also enter a specific port number to enable only that port.
To remove entry from the Allowed Referer list, select the item from the list and click Delete.
If the Allowed Referer List is empty, the CSRF feature stops working and the system becomes insecure.
After changing the Allowed Referer list, restart the AEM forms server.