CRX Security Checklist

This document tells you how to set up CRX so that you can use it in a production environment, without risking security leaks or unauthorized access.

Installation Settings

The current version of CRX is provided with a security level that does not allow read access to everyone as previous versions did.

For production instances, please confirm that security level using below instructions.

Determining the Security Level

To find out if CRX is configured with low or high security, proceed as follows:

  1. Open the CRX console.
  2. Log in with the user admin.
  3. Open CRX DE Light
  4. Select the root node, and open the Access Control Editor tab.
  5. Check that there is no allow Access Control Entry on the root node (/) for the principal everyone; this would allow everyone to read/write/etc content. If there is such an entry, the security level is low, and all users, including anonymous access, has read/write access to content.

Switching from Low to High Security

To switch from low to high security, you need to remove all access control policies for the principal everyone on the root node (i.e. remove any entries found in step 5 when Determining the Security Level). This will deny the default read/write access to content available to any logged-in user. After this you will be able to configure authorization for your repository groups and users according to your needs.

Hinweis

To check, open the CRX console, log in as anonymous (no password), and confirm the user can see no content.

Additionally, you might consider password-protecting, modifying, or even removing the anonymous user, to prevent anonymous login to the repository.

Passwords

Before you use CRX productively, we recommend that you change the default passwords. The default password for the admin account is admin.

Changing the CRX Admin Password

The password for the CRX admin account can be changed by various means, including:

Achtung

You need the current admin password to be able to perform the change operation.

It is recommended to test such changes before use on a production system.

Achtung

The password 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.

Changing the admin password with the Adobe CRX Security Console

You can also change the admin password from the security console:

  1.  

    Login as admin and navigate to:

    http://<server>:<port>/libs/granite/security/content/useradmin.html

     

    file
  2. Choose the Administrator user account from the left panel, so that you see its profile information in the right panel.

    file
  3. Click the Edit icon (pencil) on the bottom right of the profile panel.

  4. Enter the new CRX admin account password in the Password field of the profile edit form and click the Save icon (downwards arrow) on the bottom right of that panel.

    file

Changing the admin password from the Command Line with Curl

You can also change the admin password from the command line by using a curl command to POST to /home/users/<user>.rw.html using the granite AuthorizableServlet:

curl -u admin:<current_pwd> -F rep:password="<new_pwd>" -F :currentPassword="<current_pwd>" http://host:port/home/users/a/admin.rw.html
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

If your password includes utf-8 characters, include -F _charset_="utf-8". For example:

curl -u admin:admin -F rep:password="myAdminPwd" -F :currentPassword="admin" -F _charset="utf-8" http://host:port/home/users/a/admin.rw.html
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Password-Protecting the Anonymous Account

Issues with Cross-Site Request Forgery

To address known security issues with Cross-Site Request Forgery (CSRF) in CRX WebDAV and Apache Sling you need to configure the Referrer filter.

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:

  1. Open the Apache Felix console (Configurations) at:
       http://<server>:<port_number>/system/console/configMgr

  2. Login as admin.

  3. In the Configurations menu, select:

        Apache Sling Referrer Filter

  4. In the Allow Hosts field, enter all hosts that are allowed as a referrer. Each entry needs to be of the form
       <protocol>://<server>:<port> 
    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.

  5. Check the Allow Empty field, if you want to allow empty/missing referrer headers.

  6. Edit the methods this filter should use for checks with the Filter Methods field.

  7. Click Save to save your changes.

File System Security

Prohibit illegitimate write access to CRX installation

Write access to files in a CRX installation or its backups must only be allowed to users whose role in CRX is that of an admin.

Write access to the installation folders allows users to reconfigure CRX through OSGi configuration files, which allows immediate rights elevation to admin.

Prohibit illegitimate read access to log files

Log files can potentially disclose information that reveals attack vectors. As such, access to read log files must only be granted to trusted entities.

Securing HTTP Communication

As with any application available on the internet, any confidential information must be secured on a transport level.

The need for this will vary depending on the content stored in your system. 

To ensure that the system cannot be compromised, the following should be secured through SSL for any CRX system, irrespective of the content in the system. 

  • Access to the OSGi Console
  • Access by the admin user
  • Access to user information
  • Inter-system communication if it goes over the public internet.

Sanity Checks prior to Go-Live

The following items are secured by default, and if no changes were made to them, expose no security threat. However the security impact of a change to these is potentially critical. Due to that circumstance, you are encouraged to double check that the secure defaults are still in place before you expose your system to a public audience.

Access to User and Group nodes

By default, user and group nodes cannot be accessed by anyone but the user or group, members of the group user-administrators, and members of the group administrators.

To verify that the default settings are still in place and access to the nodes is not possible to other users

  • confirm that the defaults ACL are in place on the /home node
  • confirm that only users and groups themselves can read their own node

Confirm default ACLs on /home node

To confirm the default ACL settings, go to /crx/de/index.jsp#/crx.default/jcr%3aroot/home in your installation and confirm that the ACLs match the defaults shown below.

file

Confirm only principals themselves can read their own node

To confirm that a group's node can only be read by the group itself, go to e.g. /crx/de/index.jsp#/crx.default/jcr%3aroot/home/groups/c/content-authors and confirm

  • that the only ACL set on the node is the ACL that allows the group read access.
  • that no ACLs are effective other than the ACLs confirmed for /home above and the ACL that allows the group itself read access.

The same procedure applies for users.

file
​