Security Checklist

This section deals with various steps that you should take to ensure that your CQ installation is secure when deployed.

This list is a specialization of and in addition to the CRX Security Checklist and the Security Considerations for developing on CQ, which apply to any CQ installation.

Various areas are impacted and you should review all (in detail, the following list is meant to provide an introductory overview) to see which can be used to help protect your implementation:

  • Change Default Passwords
    An out-of-the-box installation of CQ includes various accounts to enable you to administrate and use the instance.
    In particular, Adobe strongly recommends that after installation you change the passwords for the privileged (admin) account(s).
  • Uninstall example content and users
    All example content and users should be uninstalled completely on a productive system before making it publicly accessible.
  • Disable CRXDE Support
    CRXDE Support should be disabled on a productive system before making it publicly accessible.
  • Configure replication and transport users
    Create users with specific, restricted access rights for building replication content (Author environment) and for receiving content (Publish environments) instead of using the admin user.
  • Disable WebDAV
    CRX and CQ come with WebDAV support that lets you display and edit the repository content. Setting up WebDAV gives you direct access to the content repository through your desktop.
    WebDAV should be disabled on the publish environment.
  • Use the Latest Version of Dispatcher
  • Restrict Access via the Dispatcher
    The Dispatcher filter can be used to allow or deny external access to specific areas of CQ.
    To protect your instance you should configure the Dispatcher to restrict external access as far as possible.
  • Protect against Cross-Site Scripting (XSS)
    Cross-site scripting (XSS) allows attackers to inject code into web pages viewed by other users. This security vulnerability can be exploited by malicious web users to bypass access controls.
    CQ applies the principle of filtering all user-supplied content upon output. Additionally, a web application firewall can be configured to add protection.
  • Preventing 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.
    There are a few methods that can be used with CQ to help prevent such attacks.
  • Default Access to User Profile(s) is everyone
    By default, everyone (the built-in group) has read access to all user profile(s).
    If such access is not appropriate for your installation you can change these default settings.
  • Issues with Cross-Site Request Forgery (CSRF)
    This is a security issue from the CRX Security Checklist, that is also appropriate to CQ.
    To address known security issues with (CSRF) in CRX WebDAV and Apache Sling you can configure the Referrer filter.
  • Disable the CQ WCM Debug Filter on production systems
    This is useful when developing as it allows the use of suffixes, but should be disabled on a production instance to ensure performance and security.
  • Clickjacking
    Configuring your webserver can help prevent clickjacking. 
  • Access to Cloud Service Information
    Reviewing whether the default security on the Cloud Service Information matches your requirements is recommended.
  • OSGI Settings
    Changing some OSGI settings on your publish instances can help avoid internal information leaking to the public.

注意

There are some additional security considerations applicable at the development phase.

Change Default Passwords

Adobe strongly recommends that after installation you change the password for the privileged CQ admin accounts (on all instances).

This change will also affect:

  • The CRX admin account
    The CQ admin account and the CRX admin accounts are actually one and the same. So once you have changed the password for the CQ admin account, you will need to use the new password when accessing CRX.
  • The admin password for the OSGi Web console
    This change will also be applied to the admin account used for accessing the Web console, so you will need to use the same password when accessing that.

In addition, Adobe recommends changing the OSGi (web) console password to something other than the admin password as not doing so:

  • Exposes the server with default password during startup and shutdown (that can take minutes for large servers)
  • Exposes the server when the repository is down/restarting bundle - and OSGI is running.

注意

To change the password of the admin account you must use the specific procedure - Changing the CQ admin password.

To change the password for the other CQ user accounts you can use the User Management console.

小心

You must also change the password used for accessing the Web console to ensure the security of your instance. See Changing the OSGi web console admin password.

Adobe also recommends that you either remove the example user author, or (at minimum) disable it by changing the password; see the User Management documentation for details on changing a user password.

注意

Further actions are described in the table Default Users and Groups, which gives an overview of the default users and groups included in the standard installation.

Changing the CQ admin password

The password for the CQ admin account can be changed via the Granite Operations - Users console.

Here you can edit the admin account and change the password.

注意

Changing the admin account also changes the OSGi web console account. After changing the admin account, you should then change the OSGi account to something different. 

Changing the OSGi web console admin password

You must also change the password used for accessing the Web console. This is done by configuring the following properties of the Apache Felix OSGi Management Console:

User Name and Password, the credentials for accessing the Apache Felix Web Management Console itself.
The password must be changed after the initial installation to ensure the security of your instance.

To do this:

  1. Navigate to the web console at <server>:<port>/system/console/configMgr.

  2. Navigate to Apache Felix OSGi Management Console and change the user name and password.

    file
  3. Click Save.

Configure replication and transport users

A standard installation of CQ specifies admin as the user for transport credentials within the default replication agents. Also, the admin user is used to source the replication on the author system.

For security considerations, both should be changed to reflect the particular use case at hand, with the following two aspects in mind:

  • The transport user should not be the admin user. Rather, set up a user on the publish system that has only access rights to the relevant portions of the publish system and use that user's credentials for the transport.

    You can start from the bundled replication-receiver user and configure this user's access rights to match your situation

  • The replication user should also not be the admin user, but a user who can only see content that is supposed to be replicated. The replication user is used to collect the content to be replicated on the author system before it is sent to the publisher.

Remove example content

All example content and users (e.g. the Geometrixx project and its components) should be uninstalled completely on a productive system before making it publicly accessible.

 

注意

Uninstall the cq-geometrixx-all-pkg package, as described in Uninstalling Packages.

Disable CRXDE Support

The Adobe CRXDE Support (com.day.crx.crxde-support) OSGi bundle should be disabled on both author and publish productive systems before making them accessible. This can be done by stopping the approriate OSGi bundle.

注意

OSGi bundles can be disabled with the Web Console.

Disable WebDAV

WebDAV should be disabled on the publish environment. This can be done by stopping the appropriate OSGi bundles.

  1. Connect to the Felix Management Console running on:

    http://<host>:<port>/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 bundle.

    注意

    A restart of CQ is not required.

Use the Latest Version of Dispatcher

When using Dispatcher, you should install the latest available version that is available for your platform. On a yearly basis, you should upgrade your Dispatcher instance to use the latest version to take advantage of product and security enhancements.

See Installing Dispatcher.

小心

When configuring the dispatcher, you should limit the Clients that can flush the cache.

Restrict Access via the Dispatcher

When configuring the Dispatcher you should restrict external access as much as possible. See Disabling External Access to Specific Folders.

Protect against Cross-Site Scripting (XSS)

Cross-site scripting (XSS) allows attackers to inject code into web pages viewed by other users. This security vulnerability can be exploited by malicious web users to bypass access controls.

CQ applies the principle of filtering all user-supplied content upon output. Preventing XSS is given the highest priority during both development and testing.

The XSS protection mechanism provided by CQ is based on the AntiSamy Java Library provided by OWASP (The Open Web Application Security Project). The default AntiSamy configuration can be found at

/libs/cq/xssprotection/config.xml

It is important that you adapt this configuration to your own security needs by overlaying the configuration file. The official AntiSamy documentation will provide you with all the information you need in order to implement your security requirements.

注意

We strongly recommend you always access to the XSS protection API by using the XSSAPI provided by CQ.

Additionally, a web application firewall, such as mod_security for Apache, can provide reliable, central control over the security of the deployment environment and protect against previously undetected cross-site scripting attacks.

Preventing 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 CQ.

Install Security Hotfix

Ensure that you have installed the latest Security Hotfix:

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).

注意

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 CQ is 200.
    • As a preventive measure disable the other default renderers (HTML, plain text, XML). Again by configuring the Apache Sling GET Servlet.

    小心

    Do not disable the JSON renderer, this is required for the normal operation of CQ.

Configuring the Dispatcher to prevent DoS

At the dispatcher level, there are two methods of configuring to prevent DoS attacks:

  • Use the mod_rewrite module (for example, Apache 2.2) to perform URL validations (if the URL pattern rules are not too complex).
  • Prevent the dispatcher from caching URLs with spurious extensions by using filters.
    For example, change the caching rules to limit caching to the expected mime types, such as:
    • .html
    • .jpg
    • .gif
    • .swf
    • .js
    • .doc
    • .pdf
    • .ppt
    An example configuration file can be seen for restricting external access, this includes restrictions for mime types.

To safely enable full functionality on the publish instances, configure filters to prevent access to the following nodes:

  • /etc/ 
  •  /libs/ 

Then, configure filters to allow access to the following node paths:

  • /etc/designs/*
  • /etc/clientlibs/*
  • /etc/segmentation.segment.js
  • /libs/cq/personalization/components/clickstreamcloud/content/config.json
  • /libs/wcm/stats/tracker.js
  • /libs/cq/personalization/* (JS, CSS and JSON)
  • /libs/cq/security/userinfo.json (CQ user information)
  • /libs/cq/i18n/* (Internalization)

小心

The JSON query servlet must be filtered by the dispatcher as provided by the dispatcher rule /0090 above.

Default Access to User Profile(s) is everyone

By default, everyone (the built-in group) has read access to all user profile(s). If such access is not appropriate for your installation you can change these default settings. See Profiles and User Accounts.

Cross-Site Request Forgery

This is a security issue from the CRX Security Checklist, that is also appropriate to CQ. Read Issues with Cross-Site Request Forgery for more details on how to handle it. 

Clickjacking

To prevent clickjacking we recommend that you configure your webserver to provide the X-FRAME-OPTIONS HTTP header set to SAMEORIGIN.

For more information on clickjacking please see the OWASP site.

Access to Cloud Service Information

When you integrate your CQ instance with the Adobe Marketing Cloud you use Cloud Service configurations. Information about these configurations, together with any statistics collected are stored in the repository. We recommend that, if you are using this functionality, you review whether the default security on this information matches your requirements.

The webservicesupport module writes statistics and configuration information under:

/etc/cloudservices

With the default permissions:

  • Author environment: read for contributors
  • Publish environment: read for everyone

OSGI Settings

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

For each of the following services the specified settings need to be changed (on publish):

For further details see OSGi Configuration Settings.

When working with AEM there are several methods of managing the configuration settings for such services; see Configuring OSGi for more details and the recommended practices.

​