Presentation “Configuring CQ Security“ by Ben Zahler at CQCON2013 in Basel on 19 and 20 June 2013.

1. Configuring CQ Security

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

3. Agenda
 Security Configuration Basics
 Denial-Of-Service-Attacks
 Repository Attacks
 Access Control
 Dispatcher Configuration

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

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

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

7. Denial-Of-Service attacks

8. Attack Vectors
 Types of Denial-of-Service attacks
 brute force
 exploit of system weakness that exponentially boosts the attack

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

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

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

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

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

14. Repository Attacks

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

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

17. 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“

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

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

20. Access Control

21. ACL Management in CQ
 Manage ACLs in User Administration

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

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

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

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

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

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

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

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

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

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

32. Dispatcher Configuration

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

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

35. Dispatcher Configuration
 Exact configuration is driven by your application‘s needs
 Adapt the dispatcher.any to allow as little as required by your application.

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

37. 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*"}

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

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

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

41. Summary
Key Points for every CQ installation:
 Uninstall Geometrixx content and users
 Change default user’s passwords
 Emphasize correct Access Control
 Tighten dispatcher configuration

42. Questions
What are your questions?

43. Thank You
CQ Blog: http://cqblog.inside-solutions.ch