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