Configuring CQ Security
About Me
CQ Architect for Inside Solutions
http://inside-solutions.ch
CQ Blog: http://cqblog.inside-solutions.ch
Customer Projects with Adobe CQ
Training Material on Adobe CQ
Agenda
Security Configuration Basics
Denial-Of-Service-Attacks
Repository Attacks
Access Control
Dispatcher Configuration
CQ and Security
Is CQ secure?
Yes! ... if done right.
CQ is very flexible, which means in customer projects a lot of good and bad things can be done.
Security out-of-the-box is OK
Must apply security checklist
http://dev.day.com/docs/en/cq/current/deploying/security_checklist.html
Improvements in every release
Improve it!
delete geometrixx content and users
restrict security configuration based on your application‘s needs
take care of access control
Configuring For Security
The following basic rules should always applied to secure a website:
Make available as little information about your system as required.
Emphasize access restriction and correct access implementation.
Filter out invalid requests as early as possible, e.g. on firewall, web server or dispatcher.
Every Security Issue Matters
Even minor flaws should be fixed because:
attacking a website often needs more than one loophole.
even a combination of small loopholes can lead to severe security issues.
Denial-Of-Service attacks
Attack Vectors
Types of Denial-of-Service attacks
brute force
exploit of system weakness that exponentially boosts the attack
General DoS Mitigation
Apply the following basic rules:
Protect CQ with a Firewall to filter invalid requests
Network protocol exploits
Detection of a limited number of servers that send vast amount of similar requests
Cache Resources
Dispatcher cache and/or CDN
Cache all content from CQ if possible.
Content that cannot be cached must be explicitly stress-tested.
Expect more than just regular load
Selectors and DoS
Selectors are a very helpful utility in Adobe CQ, but they can be used to flood the dispatcher cache if not implemented correctly.
For a given page, the dispatcher cache treats each combination of selectors like a distinct page, therefore caching it separately.
If the number of selectors is not limited or if arbitrary selectors are allowed, an attacker is able to quickly fill up the dispatcher cache resulting in too much load on the CQ instance behind it.
Selector Caching Example
The following requests would all be cached separately by a dispatcher cache: Random Selectors allowed :
http://localhost:4502/libs/cq/ui/widgets.cqcon.js http://localhost:4502/libs/cq/ui/widgets.whatever.js
1.3 Mb each
Frequently used ImageServlet with random selectors: www.images.com/image1.120x120.jpg
www.images.com/image1.150x150.jpg www.images.com/image1.200x200.jpg
Multiple Selectors allowed: www.images.com/image1.green.red.jpg
www.images.com/image1.red.green.jpg www.images.com/image1.red.green.blue.jpg
Rules for Selectors: Development
The following rules should be applied in the application code:
Design components so that the allowed selectors are known.
Do not allow excessive amounts of selectors
Avoid multiple selectors on a resource except for clearly defined patterns
Use multiple selectors with a fixed ordering if possible
Requests with unknown selectors should not be accepted, but should result in an HTTP response with status other than 200.
Ideally implemented in Dispatcher filtering
Also possible to create a Servlet Filter
Rules for Selectors: Configuration
The following rules should be configured in the dispatcher configuration:
Only allow selectors that are actually used in the application
Limit the number of selectors in a URL as low as the application accepts
Disable default selectors from CQ.
.feed.xml
.infinity.json
Repository Attacks
Attack Vectors
Place unwanted content on website
create security holes
change application to perform further attacks
Get access to restricted information
system information such as user information can be used for social engineering
Protect The Content
In CQ, everything is content
Content can be manipulated with POST requests
everything can be manipulated with POST requests
Only prohibited by correct ACL setup and by correct dispatcher configuration.
Repository Attack Details
POST to /content manipulates the CQ instance Manipulate the Website
Create XSS vulnerabilities curl --data 'redirectTarget=http://www.cqcon.eu' --user author:author
http://localhost:4502/content/geometrixx/en.html/jcr:content
PUT / POST to /apps can install bundles and components
Takes control of the CQ Instance Can be used to attack internal systems in a corporate network
curl -v -u admin:admin --upload-file malicious-bundle.jar http://localhost/apps/malicious/install/ --header "Content-Type: application/java-archive“
Protect Information
Only allow outside access to relevant parts of the CRX repository Disable default CQ features that expose data
json extension (also 1..9.json and infinity.json)
xml extension
feed.xml
If you need json or xml for specific URLs, only allow it for specific urls
Json data gives information about existing pages and user Ids can reveal sensitive information such as pages that have an activatedDate
if user ids are know, brute force attacks can be successful
user ids can contain (or imply) email addresses can be used for social engineering
/home/users.5.json
CQ Out Of the Box Content
Out-of-the-box, CQ comes with the geometrixx applications content components users
Before going into production: Uninstall package cq-geometrixx-all Delete all unused users
Change the password for ALL out of the box users
google for „inurl:/content/geometrixx“ >17000 hits some of them can be accessed with author/author
author user is part of geometrixx (since CQ 5.5), but still has write access to /content
Access Control
ACL Management in CQ
Manage ACLs in User Administration
Permissions, Actions and ACLs
CQ Actions define the right that can be assigned to a user CQ Permissions allow or deny a user to perform an action on a
resource For each action and on each resource in the repository, a user can have either
permission state Allow or Deny.
In Adobe CQ, permissions can be granted through the user administration UI. Under the covers, these permissions are translated into JCR access control
privileges stored in repository nodes.
This conversion can be quite complex depending on the permissions granted in the UI.
For many actions in the UI, specific JCR permissions are set for jcr:content nodes.
CRX Access Control Properties
CRXDE displays for a given node the access control entries that are set specifically for the node in section Access Control List.
All policies effective on the node (but possibly inherited) are displayed in section Effective Access Control Policies.
Adobe CQ Actions
Action Description JCR Policy Properties
Read The user is allowed to read the page and any child pages. allow: jcr:read
Modify The user can: • modify existing content on the page and on any child pages. • create new paragraphs on the page or on any child page.
At the JCR level, users can modify a resource by modifying its properties, locking, versioning, nt-modifications, and they have complete write permission on nodes defining a jcr:content child node, for example cq:Page, nt:file, cq:Asset.
General: allow • jcr:lockManagement • jcr:modifyProperties • jcr:versionManagement rep:glob=*/jcr:content*: allow • jcr:addChildNodes • jcr:nodeTypeManagement • jcr:removeChildNodes • jcr:removeNode
Create The user can create a new page or child page. If modify is denied the subtrees below jcr:content are specifically excluded because the creation of jcr:content and its child nodes are considered a page modification. This only applies to nodes defining a jcr:content child node.
General: allow • jcr:addChildNodes • jcr:nodeTypeManagement rep:glob=*/jcr:content*: deny • jcr:addChildNodes • jcr:nodeTypeManagement
Adobe CQ Actions II
Delete The user can: • delete existing paragraphs from the page or any child page. • delete a page or child page.
If modify is denied any sub trees below jcr:content are specifically excluded as removing jcr:content and its child nodes is considered a page modification. This only applies to nodes defining a jcr:content child node.
General: allow • jcr:removeChildNodes • jcr:removeNode rep:glob=*/jcr:content*: deny • jcr:removeChildNodes • jcr:removeNode
Read ACL The user can read the access control list of the page or child pages. Allow jcr:readAccessControl
Edit ACL The user can modify the access control list of the page or any child pages. Allow jcr:modifyAccessControl
Replicate The user can replicate content to another environment (for example, the Publish environment). The privilege is also applied to any child pages.
Allow crx:replicate
ACL Evaluation
In JCR, access control entries are applied hierarchically: When an entry is made on a parent resource, it is also valid for all child resources.
If the same policy property is also set on one of the child nodes, that entry supersedes the entry on the parent node.
The policy is then applied for the child node and all of its children (unless they have in turn superseding entries).
ACL Evaluation II
Permission properties on user principals always take precedence over group principals irrespective of their order in the access control list and their position in the node hierarchy.
If a user is explicitly denied jcr:read on /content and the user is member of a group with “allow jcr:read” privilege on /content/foo, the user policy has precedence and the user is denied jcr:read privilege on /content/foo
Access rights from multiple group principals are evaluated based on their order, both within the hierarchy and within a single access control list.
Impersonate Functionality
Allows one user to impersonate another user
Right to impersonate can be configured in user adaministration
When impersonating another user, all actions in Adobe CQ are effectively executed with that user.
An entry is made in the audit log when the impersonation starts and ends
Other log files (such as the access log) hold no information about the fact that impersonation has occurred on the events.
Repository attributes such as jcr:createdBy will contain the name of the impersonated user.
Programmatic Access Control
Adobe CQ provides services and interfaces to manage users and permissions programmatically.
Key classes:
UserManager (org.apache.jackrabbit.api.security.user)
AccessControlManager (javax.jcr.security)
Session (javax.jcr)
UserProperties(com.adobe.granite.security.user)
Replaces deprecated Profile API
ACL Best Practices
Use groups to assign permissions rather than users
You have many more users than groups, so groups simplify the structure.
Groups help provide an overview over all accounts.
Inheritance is simpler with groups.
Users come and go. Groups are long-term.
Always use Allow statements to specify the access rights of the group principal (wherever possible). Avoid using a Deny statement.
Keep it simple
ACL Best Practices II
We have seen that ACLs are based on content hierarchy and child nodes inherit permissions.
As a consequence, security and access requirements should be a main driver when designing the content structure:
Managing access should be easy
Enforcing access control should come for free
Avoid copying content to containers such as /var/* for temporary operations or backup purposes.
Verify a proper permission setup.
Dispatcher Configuration
Dispatcher Filtering Rules
The /filter directive in file dispatcher.any allows specifying the resources that are served by the dispatcher module. For a given resource, the directives in section /filter are evaluated from bottom up and the first matching rule is applied. Filter directives have the following format: /0001 { /type "deny" /glob "*" }
0001 is the unique id of the filter directive. The type of an entry can be either allow or deny, The glob property allows to specify a pattern to which the directive applies.
The glob expression is evaluated against the request line of the HTTP Request, such as:
GET /content/geometrixx-‐outdoors/en.html HTTP.1.1
Dispatcher Whitelist Approach
To implement the recommended whitelist approach, the first directive denies all resources:
/filter {
# Deny everything first and then allow specific entries
/0001 { /type "deny" /glob "*" }
Based on that first directive, selected resources are allowed in more fine-grained directives. The following example allows all requests to /content and all GET requests to css files: /0023 { /type "allow" /glob "* /content*" } # Enable specific mime types in non-‐public content directories
/0041 { /type "allow" /glob "GET *.css *" } # enable css
Dispatcher Configuration
Exact configuration is driven by your application‘s needs
Adapt the dispatcher.any to allow as little as required by your application.
Recommended Dispatcher Filtering Rules
Adobe CQ provides dispatcher.any files for publish and author instances as part of the dispatcher module
The following rules are recommended for all CQ publish instances unless there are substantial requirements from your application to omit them: /1001 { /type "deny" /glob "* *.xml*" }
/1002 { /type "deny" /glob "GET *.*[0-‐9].json*" }
/1003 { /type "deny" /glob "GET *.infinity*.json *" }
/1004 { /type "deny" /glob "GET *.feed.*" }
/1005 { /type "deny" /glob "GET *.query.*" }
/1006 { /type "deny" /glob "*.*?*" }
Particularly ensure: Deny ALL access to /libs, /apps, /var and /home
Allow only GET requests to /etc
Selectors in Dispatcher Configuration
To prevent DoS attacks that fill the dispatcher cache using excessive selectors, selectors can be generally disallowed. The selectors used in the application can then be explicitly allowed.
The following example shows how only selector cqcon.html is enabled: /0101 { /type "deny" /glob "* /*.*.* *"}
/0102 { /type "allow" /glob "* /content*.cqcon.html*"}
Selectors in Dispatcher Configuration II
The following configuration is slightly less restrictive:
/0101 { /type "deny" /glob "* /*.*.*.* *"}
Here, one (arbitrary) selector is allowed. Still, if the application does not validate the selectors sent and sends responses with HTTP status 200, unlimited cache entries can be created.
CQ environments without End User Login
If a website does not have functionality that is based on the login of an end user, it is recommended to disable all means of getting authenticated session on the CQ dispatcher. For this, the following two rules can be implemented:
/1010 { /type "deny" /glob "* *sling:authRequestLogin*"}
/1011 { /type "deny" /glob "* *j_security_check*"}
In addition, HTTP headers authorization and proxy-authorization should not be included in the /clientheaders section of file dispatcher.any.
Dispatcher Filter Rules Ordering
1. Deny all
2. Allow repository sections you need.
3. Deny selectors / GET parameters.
4. Allow special selectors /GET parameters for specific paths as used in your application.
5. In the end, ensure that the things that must be closed are closed.
Summary
Key Points for every CQ installation:
Uninstall Geometrixx content and users
Change default user’s passwords
Emphasize correct Access Control
Tighten dispatcher configuration
Questions
What are your questions?
Thank You
CQ Blog: http://cqblog.inside-solutions.ch