Large scale data breaches and critical security vulnerabilities have companies thinking about security more than ever.  Many developers are familiar with the OWASP top 10 (https://owasp.org/www-project-top-ten/).  There are already many resources on generic mitigation for these vulnerabilities.  So instead, in this series, I will cover security issues and mitigations specific to AEM.  Here I will cover two of AEM’s exploit mitigation tools, CryptoSupport and Service Users.

Previous posts in series:

• Part 1 – XSS
• Part 2 – Sling Resolution
• Part 3 – Denial of Service

AEM Mitigation Tools

Encrypted Credentials

It is recommended for all passwords, security tokens, and other service credentials to be encrypted within the JCR.  That way, even if an attacker gains access to read the node where they are stored, the credentials are useless without the decryption key.  If you are storing these credentials via OSGI properties, you can use AEM’s Crypto Support page to manually encrypt any property based on a system master key.  Once it is encrypted, update the matching run mode OSGI config in /apps with the encrypted value.

Implementing for your QA environment would look like this:

1. Configure all QA publishers to share the same system master key.  I recommend using a different system master key per environment type (Dev, QA, Prod).
2. Navigate to the QA publisher OSGI console, Config Mgr, Main tab, and the Crypto Support link.  Generate the encrypted property (password/secret) via the plain text field.

• • If you do not have access to the OSGI console (AMS), you will need to create a support ticket with Adobe to give you access to the OSGI console in Prod.
  • If this is not possible, you can have the Adobe CSE generate the encrypted property for you or ask them to help copy the CryptoKey down to a lower environment.
    • However, there are some flaws with these two approaches.  Having the rep generate the encrypted property can be a security concern and disallowed by the client, as the implementation team is sending credentials outside of company-owned communications.  Copying the CryptoKey down can also be a concern, as sharing keys between local/dev environments and prod introduces a risk as these environments are typically less secure overall.
  • On AEM as a Cloud Service, you can utilize Cloud Manager Secret Variables instead.

3. Update the appropriate QA runmode OSGI configuration in the codebase with the encrypted value.

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

Once this process is complete, AEM’s OSGI Configuration Plugin will automatically decrypt any encrypted OSGI properties used within an OSGI service.  You should not have to use any manual decrypt library call within your services.  For more details on this, see the below Adobe documentation.

https://experienceleague.adobe.com/docs/experience-manager-64/administering/security/encryption-support-for-configuration-properties.html?lang=en

Service User Permissions

In older AEM versions, it was common for developers to utilize administrative sessions to access data within the JCR.  Today, most AEM developers have updated these sessions to utilize service users but not all have implemented best practices around the service user’s permissions.  Many service users are assigned overly broad permissions instead of specific paths.  For instance, the platform doesn’t prevent you from implementing a service user that has the same permissions as an administrator.  If this is the case, one insecure endpoint could lead to server-side XSS, Denial of Service attacks, or a data breach via the JCR writes I discussed in previous posts.

So be very thoughtful in how you are limiting permissions.  Some key considerations are:

• Restrict the types of nodes and properties a service user writes.
• If possible, consolidate programmatically read and written content to a set number of paths. Allow the service user read access only to those paths instead of all of /apps or /content.
• In a multi-tenant architecture, utilize multiple service users to limit attack surface vectors.
• If the content is accessible to specific authenticated users, prefer to use their request’s resource resolver and ACLs instead of a service user.

Why Mitigate?

Ideal service, access, and storage designs incorporate a lot of considerations and stakeholders can wonder if it’s worth the effort.  After all, if every service is designed well with no vulnerabilities, why spend time hardening other parts of the system?  I find it useful to explain it with the analogy of home security.  Most people do not rely on just locked doors to protect their homes from theft.  Some utilize deadbolts, motion lights, neighborhood watch, safes, and external locations (banks) to secure their valuables.  Why?  Attacks grow more sophisticated or change approach.  Once an attacker breaks through the first layer of defense, you want several more to meet them.

Next week, I will cover the Content Disposition Filter, and mitigation tools specific to AEM as a Cloud Service.

For more information on how Perficient can help you achieve your AEM Security goals and implement your dream digital experiences, we’d love to hear from you.

Contact Perficient to start your journey.