CRX Security Checklist Page 1

CRX Security Checklist
CRX Security Checklist
Overview / Adobe Experience Manager / Adobe Experience Manager 6.0 / Administering / User Administration and Security /
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.
NOTE
Further information is also available about the most dangereous security threats as published by
Open Web Application Security Project (OWASP).
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.
NOTE
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:
• via the Adobe CRX Security console
© 2012 Adobe Systems Incorporated.
All rights reserved.
Page 1
Created on 2014-11-08
CRX Security Checklist
•
from the command line by using a curl command
CAUTION
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.
CAUTION
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
2.
Choose the Administrator user account from the left panel, so that you see its profile information in
the right panel.
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.
© 2012 Adobe Systems Incorporated.
All rights reserved.
Page 2
Created on 2014-11-08
CRX Security Checklist
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
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
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.
3.
Login as admin.
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.
© 2012 Adobe Systems Incorporated.
All rights reserved.
Page 3
Created on 2014-11-08
CRX Security Checklist
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 AND READ ACCESS TO FILES IN THE
AEM INSTALLATION FOLDER
Read and write access to files in an AEM installation folder or its backups must only be allowed to the
operating system user under which the AEM instance is running. File system access is a level below any
application security layer and could have consequences if access is not restricted to the appropriate user.
Write access to installation folders allows for unauthorized content modification, installation of malitious
scripts and bundles or addition of rogue keys and certificates.
Read access could allow attackers access to log files, configuration files, private content and other critical
data.
Ensuring that only the operating system user that runs the instance has full access to the files in the
installation folder will prevent attackers who gain write access to the directory from deserialising arbitrary and
untrusted data.
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.
© 2012 Adobe Systems Incorporated.
All rights reserved.
Page 4
Created on 2014-11-08
CRX Security Checklist
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.
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.
© 2012 Adobe Systems Incorporated.
All rights reserved.
Page 5
Created on 2014-11-08
CRX Security Checklist
© 2012 Adobe Systems Incorporated.
All rights reserved.
Page 6
Created on 2014-11-08