Skip to main content

Architecture

How good is your AEM security? – Sling Resolution

RNSecurity

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/) and there are already many resources on generic mitigation for these vulnerabilities.  Instead in this series, I cover security issues and mitigations specific to AEM.  Today’s topic is Sling Resolution.

Previous posts in series:

Sling Resolution Vulnerabilities

Dispatcher Allow rulesets are one of the largest risk vectors within AEM because of default Sling Resolution behavior.  Spend a significant amount of your security testing time here, because this is the most common way for malicious actors to find other vulnerabilities, compromise data within the system, and achieve remote code execution.

Remote code execution (RCE) is the highest impact concern, as an attacker may gain a broad range of further exploit options.  This can include breaking the system, compromising data, stealing user credentials, and creating phishing pages on legitimate domains.

In creating defensive measures, it’s useful to know how RCE can occur in the first place.  RCE is possible if hacker can get access to the OSGI console, writing to /apps or (in insecure systems) /content, Querybuilder, Groovy console, ACS AEM Tools, or WebDAV.  It is best to completely disallow access to these features on Production publishers for any user.  From there, utilize Adobe’s best practices of Deny all paths and then Allow necessary paths.   Most of these potential vulnerabilities should be mitigated by the latest version of the dispatcher rules present in Adobe’s AEM Project Archetype, but it’s worth confirming in your own dispatcher as well.

The following is not a comprehensive list of vulnerabilities but it will give you an idea of what to start looking for.

  • Sometimes developers write deny rules that are too rigid, or allow rules that are not rigid enough. For example, a request to /bin/querybuilder.json/test.css may still return the AEM querybuilder page.  Instead of using:
{ /type “deny” /path “/bin/querybuilder” }

Utilize wildcard (*) matching for child and extension paths. E.g.

{ /type “deny” /path “/bin/querybuilder*” }
  • Adding selectors, URL Params, multiple slashes to the URL may change how Sling and the Dispatcher interpret the request. Many vulnerabilities rely on exposing the JCR content structure through .json rendering requests.
  • If a malicious user gains access to the content structure, they can often mine usernames, credentials stored in plain text, PII, exposed admin pages, or clues about other vulnerabilities within the system. All it may take, is the attacker finding 1 username where they can brute-force the password, to have a much bigger data breach.
  • By default, numbered (-1,1,2,3…), “children”, and “infinity” selectors in a request are interpreted by Sling to display the current content path and Sling resources under it as a JSON response.  This functionality should not be available over the dispatcher.
  • If you have enabled Sling Model Exporters for your Sling Model objects, ensure no sensitive data or properties are exposed by accident in the response.

Putting into Practice

As AEM increases in market share, so too does the incentive for hackers to find exploits, so it’s very important to test and stay up to date on the latest recommended allow rules.  Test any rules that deviate from the standard ruleset very thoroughly.

Need some practical examples?  Below I’ve provided some basic URLs to test on your dispatcher.  Over the public internet these should return a 404 or redirect appropriately.  If not, that represents a vulnerability within your application.

  • /content.infinity.json
  • /.1.json
  • /content.5.json
  • /content.ext.json
  • /content.children.json/test.css
  • /etc.-1.json
  • /content.html/test.png/test.1.json
  • /bin/querybuilder.json/test.css
  • /bin/querybuilder.json?a.html
  • /bin/querybuilder.json.css
  • /bin/querybuilder.json.servlet.css
  • //bin//querybuilder.json
  • /system/console/bundles?.css

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Paul Goodrich

Paul Goodrich is a certified Adobe Experience Manager Technical Architect at Perficient. He is committed to excellent customer software experiences, complex problem solving and optimizing Agile delivery.

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram