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 finegrained 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