The CSRF Protection Framework in AEM

AEM 6.1 ships with a mechanism that helps protect agains Cross-Site Request Forgery attacks, called the CSRF Protection Framework. For more information on how to use it, consult the documentation.

The Sling Referrer Filter

To address known security issues with Cross-Site Request Forgery (CSRF) in CRX WebDAV and Apache Sling you need to add configurations for the Referrer filter in order to use it.

The referrer filter service is an OSGi service that allows you to configure:

• which http methods should be filtered
• whether an empty referrer header is allowed
• and a white list of servers to be allowed in addition to the server host.

By default, all variations of localhost and the current host names the server is bound to are in the white list.

To configure the referrer filter service:

- Open the Apache Felix console (Configurations) at:
   http://<server>:<port_number>/system/console/configMgr
- Login as admin.
- In the Configurations menu, select:
    Apache Sling Referrer Filter

- In the Allow Hosts field, enter all hosts that are allowed as a referrer. Each entry needs to be of the form
   ://: 
For example:
• http://allowed.server:80 allows all requests from this server with the given port.
• If you also want to allow https requests, you have to enter a second line.
• If you allow all ports from that server you can use 0 as the port number.
  
- Check the Allow Empty field, if you want to allow empty/missing referrer headers.
Caution:
It is recommended to provide a referrer while using commandline tools such as cURL instead of allowing an empty value as it might expose your system to CSRF attacks.

• Edit the methods this filter should use for checks with the Filter Methods field
• Click Save to save your changes.

Changge Default OSGI setting in AEM production instances

Some OSGI settings are set by default to allow easier debugging of the application. These need to be changed on your publish and author productive instances to avoid internal information leaking to the public

For each of the following services the specified settings need to be changed:

• Adobe Granite HTML Library Manager:
  • enable Minify (to remove CRLF and whitespace characters).
  • enable Gzip (to allow files to be gzipped and accessed with one request).
  • disable Debug
  • disable Timing
• Day CQ WCM Debug Filter:
  • uncheck Enable
• Day CQ WCM Filter:
  • on publish only, set WCM Mode to "disabled"
• Apache Sling Java Script Handler:
  • disable Generate Debug Info
• Apache Sling JSP Script Handler:
  • disable Generate Debug Info
  • disable Mapped Content

How to disable WebDav in AEM

Disable WebDAV

WebDAV should be disabled on both the author and publish environments. This can be done by stopping the appropriate OSGi bundles.

1. Connect to the Felix Management Console running on: http://:/system/console For example http://localhost:4503/system/console/bundles.
2. In the list of bundles, find the bundle named: Apache Sling Simple WebDAV Access to repositories (org.apache.sling.jcr.webdav)
3. Click the stop button (in the Actions column) to stop this bundle.
4. Again in the list of bundles, find the bundle named:Apache Sling DavEx Access to repositories (org.apache.sling.jcr.davex)
5. Click the stop button to stop this b
   undle.
   
   Note:
   
   A restart of AEM is not required.

Reference URL:

https://helpx.adobe.com/experience-manager/6-4/sites/administering/using/security-checklist.html

How to prevent DOS attacks in AEM

Mitigate Denial of Service (DoS) Attacks

A denial of service (DoS) attack is an attempt to make a computer resource unavailable to its intended users. This is often done by overloading the resource; for example:

• With a flood of requests from an external source.
• With a request for more information than the system can successfully deliver.
  For example, a JSON representation of the entire repository.
• By requesting a content page with an unlimited number of URLs, The URL can include a handle, some selectors, an extension, and a suffix - any of which can be modified.
  For example, .../en.html can also be requested as:
  • .../en.ExtensionDosAttack
  • .../en.SelectorDosAttack.html
  • .../en.html/SuffixDosAttack
  All valid variations (e.g. return a 200 response and are configured to be cached) will be cached by the dispatcher, eventually leading to a full file system and no service for further requests.

There are many points of configuration for preventing such attacks, here we only discuss those directly related to AEM.

Configuring Sling to Prevent DoS

Sling is content-centric. This means that processing is focused on the content as each (HTTP) request is mapped onto content in the form of a JCR resource (a repository node):

• The first target is the resource (JCR node) holding the content.
• Secondly, the renderer, or script, is located from the resource properties in combination with certain parts of the request (e.g. selectors and/or the extension).

Note:

This is covered in more detail under Sling Request Processing.

This approach makes Sling very powerful and very flexible, but as always it is the flexibility that needs to be carefully managed.

To help prevent DoS misuse you can:

1. Incorporate controls at the application level; due to the number of variations possible a default configuration is not feasible.
In your application you should:
• Control the selectors in your application, so that you only serve the explicit selectors needed and return 404 for all others.
• Prevent the output of an unlimited number of content nodes.




2. Check the configuration of the default renderers, which can be a problem area.
• In particular the JSON renderer which can transverse the tree structure over multiple levels.
  For example, the request:
      http://localhost:4502/.json
  could dump the whole repository in a JSON representation. This would cause significant server problems. For this reason Sling sets a limit on the number of maximum results. To limit the depth of the JSON rendering you can set the value for:
      JSON Max results (json.maximumresults)
  in the configuration for the Apache Sling GET Servlet. When this limit is exceeded the rendering will be collapsed. The default value for Sling within AEM is 200.
• As a preventive measure disable the other default renderers (HTML, plain text, XML). Again by configuring the Apache Sling GET Servlet.
Caution:
Do not disable the JSON renderer, this is required for the normal operation of AEM.




3. Use a firewall to filter access to your instance.
• The use of an operating system level firewall is necessary in order to filter access to points of your instance that might lead to denial of service attacks if left unprotected.

Mitigate Against DoS Caused by Using Form Selectors


Note:

This mitigation should be performed only on AEM environments that are not using Forms.

Since AEM does not provide out of the box indexes for the FormChooserServlet, using form selectors in queries will trigger a costly repository traversal, usually grinding the AEM instance to a halt. Form selectors can be detected by the presence of the *.form.* string in queries.

In order to mitigate this, please follow the below steps:

1. Go to the Web Console by pointing your browser to http://serveraddress:serverport/system/console/configMgr
2. 
   
3. Search for Day CQ WCM Form Chooser Servlet
4. After you click on the entry, disable the Advanced Search Require in the following window.
5. 
   
6. Click Save.

Disable WebDAV

WebDAV should be disabled on both the author and publish environments. This can be done by stopping the appropriate OSGi bundles.

1. Connect to the Felix Management Console running on: http://:/system/console For example http://localhost:4503/system/console/bundles.
2. In the list of bundles, find the bundle named: Apache Sling Simple WebDAV Access to repositories (org.apache.sling.jcr.webdav)
3. Click the stop button (in the Actions column) to stop this bundle.
4. Again in the list of bundles, find the bundle named:Apache Sling DavEx Access to repositories (org.apache.sling.jcr.davex)
5. Click the stop button to stop this b
   undle.
   
   Note:
   
   A restart of AEM is not required.

Replicating Keys for AEM 6.2 and Older Versions

Solution:

Replicating Keys for AEM 6.2 and older version.

In AEM 6.2 and older versions, the keys are stored in the repository under the /etc/key node.

The recommended way to securely replicate the keys across your instances is to only replicate this node. You can selectively replicate nodes via CRXDE Lite:

1. Open CRXDE Lite by going to http://serrveraddress:4502/crx/de/index.jsp
2. Select the /etc/key node.
3. Go to the Replication tab.
4. Press the Replication button.

Replicating Keys for AEM 6.3

Whereas in older versions the replication keys were stored in the repository, beginning with AEM 6.3 they are stored on the filesystem.

Therefore, in order to replicate your keys across instances you need to copy them from the source instance to the target instances' location on the filesystem.

More specifically, you need to:

1. Access the AEM instance, typically an author instance, that contains the key material to copy;
2. Locate the com.adobe.granite.crypto.file bundle in the local file system. For example, under this path: /crx-quickstart/launchpad/felix/bundle21
3. The bundle.info file inside each folder will identify the bundle name.
4. Navigate to the data folder. For example: /crx-quickstart/launchpad/felix/bundle21/data
5. Copy the HMAC and master files.
6. Then, go to the target instance you want to duplicate the HMAC key to, and navigate to the data folder. For example: /crx-quickstart/launchpad/felix/bundle21/data Paste the two files you previously copied.
7. Refresh the Crypto Bundle if the target instance is already running.
8. Repeat the above steps for all instances you want to replicate the key to.

Note:

You can revert to the pre 6.3 method of storing keys by adding the below parameter when you first install AEM:
-Dcom.adobe.granite.crypto.file.disable=true